Let’s introduce what it means…
While Petals ESB does not provide any solution to invoke services directly from the kernel/component Java code, the DSB now provides a solution for that… By using this DSB feature, we can really use the power of service oriented architecture directly in our code. No more direct calls to services, you just need to call the client and say which service you want to invoke. The service bus will resolve the endpoint and route the message to the right place by using the right way/path. By using this way, you do not have to care if you need to speak with a SOAP service, a JMS queue or a REST service: Just call the service, the DSB will do the rest.
Now some code…
So, let’s have a look on the client code and first, let’s imagine that you have a web service which is bound to the service bus. Once bound, a DSB endpoint is available inside the DSB, and all messages which are sent to this endpoint will be forwarded to the final web service. One basic approach is to create a web service hosted by the service bus which ‘consumes’ the DSB service. As a result, a SOAP message sent to the DSB web service will be forwarded to the DSB endpoint which will forward it again to the final web service. Allright, but this is just for external SOAP clients and it is impossible to invoke anything firectly from the service bus kernel.
Now, let’s call the DSB endpoint from Java code… To put ourselves in a **real** case, let say that you are DSB kernel developer and that you want to say hello to the world (oh s*** really?) by using the *HelloWorldService* which is bound to the bus. Let’s code this client:
So, just get a *org.petalslink.dsb.service.client.Client* from the *org.petalslink.dsb.service.client.ClientFactory* factory, create your *org.petalslink.dsb.service.client.Message* and send it by using the *sendReceive* method. That’s all… Let’s try to clarify what it means with a simple schema:
It looks so simple… I just deeply hacked the petals service bus kernel to provide such a thing. Why? Because the service bus is also deeply based on the JBI specification: Creating a client means that the client need to be able to receive responses and acts itself as a service on the service bus point of view. It is also built using all the component context stuff. No component context means no way to send/receive messages (component contexts are just created when JBI components are installed).
So it is really important to release the client when you do not use it anymore: There are tons of listeners and threads in the different layers which are just used to receive messages. If you do not release the client, there will be unused resources for a long time.