Using the ESB Service Container
Subject:   Tracking 'entry' endpoint?
Date:   2006-01-09 12:51:37
From:   dave_chappell
Response to: Tracking 'entry' endpoint?

Hi Michael,
The 'entry' endpoint is the input channel that the service is listening on. This is where services receive their messages from the bus.

Using visual modeling tools, you describe process definitions that coordinate the interaction between service invocations. The bus invokes a service as part of executing a step in the process, which results in the delivery of a message to that service. The service processes the message, and if there is a response required (to be sent back to the sender or forwarded on to the next step in the process) the response is placed in the 'exit' endpoint. The bus picks up whatever is placed in the 'exit' endpoint and sends it to the next step in the process.

If you are using a mediation service that is provided by the ESB, such as an XSLT transformation service or a content-based router, then all you have to do is configure the entry/exit endpoints, configure the artifacts necessary to deploy the service (such as XSLT stylesheet or XPath expression), and you are ready to deploy. There is no coding required.

If you are writing your own custom service, you write code once that extracts the incoming message from the entry endpoint using SOAP, DOM, Multi-part MIME operations (based on Apache SOAP). Once the service is written, it can be placed in the ESB repository.

Any service that is in the ESB repository, whether custom written or supplied by the ESB, may be reused multiple times in different contexts depending on the surrounding process definition that references it, and by suppying different deployment artifacts or runtime/startup parameters.

The entry and exit endpoints can be configured to be a point-to-point message queue, a publish-and-subscribe topic, or ultimately a web service call. Actually because the entry/exit endpoints are abstracted through the bus, and the bus provides protocol mediation the next next step in the process may be independently configured to use a different protocol than the last service sent the message out on (e.g. pub/sub from the exit endpoint to an application that is ultimately listening using SOAP, or FTP).