Sharing structured data

XML Magazine

Subscribe to XML Magazine: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get XML Magazine: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

XML Authors: Jayaram Krishnaswamy, Chris Pollach, Jason Bloomberg, Peter Silva, Mehdi Daoudi

Related Topics: Java EE Journal, Artificial Intelligence Journal, XML Magazine

J2EE Journal: Article

Business Process Management of Web Services

Business Process Management of Web Services

Creating a Web service is not a technology story that's limited to applications talking XML to one another and using registries. Rather, the real endgame is enabling companies to deliver useful services to key constituencies ­ employees, customers, and partners. To cite Metcalf's Law, a single Web service interfacing entity on the network is of little value. However, as Web services grow in number, they grow in value exponentially because they present the potential for new combinations.

Integration plays a pivotal role in the delivery of Web services. Ranging from encapsulation of data objects as Web services to the transformation of Web services from one system to another, integration solutions can add tremendous technical capabilities to an entire Web services infrastructure. In fact, a key integration concept, business process management (BPM), represents one of the most critical elements of composing Web services into complete applications, This article highlights how organizations can elegantly achieve this goal with BPM tools.

BPM concepts, including modularity, routing, and automation, are all critical elements of Web services. After all, Web services are service objects that can be inserted into larger solutions in a modular fashion; interactions with Web services depend on messages being routed to and from them; Web services have description files which allow for automatic discovery. BPM tools should be used to incorporate various Web services to produce composite applications that actually serve a business function. In other words, the value of establishing a Web services-ready infrastructure will be realized by the coordination of multiple Web services ­ in the intelligent BPM-driven integration of the separate components.

BPM tools have to extend beyond the traditional programmer environment to include line-of-business managers and analysts who are often responsible for delivering these services. With traditional IDEs, the developer works with segments of code such as functions or libraries, but BPM tools operate at a higher level of abstraction than code. With BPM tools that coordinate Web services, the user works with entire applications or services. BPM tools allow for the orchestration business activity.

Evolution of BPM
Unfortunately, the numerous terms used in the BPM space have given rise to confusion. The legacy of "workflow," "process automation," and even "BPR" (business process reengineering) all contribute to the confusion over what's meant by BPM. The development of Web services has given rise to even more applications of BPM concepts, and led to greater misunderstanding. The following stages outline the evolution of BPM from pre-Internet days to its current applicability with Web services.

Stage 1: Workflow before the Internet
Workflow applications before the takeoff of the Internet were employee productivity tools delivered via desktop applications, often integrated with document routing and document version control. Automation at this level bypassed interoffice mail and manual reentry of data.

Stage 2: EAI and Process Automation
When IT departments and software engineers divorced the workflow components of these applications from the document management portion and then applied it to systems management, the enterprise application integration software advanced to a new level of sophistication and agility. The concept of capturing business rules to route work from one employee to another was transferred to machines in order to manage the communication between two applications, with goals of even higher throughput rates and greater data integrity.

Stage 3: Application Servers and Component Coordination
With the rise of Internet browsers and the Java programming language, employee productivity tools were no longer limited to desktop applications, and applications created by integrating disparate legacy systems can be given a Web front. Java components could be used to present Web forms to employees or to invoke existing applications. Process automation then took on the role of component coordination. "Work" flowed from one JSP, servlet, or EJB to another. Web interaction through JSPs allowed for manual inputs into the process; automated steps are captured by servlets or EJBs. BPM tools in this group combine human workflow and machine process automation and managed the entire process.

