SOA (Service Oriented Architectures) have been deployed for 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 mobile 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, mobile apis, based on Web Oriented Architecture (WOA) are now days more and more used for external enterprises exchanges.
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:
Simple Object Access protocol
Web service based on XML and HTTP protocols
Describe data structures and models to be used cross enterprise.
Web service description Language
XML based structure to describe interactions between entities by specifying action methods and structured data exchanged by these methods.
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.
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.
This is why, in the mobile space, 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.
Representational State Transfer
Lightweight web service protocol based on HTTP and POX (Plain Old XML)
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 for enterprise to mobile, enterprise to web and enterprise to partner exchanges.
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 Mobility Platform, Mobile Application Development Platform (MADP/MEAP)
Convertigo Mobility Platform MADP will plug in any SOA based architecture, and expose some if its selected features to the outside world as Mobile APIs based on standard WOA based protocols to be used by Mobiles, eService portals and partner exchanges. This can be done as an on premise platform, or as a Cloud service offering MBaaS (Mobile Backend as a Service).
Convertigo bridges the enterprise’s SOA to Mobile APIs
Convertigo Mobility Platform will be able to create new mobile APIs 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 Mobile API 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 mobile APIs by filtering out unnecessary or sensible data.
Mobile APIs require more security than standard web services, although SSL is mandatory, in many cases, SSL security by itself will not match business case requirements. This is why Convertigo's platform brings additional services to enable API protections, Authenticated contexts, Identity managers, API replay protection and device revocation. These services are mandatory for most securtity aware processes such as banking, e-commerce, healthcare and many others.