member login

WebServices dot org

Todays Featured Content:

Progress Software Announces Availability of Sonic ESB 7.6

New Sonic ESB Release Expands Functionality with Improved SOA Management and Enhanced BPEL Instrumentation

Implementing a Successful Service-Oriented Architecture (SOA) Pilot Program

Service-oriented architecture (SOA) provides the framework to re-architect IT infrastructure, eliminate redundancy and accelerate project delivery. Many organizations struggle to identify, implement and build on their first SOA forays.

Featured Content provided by Progress Sonic

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