Systems/Applications initially used to connect directly with each other. For example, in a J2EE environment, the code was specifically written from scratch to connect File System, Databases, EIS systems (CRM, BRM, ERP). This lead to Spaghetti like system where each application/system connects to the other independtly. If applications are more, the integration will be a real complex.
Then came idea of using adaptors, custom adaptors where developed, which encapsulated the code to connect to other applications. Certain standards like JCA where followed to build these adaptors so that they can run on wide variety of standard application servers. Adaptors provided a simpler way to connect systems, with adaptors it became more of a plug and play. To use an adaptor, use the provided API’s to connect and manage data on other sytem, use connection properties to be provided to API to connect to the other system. As API’s where standard, the code written should be able to run with any other adaptor for the similar system.
Another way of communication is to use Queues (for example JMS). Queues was used for guaranteed messaging, as message was retained in queue till the other system pick it up. Two types of queues, is simple queues and Publish and Subscribe based queues.
Parallely came idea of using Service Bus, these where independent systems, that where used to store connection information, route and transform messages (hence store message meta data model). Also they started providing, various ways of communication in one system - synchronous, asynchronous, session, REST, queues, http, adaptors, web services, etc. These systems ideally had a normal message format, to which all incoming message was converted, and then based on the required system, it was reconverted to the format that the recieving system required. This step provided extra decoupling from recieving system message format and helped coders on other system to only connect to ESB. Also connection information, adaptor related configuration information now became part of this bus.
Next came idea of Web-Services based inter-operatability. Where all systems are supposedly to provide, a standard based web-services oriented communication front. Thus all systems had this as a common language. And hence could easily communicate using this. The Service bus, rather became more of orchestrator now, with new advanced services, like BPM’s using enabling routing, transforming, and keeping track of these activities as well. UDDI provided a standard way to register/store the web-services and helped in discovering and using them.
Then came idea of using adaptors, custom adaptors where developed, which encapsulated the code to connect to other applications. Certain standards like JCA where followed to build these adaptors so that they can run on wide variety of standard application servers. Adaptors provided a simpler way to connect systems, with adaptors it became more of a plug and play. To use an adaptor, use the provided API’s to connect and manage data on other sytem, use connection properties to be provided to API to connect to the other system. As API’s where standard, the code written should be able to run with any other adaptor for the similar system.
Another way of communication is to use Queues (for example JMS). Queues was used for guaranteed messaging, as message was retained in queue till the other system pick it up. Two types of queues, is simple queues and Publish and Subscribe based queues.
Parallely came idea of using Service Bus, these where independent systems, that where used to store connection information, route and transform messages (hence store message meta data model). Also they started providing, various ways of communication in one system - synchronous, asynchronous, session, REST, queues, http, adaptors, web services, etc. These systems ideally had a normal message format, to which all incoming message was converted, and then based on the required system, it was reconverted to the format that the recieving system required. This step provided extra decoupling from recieving system message format and helped coders on other system to only connect to ESB. Also connection information, adaptor related configuration information now became part of this bus.
Next came idea of Web-Services based inter-operatability. Where all systems are supposedly to provide, a standard based web-services oriented communication front. Thus all systems had this as a common language. And hence could easily communicate using this. The Service bus, rather became more of orchestrator now, with new advanced services, like BPM’s using enabling routing, transforming, and keeping track of these activities as well. UDDI provided a standard way to register/store the web-services and helped in discovering and using them.
No comments:
Post a Comment