BPEL support in Petals DSB


As promised in the last article about my talk at OW2Con 2011 last week, here is a video on something I was not able to show due to some low resolution problems. The video is a bit long but shows several things (in the right order):

  1. The DSB Manager Web application is used to manage the Distributed Service Bus. It uses the DSB Web service API to interact with node instances running somewhere…
  2. The DSB Manager is used to bind business services to the DSB (let’s forget JBI, the user does not care about it…). DSB services are also exposed. Every DSB node provides the same business API with the help of the distributed endpoint registry it uses.
  3. The DSB Manager uses the DSB BPEL API to deploy BPEL processes to the DSB. Up to the DSB to use the right internal endpoint when the process is executed. Services can be hosted on any node, it is the role of the DSB to route messages to the right endpoint on the right node. The BPEL process is exposed as Web service and can be invoked by any Web service client. Here I just use SOAPUI client.
  4. We can monitor what happens when invoking a service! For now the DSB Manager uses Web service notification to subscribe to some monitoring topic hosted on the DSB node. When a message is exchanged between the client and the services involved in the process execution, notification are automatically published to the DSB Manager which has just subscribed. The monitoring uses Web sockets for live display in the browser…
  5. Last thing is just a test to show more monitoring data when many calls are exchanged between consumers and providers.
Let’s go one step further… The BPEL engine we use in the DSB is our own (PetalsLink) BPEL engine we developed from scratch. This allows us to have a complete control on it and to be able to extend it and embed it as we want without any constraint. In the current case, the BPEL Engine is hosted on a dedicated DSB component. It means that we do not have an external thing which talk with services through some exposed services. This is really important to notice that by doing such thing we can really base process execution on a Service Oriented Architecture. When developing the BPEL process with the Petals Studio, or when creating a BPM process (more details in a future post), you do not have to care about service endpoints. You just have to say to the process that you want to call operation X of service Y or interface Z. It is up to the DSB hosting the BPEL engine to resolve endpoints at runtime. By using this approach we can really do interesting things, just because the DSB is Distributed: services can be hosted on any nodes, can be replicated, can move, can be updated without any impact on the process itself: Oh wait this is SOA!

Related articles

Publicités

Comparing comparable things


Last week at OW2Con, Talend CTO talked about their data and service integration solution. This sentence impressed me (almost this one, not sure it was so short):

We have more than 500 connectors!

Wow! Great, let’s have a look to that! What is a connector? In the Petals ESB context connectors are the bindings represented in the upper part of this well-known image

Petals ESB

Petals ESB

So, we have almost 8 connectors. Looks that we are poor… So let’s look in details what is a Talend connector: http://www.talendforge.org/components/.

Can you see that? A Talend component is almost an operation in a service, or let’s say that it is an input/output from a data source. So a service is not as generic as a Petals service but it is a specialized service i.e. we can also have tons of ‘components’ for Petals ESB, it just means that we have to provide configuration artifacts for all the services that we find: Salesforce, Amazon EC2, S3, all the databases in the world, etc, … Oh no, wait! Don’t you see the Talend component on the bottom of the figure just above? Yes we have a Talend connector so we have 500+ components in Petals ESB 🙂

No really, Talend guys really do an incredible work and their recent press releases are really impressive. Congrats!

 

Back From OW2Con 2011


I was in Paris last week for the OW2 annual conference and I gave a talk called « Petals BPM and the Cloud » during the Open Cloud Summit Session (wow what a name!). This talk was about showing that we have things running and ready to be published in the Cloud. As I said during my talk, difficulty is not to provide the SaaS layer, pushing a Web app to the Cloud is not so hard (and not so interesting). The interesting part is about building the PaaS layer. In the current case, the PaaS will provide « Integration as a Service », or how we can use Petals Service Bus, to provide ways to integrate, orchestrate, manage and monitoring business services.

My son is an open source fan

My son is an open source fan

So let’s go back on my talk, where I planned to show things working… Unfortunately, I was not able to show anything due to some low resolution problems and this was really a shame; next time I will prepare a video in case of something like that happens. I am going to record these videos this week to show that we have interesting things under development : We can create business processes with Petals BPM and deploy them on the service bus in order to execute and monitor the process itself in a distributed way.

While waiting these videos, here are the slides of my talk. There are sort of ‘zen’ slides so the talk I gave was really important to understand all… So come and see me next time, or just send me comments.

For the other parts of the conference, as usual, there were really interesting presentations and discussions around OW2, open source and Cloud. One fun thing which I learnt was that OW2-Jonas is used in MS Azure Cloud solution as support of J2EE apps (can I also inform that Microsoft was a big sponsor of OW2Con? Yes, really, they gave money for an open source conference, that’s fun). Well, there were so many interesting things and I can not list all here. But open source is really something companies should have a look if they do not did it already, they will be surprised to see how active and professional is the community behind it.

Petals DSB is not Petals ESB


Almost true… In fact Petals DSB uses and extends Petals ESB in several ways. When I started to think about extending the Enterprise Service Bus, it was just to avoid all the JBI stuff at the management level i.e. use a real, simple and efficient API. So I added many management stuff exposed as Web services : Bind external services, expose internal services (oh yes bind + expose = proxy), get endpoints, activate things, etc…
One other goal was to avoid to use closed protocols for inter node communication: The ESB uses at least three ports to create inter node communications for JMX, NIO and SOAP. So why not, just using an open protocol like SOAP and just one port? This is what I did, I changed some implementations to use the same port and the same protocol for all services.

All this stuff has been developed focusing on extensibility and easier development. This is mainly because the ESB can be hard to extend for newbies, there are so many things inside… Today the DSB is not only a Distributed Service Bus, it is also a framework so that developers can easily extend the DSB without the need to know how it works inside. Some examples? Want to expose a kernel service : Add the JAXWS @WebService annotation. Want to subscribe to Web service notifications : Annotate you Java method with @Notify. Want to be notified about new endpoints : Add the @RegistryListener annotation. That’s all, you do not have to search for the Web service server to expose your service, nor read all the WSN documentation to receive notifications, … Simple, efficient.

There are other things you can do, mostly all is detailed in the DSB page.

Invoke business services from service bus kernel


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:

https://gist.github.com/1186183

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:

Hacker inside!

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.