This content has been marked as final. Show 2 replies
OK, now I'm going into a "vulnerable mode". Let's see what reactions we will get on my definitions...
Simply said an ESB is a seet of tools and programs that can share information based on messages. The messages (mostly xml) are created and published and received over TCP/IP by deamons/applications/adapters that listen to the protocol.
In the messages meta-information tells who the sender is what the contenttype is.
Either a hub distributes messages to subscribers to messages(adapters) select messages if they are authorised to recevie them.
Plain messages can be setup as point to point connections. e.g. SOAP messages or epecificly webservices can act like this. An ESB has additional functionality, for example a processmanager or a business rule engine that act as a central/generic functional-layer in an enterprise. Also the ESB can handle multiple messagetypes, and even transform one type to the other, for example flatfiles to xml-files.
You have an order-entry system that sends messages of orders to be shipped. But there are multiple warehouses that handle different orderttypes (e.g overnight delivery) or even deliver different products by warehouse
The businessrule to send an ordermessages to a specific warehouse is setup on the ESB where the messages are received and passed to the correct warehouse.
Let me know if this answer is what you expected
I think ESB gives us an ability to define additional abstract Business Objects layer.
I mean we can define all Business Objects involved in our integration in ESB.
And we define mappings of this Business Objects to real Web Services, Databases and systems in ESB (link up adapters or so on...).
At higher Business Process Level - we make a BPEL process that handle with this Business Objects ONLY (defined in ESB), NOT with real systems, databases.
So we can ceperate business logic (BPEL process) from lower level mappings to certain systems. In BPEL we can work with business objects of our enterprise, not thinking of there real reflection in web service or database. This work (of such a binding) will do ESB.
In addition we simply resolve situation when our Business Object is stored actually in several systems or databases. We do NO changes in BPEL, and even don't need to know about this. We simly add propogation of Business Object to several systems in ESB by adding Adapter.
By so, we can devide roles:
- business process developer (work with business objects and BPEL)
- lower connectivity developer (work with Adapters and ESB)
Message was edited by: