SOA (Service Oriented Architectures) have been deployed since years in enterprises. SOA promises have been more or less kept, giving enterprises the flexibility, security and the reliability they required. But, the needs have now changed since SOA was largely adopted by the industry. Enterprises need now to be even more flexible and agile to the outside world.
Mobility is spreading like fire, customer portals for eServices are mandatory, creating new feeds for partners allowing them to interact back with the enterprise is now crucial. For sure SOA architectures could solve these pains, but with costs and delays that no companies can now afford. This is why, Web Oriented Architecture (WOA) are now days more and more used for external enterprises exchanges.
SOA Technology
Service oriented architecture is a quite old idea where computer programs should offer services to others and have real time interactions between them based on a loosely coupled scheme. This concept is opposed to batch processing and monolithic silo architectures.
SOA existed much before it was actually called SOA but as it was more and more standardized to become what we know now as SOA, a set of protocols, functions and tools often used together. SOA is in general associated with some of the following technologies:
SOAP
|
Simple Object Access protocol |
Web service based on XML and HTTP protocols |
XSD
|
XML Schemas |
Describe data structures and models to be used cross enterprise. |
WSDL
|
Web service description Language |
XML based structure to describe interactions between entities by specifying action methods and structured data exchanged by these methods. |
ESB
|
Enterprise Service Bus |
A real exchange HUB allowing applications to exchange data using the SOA protocols. ESBs can be programmed for specific business processes and support asynchronous exchanges as well as queuing. |
Although SOA solves lots of enterprise’s pains, its adoption has not been complete in most enterprises for the following reasons:
- Most of the existing strategic enterprises applications where not developed to be SOA aware, that is to say they do not support SOAP, Web Services based on XML an XSD schemas. Redeveloping them is out of the reach of most enterprises in term of time and budget.
- ESBs and SOA technology products are expensive in license and professional services needed to implement a reliable SOA architecture. Although some open source and free products are on the market now, implementing SOA architecture is still expensive, and only very large organizations did and can afford it.
- SOA technologies are not easy to master for low level skill programmers, for example, SOAP webservices requires lots of knowledge, is rather rigid, and consumes a reasonable amount of CPU and network bandwidth.
WOA Technology
Web Oriented Architectures came along the WEB 2.0 revolution to extend SOA. In this world, things had to move fast! Creating and consuming web services have been done on simplified web service protocols. This is why REST (Representational State Transfer) and JSon (JavaScript Object Notation) where introduced.
These protocols are much easier to use by web based developers, require less CPU and bandwidth and are largely promoted by internet stars such as Facebook, Amazon, Twitter, Youtube and others. In the Internet web world, each time an application offers services to others it is in majority based on WOA standards.
Also, in the mobile space, a majority of mobile applications exchange data with servers using JSON/REST protocols. As explained before, they consume much less CPU and bandwidth than SOAP web services, interesting feature when used over 3G networks.
REST
|
Representational State Transfer |
Lightweight web service protocol based on HTTP and POX (Plain Old XML) |
JSon
|
JavaScript Object Notation |
JSON is a variant for data returned by REST Web Services. It consumes less bandwidth and is easily handled by web developers mastering the Javascript language |
Service Orchestrator
|
Orchestrates REST/JSON services |
Acts like a lightweight ESB without its complexity. A service orchestrator can invoke several services and combine them to one by filtering out unnecessary data for a specific WOA based service. |
Mainly, we can say that WOA based architecture is more flexible and agile than pure SOA and used more and more for enterprise to mobile, enterprise to web and enterprise to partner exchanges.
Convertigo Mobilizer MADP solution
How can enterprises having a strongly structured SOA deployed embrace mobility, eServices portals and partners exchange by preserving their agility, reliability and security? Even more, how can they even embrace existing applications not yet SOA enabled? The solution comes with Convertigo Mobilizer Mobile Application Development Platform (MADP/MEAP)
Convertigo MADP will plug in any SOA based architecture, and expose some if its selected features to the outside world as very standard WOA based protocols to be used by Mobiles, eService portals and partner exchanges.
Convertigo bridges the enterprise’s SOA to non SOA and WOA spaces
Convertigo will be able to create new WOA services based on exiting SOA or non SOA apps in a fraction of time and cost compared to traditional development. More, the enterprise agility will be preserved as changing and external WOA service will not require any change in the underlying SOA services.
Convertigo’s built in Sequencer will orchestrate the services provided by the enterprise’s internal SOA layer to build lightweight, business oriented WOA services by filtering out unnecessary or sensible data.
When security and privacy is a concern, Convertigo’s WOA services will be available to the outside world encrypted by SSL (Secure Socket Layer protocols) using https protocols.
|
