Saturday, April 12, 2008
Smooks improvements and futures
If you're a JBossESB user then you've probably used Smooks, which is our default transformation engine. Unlike other ESBs that may only give you XSLT based transformations (perhaps as an afterthought to their architecture), Smooks provides much more than this, and transformation has been at the heart of our architecture since the start. Anyway, Mr Smooks (aka Tom) has been describing the future for Smooks and within our ESB. Definitely worth a read. It's nice to see that others are getting in on the act. What's that they say about imitation and flattery ;-)?
Friday, April 11, 2008
Cloud Computing and the ESB
Whether you call it Cloud Computing, Grid, utility computing, ubiquitous computing, or just large scale distributed systems, computing devices are everywhere. These days I have a mobile phone that is more powerful (processor and memory) than the laptop I had 10 years ago. I suspect my fridge is more powerful than my old BBC Model B computer! Having spent a lot of time working in large-scale distributed systems, the basic requirements are pretty similar: develop objects/services, publish, locate and use. Doing this in a transport agnostic manner is very important as well: how many services running on a mobile phone support JMS? But as a service developer do I really need to tie my service to a specific transport? That breaks reusability: the service logic (excluding transport) should be useable in a variety of different deployments, assuming its dependencies on 3rd party bindings are present (e.g., no good deploying a service on a mobile phone if it needs a local Oracle instance to execute!)
What you need to support cloud computing (for want of a better term) is an infrastructure that allows you to develop your services without having to worry about where they will be deployed. Furthermore, if you can compose services from other services and (re-)deploy them dynamically as your requirements change, that would be a benefit. Many service deployments need to change over time, if for no other reason than machines may fail or performance improvements mean that you want to move a service from one machine to another. Or you may need to deploy more (or less) service instances over time to improve availability. Interestingly some of this overlaps with governance.
You also need to be able to cope with dynamic routing (service locations change and you want to route inflight messages or messages sent to the old address, to the new location). Transformations of data are pretty important too: sending Gigabytes of data to my services that has been deployed on the mobile phone might get a bit costly, but maybe my infrastructure can prune that information while it is inflight and only send a synopsis (or some portion of it that is sufficient for the service do do meaningful work).
Ultimately the service deployments and how they are related to the devices that are available to the infrastructure should be handled automatically by the infrastructure, with the capability to override this or provide hints as to more appropriate deployment choices (e.g., "please don't deploy this service on a mobile phone!") The infrastructure then becomes responsible for managing those services, guaranteeing specific SLAs (so it may mean migrating a service from one device to another, for example, to maintain a level of performance or availability), pulling in more devices or distributing more instances of the service across multiple devices, again to maintain policies and SLAs.
Overall the infrastructure and the way it supports development of services assists in the realisation of loosely coupled, non-brittle applications. By this point you may see where I'm going with this. In my opinion a good infrastructure for cloud computing is also a good infrastructure for SOA, i.e., an SOI. In our case, that would be JBossESB as it continues to evolve and improve. Stay tuned!
What you need to support cloud computing (for want of a better term) is an infrastructure that allows you to develop your services without having to worry about where they will be deployed. Furthermore, if you can compose services from other services and (re-)deploy them dynamically as your requirements change, that would be a benefit. Many service deployments need to change over time, if for no other reason than machines may fail or performance improvements mean that you want to move a service from one machine to another. Or you may need to deploy more (or less) service instances over time to improve availability. Interestingly some of this overlaps with governance.
You also need to be able to cope with dynamic routing (service locations change and you want to route inflight messages or messages sent to the old address, to the new location). Transformations of data are pretty important too: sending Gigabytes of data to my services that has been deployed on the mobile phone might get a bit costly, but maybe my infrastructure can prune that information while it is inflight and only send a synopsis (or some portion of it that is sufficient for the service do do meaningful work).
Ultimately the service deployments and how they are related to the devices that are available to the infrastructure should be handled automatically by the infrastructure, with the capability to override this or provide hints as to more appropriate deployment choices (e.g., "please don't deploy this service on a mobile phone!") The infrastructure then becomes responsible for managing those services, guaranteeing specific SLAs (so it may mean migrating a service from one device to another, for example, to maintain a level of performance or availability), pulling in more devices or distributing more instances of the service across multiple devices, again to maintain policies and SLAs.
Overall the infrastructure and the way it supports development of services assists in the realisation of loosely coupled, non-brittle applications. By this point you may see where I'm going with this. In my opinion a good infrastructure for cloud computing is also a good infrastructure for SOA, i.e., an SOI. In our case, that would be JBossESB as it continues to evolve and improve. Stay tuned!
Tuesday, February 19, 2008
JBossWorld 2008 update
Lots of activity at JBossWorld 2008! As you can find elsewhere, this was the biggest JBW ever and all of the presentations I attended were packed. The ESB/SOA Platform related presentations will be uploaded soon and we'll cross post links here as soon as possible. But in the meantime you may be interested in another announcement about the SOA Platform.
Friday, February 15, 2008
SOA-P now available
Yesterday at JBoss World the availability of the JBoss Enterprise SOA Platform was officially announced. I don't know how long this webcast is going to be available but a recording can be found here.
Sunday, February 3, 2008
Tuesday, January 29, 2008
SOA + BPM = Killer Combination
Kurt's recent posting prompted me to put down here what I've been putting off for a while: my thoughts on BPM and SOA. Hopefully it's apparent to everyone that BPM != SOA: they solve different problems. However, that does not mean they cannot compliment each other. The recent work on combining jBPM with JBossESB should illustrate that, but let's go further.
One of the key aspects of SOA is about agility: the ability to react more quickly to changes in the way IT systems need to be deployed and used, as well as being able to leverage existing IT investments. At this level agility is something that is definitely a concern of T-Shirt And Sandle Man, i.e., IT folks and not Men In Suits, i.e., business folks, which is primarily where BPM resides. Where BPM works well is in ensuring that business goals and efficiently aligned with how they are translated into processes, making those processes more reliable, faster and compliant with the businesses policies and practices. Fairly obviously, for business folks, these are just as important as IT agility.
SOA and BPM do not compete with one another: they are natural compliments. A good combination of SOI (Service Oriented Infrastructure) and BPM will make it natural to orchestrate services (or more likely tasks) as second nature within the deployment and not as some bolt-on which is there simply for compliance reasons. I think the combination of SOA and BPM is a "killer app" because:
Remember that SOA is not a product: it does not come in a shrink-wrapped box. So you shouldn't think that it is simply an ESB or some other technology. It is not purely a technology driven initiative. A good SOI will allow the right people in an organisation to take ownership of the components (technology and business) that are important to them. This is one of the reasons why loosely coupled systems work. SOA does not belong to a single group of people (e.g., the typical developer), but to the business as a whole. That's why SOA+BPM work so well together: it is a natural fit.
One of the key aspects of SOA is about agility: the ability to react more quickly to changes in the way IT systems need to be deployed and used, as well as being able to leverage existing IT investments. At this level agility is something that is definitely a concern of T-Shirt And Sandle Man, i.e., IT folks and not Men In Suits, i.e., business folks, which is primarily where BPM resides. Where BPM works well is in ensuring that business goals and efficiently aligned with how they are translated into processes, making those processes more reliable, faster and compliant with the businesses policies and practices. Fairly obviously, for business folks, these are just as important as IT agility.
SOA and BPM do not compete with one another: they are natural compliments. A good combination of SOI (Service Oriented Infrastructure) and BPM will make it natural to orchestrate services (or more likely tasks) as second nature within the deployment and not as some bolt-on which is there simply for compliance reasons. I think the combination of SOA and BPM is a "killer app" because:
BPM promotes a model-based approach to task definitions, which, if used right, should ensure that what the business wants is what they get. Importantly it's defined by the business folks and not by the infrastructure. It encourages a top-down approach to service orchestration and requirements: you don't develop what you don't need. I know this sounds pretty obvious, but you'd be surprised!- BPM and tooling are natural allies, as they are with SOA.
Remember that SOA is not a product: it does not come in a shrink-wrapped box. So you shouldn't think that it is simply an ESB or some other technology. It is not purely a technology driven initiative. A good SOI will allow the right people in an organisation to take ownership of the components (technology and business) that are important to them. This is one of the reasons why loosely coupled systems work. SOA does not belong to a single group of people (e.g., the typical developer), but to the business as a whole. That's why SOA+BPM work so well together: it is a natural fit.
Friday, January 25, 2008
Service Orchestration using jBPM
Service Orchestration is the arrangement of business processes. Traditionally BPEL is used to execute SOAP based WebServices, and in the Guide 'Service Orchestration' you can obtain more details on how to use ActiveBPEL with JBossESB. However, if you want to orchestrate JBossESB services regardless of their end point type, then it makes more sense to use jBPM. Figure 1 shows an order process in jBPM Designer view which is part of JBoss Developer Studio. In this post we will describe what it takes for you to start using jBPM for Service Orchestration.
Figure 1. 'OrderProcess' Service Orchestration using jBPM
Step 1. Create the Process Definition
To create the process definition from Figure 1 you drag in components from the left menu bar. To start you'd drag in a Start node, followed by a regular 'node' type, which we gave the name 'Intake Order'. You can now connect the two boxes by selecting a 'transition', and by first clicking on the start node and then on the Intake Order node. Next we need to tell jBPM which JBossESB service backs this node. This is done by attaching a special 'EsbActionHandler' action to the node and configuring it to go out to the service 'InTakeService'. For now you will need to click on the 'source' tab to drop into the XML representation of this node (see Figure 2).
Figure 2. XML Source of the 'OrderProcess' Service Orchestration
In this case the configuration for the Intake Order the XML looks like
The first two subelements esbServiceName and esbCategoryName specifiy the name of the service, where the other two elements: bpmToEsbVars and EsbtoBpmVars specify which variables should be carried from jBPM to the ESB Message and back respectively. Koen Aers has been working on a special EsbServiceNode so all the configuration can be done in design view.
Creation of the rest of the process definition goes in a similar fashion, ending with an 'End' node, which when reached will terminate the process.
Step 2. Deployment
JBossESB deploys the jBPM core engine in a jbpm.esb archive. This jbpm.esb archive contains the jBPM core engine as well as the configuration and the jbpm-console. To deploy the process click on the 'deployment' tab in the IDE, selecting the files you wish to deploy and clicking on the 'Deploy Process Archive' button.
Figure 3. Deployment of the 'OrderProcess' Service Orchestration
Besides deploying the process definition we also need to deploy the services themselves. Your services are deployed in a yourservices.esb archive. For deployment order you need to specify a depends 'jboss.esb:deployment=jbpm.esb' in the deployment.xml.
Note that deployment of process definitions and esb archives is hot and does not require a server restart.
Step 3. Starting and Running the process
There a multiple ways to start an instance of the process that was deployed in step 2. For instance you can start one from your own code, the jbpm-console, but perhaps the easiest way is to start on using an out-of-the-box service. For instance when your store front receives the order you can create an EsbMessage with the invoice and drop it on the 'StartProcess' service.
You can define a StartProcess service (one for each process definition) in the jboss-esb.xml in yourservices.esb. For instance it can look like
where we use the 'StartProcessInstanceCommand' to invoke a new process instance of the type 'OrderProcess' and with the invocation we insert a business key (invoice ID) and the invoice itself into the jBPM process instance context. Now when a message hits this service a new instance of the shipping process is created and we can look at its state using the jbpm-console (by default running on http://localhost:8080/jbpm-console)
Figure 4. State of an instance of the 'OrderProcess' Service Orchestration
In Figure 4 the 'Review Order' process is highlighted because the process is waiting for a human to review the order. So here we now have integrated human work flow, see Figure 5!
Figure 5. 'Review Order' Human Work Flow Integration
Conclusion
We demonstrated that it is a three step process to use jBPM for Service Orchestration and how to integrate it with Human Work Flow. To get more details you can read the jBPMIntegrationGuide.
Have fun,
--Kurt
Figure 1. 'OrderProcess' Service Orchestration using jBPM
Step 1. Create the Process Definition
To create the process definition from Figure 1 you drag in components from the left menu bar. To start you'd drag in a Start node, followed by a regular 'node' type, which we gave the name 'Intake Order'. You can now connect the two boxes by selecting a 'transition', and by first clicking on the start node and then on the Intake Order node. Next we need to tell jBPM which JBossESB service backs this node. This is done by attaching a special 'EsbActionHandler' action to the node and configuring it to go out to the service 'InTakeService'. For now you will need to click on the 'source' tab to drop into the XML representation of this node (see Figure 2).
Figure 2. XML Source of the 'OrderProcess' Service Orchestration
In this case the configuration for the Intake Order the XML looks like
The first two subelements esbServiceName and esbCategoryName specifiy the name of the service, where the other two elements: bpmToEsbVars and EsbtoBpmVars specify which variables should be carried from jBPM to the ESB Message and back respectively. Koen Aers has been working on a special EsbServiceNode so all the configuration can be done in design view.
Creation of the rest of the process definition goes in a similar fashion, ending with an 'End' node, which when reached will terminate the process.
Step 2. Deployment
JBossESB deploys the jBPM core engine in a jbpm.esb archive. This jbpm.esb archive contains the jBPM core engine as well as the configuration and the jbpm-console. To deploy the process click on the 'deployment' tab in the IDE, selecting the files you wish to deploy and clicking on the 'Deploy Process Archive' button.
Figure 3. Deployment of the 'OrderProcess' Service Orchestration
Besides deploying the process definition we also need to deploy the services themselves. Your services are deployed in a yourservices.esb archive. For deployment order you need to specify a depends 'jboss.esb:deployment=jbpm.esb' in the deployment.xml.
Note that deployment of process definitions and esb archives is hot and does not require a server restart.
Step 3. Starting and Running the process
There a multiple ways to start an instance of the process that was deployed in step 2. For instance you can start one from your own code, the jbpm-console, but perhaps the easiest way is to start on using an out-of-the-box service. For instance when your store front receives the order you can create an EsbMessage with the invoice and drop it on the 'StartProcess' service.
You can define a StartProcess service (one for each process definition) in the jboss-esb.xml in yourservices.esb. For instance it can look like
where we use the 'StartProcessInstanceCommand' to invoke a new process instance of the type 'OrderProcess' and with the invocation we insert a business key (invoice ID) and the invoice itself into the jBPM process instance context. Now when a message hits this service a new instance of the shipping process is created and we can look at its state using the jbpm-console (by default running on http://localhost:8080/jbpm-console)
Figure 4. State of an instance of the 'OrderProcess' Service Orchestration
In Figure 4 the 'Review Order' process is highlighted because the process is waiting for a human to review the order. So here we now have integrated human work flow, see Figure 5!
Figure 5. 'Review Order' Human Work Flow Integration
Conclusion
We demonstrated that it is a three step process to use jBPM for Service Orchestration and how to integrate it with Human Work Flow. To get more details you can read the jBPMIntegrationGuide.
Have fun,
--Kurt
Subscribe to:
Posts (Atom)