member login

WebServices dot org

Todays Featured Content:

SOA Platform 30-Day Free Evaluation Subscription

The JBoss Enterprise SOA Platform includes service oriented architecture (SOA) open source middleware such as JBoss Enterprise Service Bus (ESB), JBoss jBPM, JBoss Rules and the JBoss Enterprise Application Platform to integrate applications, services, transactions, and business components into automated business processes.

JBoss calls for SOA reality check

Service oriented architectures are not about building a grand software vision, says JBoss.

Who's the BOSS? JBoss Seam and JBoss Rules, of course

InfoWorld recently awarded the Best Open Source Software for the Enterprise (aka the 2007 InfoWorld Bossies).

JBoss Enterprise Middleware

JBoss Enterprise Middleware is an extensible and scalable suite of products for creating and deploying e-business applications, offering cutting-edge technology components which customers can mix-and-match and roll out into their line of business infrastructure - all at zero-cost software licenses.

Featured Content provided by JBoss, a division of Red Hat

Business Process Validation

John Michelsen
13th Nov 07:

One of the primary goals of SOA is to model applications closer to the way that business processes actually function.

One way to define a business process is through a language called BPEL (Business Process Execution Language, or “Bee-Pill”) that allows us to create models using business-process type terms that would represent the actual system behavior in the backend of IT applications.

From a validation standpoint we try to take a simplistic approach--if we’re not careful--of trying to import these BPEL models as if they are tests of the processes themselves.

The problem with this approach is that it ignores the fact that testing is actually a verification of business or technical outcomes, not a defined procedure. What we have to do is cause the business process to happen – think of that as “Step One” of a business process validating test. But the remaining steps of the validation may have nothing to do with the business process steps as understood by the process model. Once a business process is in motion, you have to validate the expected technical outcomes of the process.

Let’s use an example: If placing an order within a SOA based application occurs by creating an xml document that represents that order and putting it on a message queue —let’s say that is the cause of a particular business process. Of course, the responsibility of that process as modeled in a BPM tool is to take the xml doc that represents the order and create the inventory transactions, create the shipping and order management transactions, update the CRM system and then close out the order or set the order status to some certain processed state.

How would we validate the business and technical outcomes of this process? Well it would start by causing that process to function. Step 1 then is to create that XML document and drop it on the queue. Great. Then what? Well this requires the an understanding of the outcomes, not the steps of the process. But let’s hope they help shed light on this...

We might have to check the system of record to confirm the order was placed. We might have to asynchronously listen on another message queue and interrogate the message payload for proper content to ensure the shipping system is properly instructed. We might have to refresh a web browser to prove that the end-to-end process completed in the acceptable amount of time.

Alas, very little of that is stored in BPEL :(

Then how can the business ever hope to validate thier business process models when the validation sounds like a bunch of bits and bytes? Ah, we have been working on that problem for years and have a elegant solution if I do say so. In another blog I’ll introduce the concepts and resist the urge to make it an iTKO LISA commercial.


Trackback URL for this post: http://www.webservices.org/trackback/id/88156