Advancing System Design & Data Management Through Process Modeling- Page 3

Untitled Document

In this article, I will attempt to steer you through the pitfalls of designing service-oriented architecture (SOA) applications using Business Process Execution Language or BPEL models.



The problems with designing application systems are many when drawing comparisons to the work of an architect designing a building. The rules, standards, principles and techniques utilized in architecture have been clearly defined and well understood for centuries. The guiding viewpoint for their designs have centered on equal parts of functionality and aesthetics.

Additionally, the cost of design failure can be catastrophic, thereby leading to considerable governmental regulation. Unfortunately, we have few of these benefits when modeling applications for our SOA integration systems.

This is not to say that we don't have some pretty good methodologies and design principles for guiding our work efforts -- we certainly do. We just don't execute them effectively or apply them in a timely fashion. Many times we feel rushed and compelled to meet an urgent emerging need with a quick solution with no thought to the overall strategy.

Enter process modeling

So what exactly is this concept known as process or BPEL modeling? These models are the technical progression of SOA modeling from multiple historical predecessors: flowcharts, data flow diagrams, program structure charts, UML models, Gantt and PERT charts to name a few.

When fully developed it is simply the process of linking together multiple deployed web services, which return standardized corporate data into an automated and sequential workflow. Through the process model, we utilize the deployed web services to provide the predominant business logic that will generate universal data relationships.

Then, wrapped around this logic we integrate conditional logic, branching, fault handling, iterative processing, parallel logic and sequential flow to complete the process model. Through the use of graphical tools, a designer can rapidly create a new model, search for services, integrate internal or external web services, visually represent the flow of activities, add and upgrade new tasks and deploy to an integration server.

We must remember that process modeling requires some significant infrastructure components to be in place to assure efficient utilization. First and foremost, it requires an integration server with a BPEL container environment for converting the BPEL XML into executable code. Second, it requires the use of an enterprise service bus to serve as the centralization point of standard services (security, logging, auditing, etc.) and to manage the routing, transformation and mediation of the SOAP message.

Third, it requires a rules engine as a repository of business rules for elevating business logic to the enterprise level. Finally, it requires a fully searchable UDDI repository for storing the Web Services Descriptive Language (WSDL) files generated for our deployed web services.

When we are developing our process models, we should keep in mind the concept of service component architecture (SCA) to clarify in our own minds what is deemed a callable enterprise service. Generally, we think that only deployed web services can be called in a process model.

However, the SCA concept reminds us that we can access anything that meets these simple rules: it can be described with a WSDL document, it has an interface, contains one or more operations and has a proper implementation. Thus, not only web services can be called, but also business rules, human tasks, state machines and other process models.

Applying process models

Now that we know more about the concept of process modeling, we should illustrate these concepts with an example. If we were going to develop a process model for processing orders from a website that was selling widgets, what would the scenario appear like?

Step 1: Our model accepts a standard order from a client that contains all order information (product info, credit card data, shipping preference, etc.). Our model assigns all of these values to internal variables.

Step 2: Upon receipt of the order, we need to check on available inventory. So we call an internal deployed service for the inventory system and pass it the product ID and requested quantity. We incorporate a basic conditional to insure appropriate quantity is available.

Step 3: If quantity is unavailable, we initiate parallel calls to each of our widget manufacturers and their corresponding external services to get their price quotes. We utilize a conditional to determine which price quote is the lowest. Finally, we initiate a call to the external service of the widget manufacturer to place an order.

Step 4: Next, we need to process the client's payment. We have enlisted a credit card processing outfit to manage all of our online payments. Thus, we simply execute this external service and pass all of the appropriate credit card information and await the authorization code. We incorporate a basic conditional to verify the authorization code to allow the sequence to continue.

Step 5: With the proper authorization in hand, we can continue to processing the shipment. If the quantity was available and on hand, we would call the external service for our shipping entity and pass all appropriate information and receive a confirmation number.

Step 6: Finally, we like to generate an email confirmation to the client. Therefore, we gather all of the confirmation information and client data and call an internal service that will generate the email. We'd return a completion message to the client and our model is complete.

Step 7: At appropriate points in our model, we'd need to perform basic exception handling and generate fault messages for the client.

Thus, we've completed a complete workflow model for handling order requests by sequentially processing a series of external/internal deployed services and controlling the flow by performing conditional tests. Once completed, we can deploy this process model to the integration server and it is ready to start processing orders.

Deploying successful models

Process modeling can't be viewed in a vacuum and there are many interrelated components required for developing and deploying successful models. During the design process, there are a series of basic principles I've adhered to that have proven to be very beneficial.

First and foremost, we must have a long-term plan effect. There is that old adage "Fail to plan, plan to fail." It could not be more fitting than when applied to the world of IT architecture design. Having been in the IT business for 30 years I have seen my fair share of wasted design efforts. The first step must be the visualization and dissemination of the long term goals of our corporate SOA integration efforts.

One of the underlying aspects of SOA implementations is their collaborative nature. Integration in the SOA world requires a high degree of interaction and support from both the IT and client community to be effective and successful. The creation of an advisory panel, composed of representative individuals from all communities, is recommended to define the goals and mitigate the direction and is a key ingredient of success.

Another supporting principle is the recognition of the delineation of roles. Upon entering the realm of SOA integration development, we must recognize that certain prerequisite skills are required and successful SOA projects will require individuals in multiple roles.

These roles include: developers developing our granular web services, enterprise architects controlling overall architectural control, business analysts interfacing with clients and developing system prototypes and integration developers that will be creating and fine tuning process models and communicating with all other individuals.

An interwoven principle is the integration of basic governance strategies. Developing process models will incorporate service components from many different applications within our corporate architecture. Thus, creation of standard governance policies regarding service development, data management, deployment and adherence to these policies is crucial.

For our applications to be successful, we must recognize the basic infrastructure prerequisites necessary for our implementation. The development of process models is a fairly sophisticated technique within the realm of SOA application development. Thus, it requires the implementation of specific infrastructure components: discoverable services, a rules engine, a fully developed UDDI Registry, an Integration Server with a BPEL container and an enterprise service bus with deployed routing rules.

The most common mistake enterprises make in their hurried pace to implement services is the incorporation of a complete workflow as a web service. They end up exposing a service that is both a data and time intensive process that when combined in a process model will tend to set new records for performance inefficiency. I tend to call this the Iceberg principle, because in process modeling we don't foresee the full impact of enacting a service. Services need to be driven to the lowest possible level, thus allowing us to avoid the Iceberg principle where the service performs far more activity than required.

The last, and one of the more crucial principles, is the deployment of a UDDI Registry. Having a common repository to publicize the existence of available and deployed services should not be underrated. Not only does it provide a common library of available components for our process models, it also serves as a vehicle for enforcing the rules, standards and policies implemented under the corporate governance umbrella.

Planning makes perfect

If your goal is to create and deploy an efficient and effective SOA architecture, then you'll need to realize that this process is not as simplistic as a vendor's toolset or presentation will imply. It is long and arduous process full of complex decisions that requires stringent goal setting, careful planning, proper infrastructure implementation, efficient dissemination of data, adherence to governance and resistance to the quick solution. Process models are an integral ingredient in any SOA implementation, and understanding the components upon which they are dependent will greatly increase your probability of success.

About the Author

Michael Deskis is actively involved in consulting, mentoring and training in the Service-Oriented Architecture environment for GoGogh.com. and is a primary principal with OnsiteSeminar LLC. His passion is to guide organizations through their design, modeling and development processes for their enterprise integration efforts to insure their success.

More by Michael Deskis