Stage 4: Web Services and Business Process Management
Even with more mature tools, integrating applications within one company is no small task. With Web services, BPM tools need to apply concepts such as code reuse and graphic modeling to multiparty application development. While in its early inception stage, Web services can and will be used in intraenterprise applications as an integration standard; the greater value proposition of Web services lies within a business-to-business context. In fact, BPM applied to Web services can be thought of as a standard means to B2B integration or even B2BPM. Following are some of the ways that BPM tools can enable Web services:

  • B2B Integration and B2BPM: For starters, a successful Web services infrastructure will often include elements such as a business-to-business friendly messaging system and a lingua franca for the messages to be passed. The new Web services­related standards such as ebXML and SOAP address these needs. The ebXML specification includes an entire section on Message Handling Service (MHS) that describes the transport, routing, and packaging (TRP) of messages to be passed between partners. The SOAP specification describes how SOAP-based XML messages can serve as the common message format. Messaging protocols and formats are the areas in which the standards are first maturing. Currently, software vendors are most active in this area. Building on top of the messaging system, BPM tools can be used to establish exchange patterns, conduct the flow of intercompany communications, and automate processes at a business transaction level.
  • Service Description and Collaboration Modeling: In addition to taking part in the orchestration of Web services at runtime, BPM tools can have a role in creating the Web service descriptions needed for registries and repositories. Web service descriptions will not only contain basic business function identifiers and contract definitions, but by adhering to specifications such as BPSS (Business Process Specification Schema), these descriptions can represent inter-enterprise processes within the XML-formatted description file. Such descriptions hold process-related information such as what to do with a virtual purchase order once it has been received, what and when information needs to be sent back to the business partner who posted the Web service, and in what order each step should be carried out. BPM tools offer a way to model this business level collaboration through a graphic user interface and then generate the necessary description file.
  • Service Registry and Dynamic Discovery: Furthermore, BPM tools can be extended to dynamic discovery of services as well. As Web services adoption grows, more and more public services become available, and registries are well populated, process tools will adopt features that enable dynamic discovery of Web services. This is the final frontier of Web services: the ability to go to an outside source for a service before knowing the source. In order for dynamic discovery to become a reality, the following tasks would need to be automated:
    - Detecting when the process needs to go to an external source; i.e., in an expense reporting application, an up-to-date currency converter is required
    - Knowing which registries to research and in which order
    - Keeping track of the time restraints on the discovery process
    - Initiating a negotiation when description of a service that fits the requirements is found
    - Negotiating the terms on which the communication between the two entities will be conducted

    Carefully crafted processes will capture the business logic needed to conduct such discovery and negotiation processes without manual intervention, thus instilling a level of artificial intelligence into Web service­incorporating applications. Extending the analogy of the process manager as the central nervous system, advanced BPM tools in the Web services world have the potential to turn once-conscious activities into autonomic functions.

  • Service Orchestration: Monitoring and Enforcement: The potential exists for BPM tools to expand their relevance over the entire life cycle of a Web service. Once discovered and engaged, how will Web services be monitored? How will the rules of engagement be enforced? Such process management challenges are nothing new to BPM tools of the past. Traditionally, they've included administrative consoles with various views of the activity and interactivity they create. These monitors are no less important with the inclusion of Web services. In essence, the process monitors themselves will be monitored to ensure that the terms established during the negotiation phase are being adhered to. For example, a Web service procures certain widgets for a company from another for a certain price. The price may have been promotional and has now expired. Once an internal procurement application tries to call on this Web service again, the request is rejected; it's in violation of the contract. BPM tools with enforcement capabilities could detect this and stop any further requests for this service or even initiate a search for a replacement service.

    As outlined above, the utility and ubiquity of BPM concepts are clear. Different analyst groups may propose slightly varying taxonomies, and just about every software datasheet contains similar terminology. In order to discern the differences and find the right tool for the job you must understand scale. Different BPM tools may have been optimized for process integration at different levels of granularity.

    Take, for example, a very large, long-established company with IT shops in various departments. During the early '90s they streamlined their business by taking out manual steps where they could and integrating large packaged applications and mainframes with some of the custom work they had done. Let's say that the department in this case was the Shipping department and the streamlined process involved integrating the various package-tracking systems. It's very possible that an EAI-style BPM tool was used here.

    In the late '90s, the same company changed their focus from direct mail to online catalogs. In order to advance from simple online brochures to an e-commerce­enabled Web site, the company needed to further integrate its processes; the online catalog had to be integrated with the billing department and the inventory system as well as the shipping process mentioned above. Keeping with the object-oriented programming model, each newly developed part was developed as a Java component. A single servlet running on a J2EE application server was written to trigger the shipping process. The component-coordinating BPM tool treated this application as one node in the larger order fulfillment process.

    Today, the company has the option of starting a wholesale business, selling directly to a reseller partner. From the point of view of the partner, the entire order fulfillment process could be encapsulated as a Web service called "procure widget (see Figure 1)." The partner may have solicited this service from several different vendors in hopes of a finding the lowest price. The process involved in this bidding will also benefit from BPM tools to give it shape.

    The example above describes how a process may be nested in another process, which is in turn nested in another. The final process happens to be one that spans company boundaries and does so in a very specific Web service­compliant way.

    A complete Web services­enabled BPM tool can present an internal application as a Web service and manage all the processes involved in creating, describing, and registering Web services. Furthermore, it should be able to find, negotiate, elicit, and monitor Web services. This is a rather tall order. Expect the first entrants into the market to resemble traditional BPM tools with an added feature: the ability to call on Web services into its process when necessary (see Figure 2).

    Just as Web services are a natural progression of networked computing, message-oriented-middeware, and object-oriented programming, BPM tools continue to evolve, making the gradual transition to a Web-services style of B2B integration. This change will track the development and adoption of Web­ services­related standards. Initially, the up-front investments required in establishing a homogenous way for businesses to communicate electronically will seem great, but the potential for return on that investment is much greater. BPM tools have the potential to bury much of the complexity, offer an easier user interface for soliciting Web services, and provide greater impetus for adopting Web services in the enterprise architecture.

  • More Stories By Christen Lee

    Christen Lee is a product marketing manager at Sun Microsystems. She is repsonsible for marketing iPlanet Integration Server and iPlanet Message Queue, as well as tracking emerging integration technologies, with a special focus on business process management.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.