If you've read my previous posts, you know a couple of colleagues and I are in the process of developing a business process using various SOA product suites. The intent is to go beyond the typical hand held tutorials that vendors provide and understand what it really takes to develop composite applications in an existing enterprise.
To that end, I have already learned a good bit. For instance, WSDLs and Schemas are not always provided for you, sometimes you actually have to create them.... and it is not always drag and drop and whammo, you created a business process... and just because you have a web service doesn't mean it drops easily into a BPEL process. That's just a small taste of what I have discovered so far, and I know there is plenty more to come.
As I have stated earlier, I am using the Cape Clear ESB to implement our business process. Well, over the past couple of weeks, I haven't had much time to progress from Step 2. That is mainly due to some Sun Java CAPS training we received (and being able to attend the SD West conference). As a result of this training, I am going to shift my implementation from Cape Clear to Java CAPS for the time being. Once I complete the implementation in Java CAPS, I do plan to return to the Cape Clear implementation.....and I will still be relaying the things I encounter along the way with both products....in case you were worried :)
Stay tuned....
Monday, March 26, 2007
Friday, March 16, 2007
Step 2: Accessing the CRM System
My excursion into the "real" world of SOA has already been a learning experience. As mentioned in my original post in this series (The Beginning), the intent is to move away from the vendor propaganda and canned tutorials and implement a business process from the ground up using different SOA products. This way I can understand first hand what it takes to service enable existing applications, the implications of various system interfaces that can be encountered in an Enterprise, and the challenges to deal with when trying to build a composite application with pre-existing systems. In order to do this, several of my colleagues and I have created a Virtual Enterprise (described here).
So far, we have encountered the need to introduce a new service into our Virtual Enterprise due to the granularity of some of our Enterprise Applications (specifically the IVR and Email systems). We also began to realize that SOA products don't always support some of the deployed technologies within an Enterprise. As described in my previous post (Receive a JMS Message), I had to workaround the fact that Cape Clear did not support our Virtual Enterprise messaging standard of ActiveMQ. Also, Cape Clear expects all messages to be SOAP messages our Alert system doesn't communicate via SOAP.
This is all good stuff. I am starting to accomplish exactly what I set out to....experience SOA in the real world. Now on to the next challenge....invoking a web service (RPC encoded style) to retrieve a set of participants in my event.
This task seems pretty straightforward. Call a web service, get a set of people back and use this set to send out some notifications. Cape Clear likes everything to be a web service, so what could be easier. Just define the partner in your BPEL process using the WSDL from the CRM web service, drag and drop....and now you can use the CRM system in my process.
Cape Clear has a very easy way to define a partner within a BPEL process. Simply walk through a wizard which requests a WSDL (either file, URL, or Cape Clear Server based), asks you to define the partner type (in this case I will be invoking this partner), and like magic it creates the necessary variables to be used in your BPEL based on the schemas defined in the WSDL. Based on the operations exposed within the WSDL, the appropriate actions also become available to your BPEL process. From there it's good old drag and drop the action onto the BPEL process, use the variables created during the partner definition......and viola, you just included this external system in your business process.
Here is where I encountered my next challenge. Recall that this web service is using RPC encoded style SOAP and returns an array of people. The variable that Cape Clear (and I learned later any current BPEL engine) creates is a simple variable type. Well, I am trying to work with a complex array of people. Something isn't right here. After much research, struggles, research, struggles and a submission to the Cape Clear forum I decided I needed a work around.
While waiting to hear back from the Cape Clear folks, I decided to wrap the CRM systems RPC style web service with a document/literal style web service. Then I could use the document/literal web service in my BPEL process. Sounds like a good bit of overhead, but that is for a later topic.
So, I attempted to create a simple web service that calls another web service. This is great....Cape Clear allows me to create a project for exactly this purpose. So, first I create a schema that will represent the return type of my new wrapper web service. This schema essentially defines an element containing an unbounded number of people elements.
Now, I fire up the Cape Clear wizard to create a web service that invokes another web service. I point at my RPC style web service and.....low and behold....the wizard cannot handle the WSDL. Great....now what. I decide to try create a web service client in a standard Eclipse IDE I have installed (BTW....the Cape Clear IDE is Eclipse with some plugins) and everything worked fine. So now I submit my second post to the Cape Clear 7.0 Beta forum (I was still waiting on a response to the earlier post).
In the mean time, I create a WSDL based on the schema I created earlier for my new wrapper web service. If you never created a WSDL from scratch before....it's a good learning experience. Once I had the WSDL defined, I created a Java Web service to implement the WSDL. I then had to copy in the classes from my external Eclipse project that would allow me to call the RPC style web service into my new Cape Clear project. I now had one project that represented a web service that would call another web service. I deployed this to the Cape Clear Server and was now able make the call out to the CRM web service through my new wrapper web service.
After this was completed and functional, I got my reply from Cape Clear. They informed me that "RPC/encoded style of WSDL is not supported by BPEL. The problem is that according to the rules of SOAP encoding, the messages does not conform to the structure defined by the XML Schema". Their recommendation was to do exactly what I ended up doing...create a web service that wraps the RPC/encoded style web service (although they recommended RPC/literal). They also indicated that "The local call to the new web service will be very efficient, so it shouldn't cause any performance problems". Again, that is for a later topic.
Good thing these tools make it so easy to build a business process :)
So far, we have encountered the need to introduce a new service into our Virtual Enterprise due to the granularity of some of our Enterprise Applications (specifically the IVR and Email systems). We also began to realize that SOA products don't always support some of the deployed technologies within an Enterprise. As described in my previous post (Receive a JMS Message), I had to workaround the fact that Cape Clear did not support our Virtual Enterprise messaging standard of ActiveMQ. Also, Cape Clear expects all messages to be SOAP messages our Alert system doesn't communicate via SOAP.
This is all good stuff. I am starting to accomplish exactly what I set out to....experience SOA in the real world. Now on to the next challenge....invoking a web service (RPC encoded style) to retrieve a set of participants in my event.
This task seems pretty straightforward. Call a web service, get a set of people back and use this set to send out some notifications. Cape Clear likes everything to be a web service, so what could be easier. Just define the partner in your BPEL process using the WSDL from the CRM web service, drag and drop....and now you can use the CRM system in my process.
Cape Clear has a very easy way to define a partner within a BPEL process. Simply walk through a wizard which requests a WSDL (either file, URL, or Cape Clear Server based), asks you to define the partner type (in this case I will be invoking this partner), and like magic it creates the necessary variables to be used in your BPEL based on the schemas defined in the WSDL. Based on the operations exposed within the WSDL, the appropriate actions also become available to your BPEL process. From there it's good old drag and drop the action onto the BPEL process, use the variables created during the partner definition......and viola, you just included this external system in your business process.
Here is where I encountered my next challenge. Recall that this web service is using RPC encoded style SOAP and returns an array of people. The variable that Cape Clear (and I learned later any current BPEL engine) creates is a simple variable type. Well, I am trying to work with a complex array of people. Something isn't right here. After much research, struggles, research, struggles and a submission to the Cape Clear forum I decided I needed a work around.
While waiting to hear back from the Cape Clear folks, I decided to wrap the CRM systems RPC style web service with a document/literal style web service. Then I could use the document/literal web service in my BPEL process. Sounds like a good bit of overhead, but that is for a later topic.
So, I attempted to create a simple web service that calls another web service. This is great....Cape Clear allows me to create a project for exactly this purpose. So, first I create a schema that will represent the return type of my new wrapper web service. This schema essentially defines an element containing an unbounded number of people elements.
Now, I fire up the Cape Clear wizard to create a web service that invokes another web service. I point at my RPC style web service and.....low and behold....the wizard cannot handle the WSDL. Great....now what. I decide to try create a web service client in a standard Eclipse IDE I have installed (BTW....the Cape Clear IDE is Eclipse with some plugins) and everything worked fine. So now I submit my second post to the Cape Clear 7.0 Beta forum (I was still waiting on a response to the earlier post).
In the mean time, I create a WSDL based on the schema I created earlier for my new wrapper web service. If you never created a WSDL from scratch before....it's a good learning experience. Once I had the WSDL defined, I created a Java Web service to implement the WSDL. I then had to copy in the classes from my external Eclipse project that would allow me to call the RPC style web service into my new Cape Clear project. I now had one project that represented a web service that would call another web service. I deployed this to the Cape Clear Server and was now able make the call out to the CRM web service through my new wrapper web service.
After this was completed and functional, I got my reply from Cape Clear. They informed me that "RPC/encoded style of WSDL is not supported by BPEL. The problem is that according to the rules of SOAP encoding, the messages does not conform to the structure defined by the XML Schema". Their recommendation was to do exactly what I ended up doing...create a web service that wraps the RPC/encoded style web service (although they recommended RPC/literal). They also indicated that "The local call to the new web service will be very efficient, so it shouldn't cause any performance problems". Again, that is for a later topic.
Good thing these tools make it so easy to build a business process :)
Wednesday, March 14, 2007
First Step: Receive a JMS Message
This blog continues the story from my previous post (The Virtual Enterprise). In this installment I will describe what I had to go through in order for my business process to receive an XML message from a JMS queue (using ActiveMQ as the provider). Recall that I am implementing my business process using Cape Clear.
As a point of clarification, I have yet to receive any formal training in Cape Clear's product and am attempting to implement my business process by referring to documentation and tutorials available on Cape Clear's developer web site (http://developer.capeclear.com/). To Cape Clear's credit, they do have a good amount of documentation available to the public. Just to make it a little tougher, I chose to use Version 7 of their product, which (at the time of my effort) is in beta (some may call me a glutton for punishment).
In Cape Clear's world, everything is a web service communicating using SOAP. Also, as for supported JMS providers, ActiveMQ is not among them. They do support (out of the box) IBM, BEA, and JBoss. As an additional piece of information, my Cape Clear installation is deployed on JBoss (other options include BEA, IBM, Tomcat).
So, here is problem number 1 (or is that challenge number 1). How do I get a JMS XML message (non-SOAP) sitting on an ActiveMQ message queue to kick off a business process (BPEL) deployed to Cape Clear?
Just to be specific, there are actually 2 problems here. First, using ActiveMQ as the JMS provider, and second, handling a non-SOAP message. Looking back (after a little teeth grinding and mental cursing), the solution was "easy".
First, I configured the JBoss server to access an ActiveMQ broker running on another machine. This part was fairly straightforward using the ActiveMQ resource adapter. I followed directions that I found here (modified for my specific versions of the products and to use a remote broker in place of the embedded broker). Once I got this working, the next step was to configure the Cape Clear server to route messages on this ActiveMQ queue to my new BPEL process. This was accomplished by configuring a "transport" on the Cape Clear server. I essentially created a JMS JBossMQ transport, but in place of the standard connection factories and queue names, I used the JNDI names for the ActiveMQ connection factories and queue names that I configured with the ActiveMQ resource adapter. And then, like magic, I was able to receive messages from an ActiveMQ queue.
Now, how do I get the BPEL process to handle a non-SOAP message. Fortunately, as I stated earlier, Cape Clear has a good amount of documentation and tutorials on their site. I was able to find an example of handling non-SOAP XML messages in an Orchestration Web Service (i.e. a BPEL process deployed as a web service). This tutorial was created for version 6 of their product, but works as well on version 7. Essentially what happens is that you define an XSLT transformation to wrap a non-SOAP message in the appropriate SOAP header and body tags to make it a SOAP message. This XSLT is applied prior to invoking the BPEL process by configuring an interceptor for the BPEL process deployed within the Cape Clear server. How much this additional step potentially impacts performance is TBD and will be addressed sometime later in my road to discovery :). I wonder why Cape Clear just doesn't make that a configuration option for a BPEL web service and then perform some sort of optimized operation to receive the non-SOAP message, or skip the SOAP message parsing entirely and just pass the message directly to the BPEL?
Anyway.....there you have it. I can now accept a non-SOAP message from an ActiveMQ queue and invoke my BPEL process deployed to Cape Clear. So simple a monkey could do it ;) ......got any bananas?
As a point of clarification, I have yet to receive any formal training in Cape Clear's product and am attempting to implement my business process by referring to documentation and tutorials available on Cape Clear's developer web site (http://developer.capeclear.com/). To Cape Clear's credit, they do have a good amount of documentation available to the public. Just to make it a little tougher, I chose to use Version 7 of their product, which (at the time of my effort) is in beta (some may call me a glutton for punishment).
In Cape Clear's world, everything is a web service communicating using SOAP. Also, as for supported JMS providers, ActiveMQ is not among them. They do support (out of the box) IBM, BEA, and JBoss. As an additional piece of information, my Cape Clear installation is deployed on JBoss (other options include BEA, IBM, Tomcat).
So, here is problem number 1 (or is that challenge number 1). How do I get a JMS XML message (non-SOAP) sitting on an ActiveMQ message queue to kick off a business process (BPEL) deployed to Cape Clear?
Just to be specific, there are actually 2 problems here. First, using ActiveMQ as the JMS provider, and second, handling a non-SOAP message. Looking back (after a little teeth grinding and mental cursing), the solution was "easy".
First, I configured the JBoss server to access an ActiveMQ broker running on another machine. This part was fairly straightforward using the ActiveMQ resource adapter. I followed directions that I found here (modified for my specific versions of the products and to use a remote broker in place of the embedded broker). Once I got this working, the next step was to configure the Cape Clear server to route messages on this ActiveMQ queue to my new BPEL process. This was accomplished by configuring a "transport" on the Cape Clear server. I essentially created a JMS JBossMQ transport, but in place of the standard connection factories and queue names, I used the JNDI names for the ActiveMQ connection factories and queue names that I configured with the ActiveMQ resource adapter. And then, like magic, I was able to receive messages from an ActiveMQ queue.
Now, how do I get the BPEL process to handle a non-SOAP message. Fortunately, as I stated earlier, Cape Clear has a good amount of documentation and tutorials on their site. I was able to find an example of handling non-SOAP XML messages in an Orchestration Web Service (i.e. a BPEL process deployed as a web service). This tutorial was created for version 6 of their product, but works as well on version 7. Essentially what happens is that you define an XSLT transformation to wrap a non-SOAP message in the appropriate SOAP header and body tags to make it a SOAP message. This XSLT is applied prior to invoking the BPEL process by configuring an interceptor for the BPEL process deployed within the Cape Clear server. How much this additional step potentially impacts performance is TBD and will be addressed sometime later in my road to discovery :). I wonder why Cape Clear just doesn't make that a configuration option for a BPEL web service and then perform some sort of optimized operation to receive the non-SOAP message, or skip the SOAP message parsing entirely and just pass the message directly to the BPEL?
Anyway.....there you have it. I can now accept a non-SOAP message from an ActiveMQ queue and invoke my BPEL process deployed to Cape Clear. So simple a monkey could do it ;) ......got any bananas?
The Virtual Enterprise
As discussed in my previous blog (The Beginning), my associates and I are going to implement a single business process with an Enterprise. This Enterprise consists of 5 systems that have defined system interfaces. We call this our Virtual Enterprise. It is virtual in the sense that it does not exist within any Corporate Enterprise, but they are real functioning applications. These applications were designed and built by my associates and I, but done so in an independent manner, as if they grew up in a real Corporate environment. Keep in mind that they are simplified versions of what one might find in a real Enterprise, but the intent is really to create a business process based off of pre-defined system interfaces. In order to provide flexibility into our Virtual Enterprise, the interfaces that each system supports can be changed simply by modifying some configuration parameters. This allows us to modify some of the restrictions of the Enterprise for determining capabilities of various SOA product suites.
Let me introduce the systems:
(1) The Alert System. This system will record information about an event. It is web based and can release the event information via JMS to a defined ActiveMQ queue. The structure of the event is specified in an XML schema.
(2) The CRM System. Here we can define employees, customers, etc. and group them together in some logical fashion. This is our people repository. This system has an RPC encoded style SOAP interface for retrieving groups of people, individuals, and the set of groups defined within it.
(3) The Scheduler. This systems provides the ability to schedule a get together (conference call, meeting, etc.). Provided some information such as number of participants, dates and times, it will provide a logical meeting place (conference call code, etc.). This application is EJB based and can be accessed via RMI.
(4/5) The Notification System. This system is responsible for notifying participants in the get together. The reason I label this 4/5 is that it is really wrapping 2 separate systems (an IVR system and an Email system). When we defined this Virtual Enterprise, we decided that participants in the get together could be notified either by email or voice. As we began to review the Enterprise and look at the Business process we were implementing, we realized that these systems were a bit fine grained for an SOA. We therefore decided to wrap these in what we call a Notification Service. This notification service will provide a more coarse grained interface to the underlying systems. This was lesson #1 for our Real World SOA. The underlying IVR system has a document literal SOAP interface and the Email system has an SMTP interface (shocking). We are allowing the Notification system to be defined using the strengths of any given SOA product we are evaluating. This is really intended to test some of the product suite capabilities for building a service as opposed to the true service enabling of existing applications.
Now that you know the systems involved, the use case is fairly straight forward (ha ha). The alert system will create an event that people need to get together and discuss. Therefore our business process has to determine what people need to get together, where they are getting together, how to contact them, manage their responses over time, and provide status back to the alert system as the process progresses. If a person is not available then contact their alternate. Sounds simple enough, but when you dig deeper there is a good bit going on here.
Subsequent blogs will provide more information as to the issues encountered along the way, potential or actual workarounds, struggles with the products, etc.
Stay tuned........
Let me introduce the systems:
(1) The Alert System. This system will record information about an event. It is web based and can release the event information via JMS to a defined ActiveMQ queue. The structure of the event is specified in an XML schema.
(2) The CRM System. Here we can define employees, customers, etc. and group them together in some logical fashion. This is our people repository. This system has an RPC encoded style SOAP interface for retrieving groups of people, individuals, and the set of groups defined within it.
(3) The Scheduler. This systems provides the ability to schedule a get together (conference call, meeting, etc.). Provided some information such as number of participants, dates and times, it will provide a logical meeting place (conference call code, etc.). This application is EJB based and can be accessed via RMI.
(4/5) The Notification System. This system is responsible for notifying participants in the get together. The reason I label this 4/5 is that it is really wrapping 2 separate systems (an IVR system and an Email system). When we defined this Virtual Enterprise, we decided that participants in the get together could be notified either by email or voice. As we began to review the Enterprise and look at the Business process we were implementing, we realized that these systems were a bit fine grained for an SOA. We therefore decided to wrap these in what we call a Notification Service. This notification service will provide a more coarse grained interface to the underlying systems. This was lesson #1 for our Real World SOA. The underlying IVR system has a document literal SOAP interface and the Email system has an SMTP interface (shocking). We are allowing the Notification system to be defined using the strengths of any given SOA product we are evaluating. This is really intended to test some of the product suite capabilities for building a service as opposed to the true service enabling of existing applications.
Now that you know the systems involved, the use case is fairly straight forward (ha ha). The alert system will create an event that people need to get together and discuss. Therefore our business process has to determine what people need to get together, where they are getting together, how to contact them, manage their responses over time, and provide status back to the alert system as the process progresses. If a person is not available then contact their alternate. Sounds simple enough, but when you dig deeper there is a good bit going on here.
Subsequent blogs will provide more information as to the issues encountered along the way, potential or actual workarounds, struggles with the products, etc.
Stay tuned........
Subscribe to:
Posts (Atom)
Posts
