Home
 > Research and Reports > TEC Blog > Understanding SOA, Web Services, BPM, and BPEL Part Two: ...

Understanding SOA, Web Services, BPM, and BPEL Part Two: BPEL and User Recommendations

Written By: Predrag Jakovljevic
Published On: December 23 2004

Web Services Orchestration

Increasing demand-driven responsiveness towards customers' needs requires a well-coordinated set of IT infrastructure components, since it is no longer good enough to purchase disparate pieces and expect them to simply interoperate. The ideal should be a sort of an independent data exchange that would leverage common metadata and processes to create composite functionality derived from existing application and Web services assets, which are kept in a repository for dynamic, almost on-the-fly assembly in, for example, a role-specific portal, with context-sensitive data for all types of users and business decision makers.

Web services orchestration, what makes Web services work, is a two-step process:1) publish first, and then 2) orchestrate (i.e., integrate these published Web services and coordinate messages between them to create business processes). In other words, orchestration involves three main elements: 1) coordination, including asynchronous communications, parallel processing, event handling, business transaction protocol (BTP), clustering, and scalability; 2) management, including administration, cancellation and change management, exception and timeouts, and version control; and 3) activity monitoring, which includes business reporting, audit trailing, and non-repudiation. As should be seen from the above depiction, the loosely coupled nature of Web services components can create complexities, such as the need for coordinating asynchronous messaging, which is not occurring at predetermined or regular intervals.

The term asynchronous is usually used to describe communications in which data can be transmitted intermittently rather than in a steady stream (e.g., a telephone conversation is asynchronous because both parties can talk whenever they feel like it). Otherwise, if the communication were synchronous, each party would be required to wait a specified interval before speaking. The difficulty with asynchronous communications is that the receiver must have a way to distinguish between valid data and noise. In computer communications, this is usually accomplished through a special start bit and stop bit at the beginning and end of each piece of data, and for this reason, asynchronous communication is sometimes called start-stop transmission.

Since some services are to be available across the entire enterprise, which often might mean across continents, they must be evocable across both local area networks (LAN) and wide area networks (WAN). The time delays involved in such long-distance communication might logically require that services should be relatively "coarse-grained", that is, they would not be invoked too often, and should do substantial amounts of work in response to each call.

This is Part Two of a two-part tutorial.

Part One discussed SAO, Web services, and BPM.

BPEL

Business process execution language (BPEL)-based products work by encapsulating the orchestration facilities necessary to coordinate, manage, and monitor service-oriented business processes. For the Java camp, that could be achieved through exposing these facilities to developers through a Java server page (JSP)-like component called ScenarioBean that is based on industry standards such as XML, SOAP, WSDL, Java Message Service, BTP and electronic business XML (ebXML). In addition to the ScenarioBeans, which enable Java developers to compose multiple Web services and user interactions, the products typically feature two other primary components: 1) the orchestration server and a 2) Web service orchestration console for administering the services.

In a somewhat simplified language, while Web services allow applications to easily exchange and reuse information, it is only when they are orchestrated (coordinated) into long-running business flows or processes that enterprises can realize their true value.

That is where BPEL comes into picture, which, also known as BPEL4WS, is an XML-based language for standardizing business processes in a distributed or grid computing environment that enables separate businesses to interconnect their applications and share data. The language provides a standard programming language that businesses can use to define how to combine Web services to accomplish tasks. The WS-Coordination specification thereby describes how the individual Web services within that task will interact, whereas the WS-Transaction standard will ensure that all the transactions are either successfully completed or fail as a group. In the Web services protocol stack, BPEL is a layer on top of WSDL, which it uses to specify actions that should take place in a business process, and to describe the Web services provided by a business process.

Designed as a combination of proprietary IBM's Web Services Flow Language (WSFL) and Microsoft's XML business process language in BizTalk Server (XLANG) specifications, platform-independent BPEL allows enterprises to keep internal business protocols separate from cross-enterprise protocols so that internal processes can be changed without affecting the exchange of data from enterprise to enterprise. A BPEL document, for example, keeps track of all the business processes that are connected to a transaction and ensures that the processes are executed in the correct order through the automation of messages.

Being a standards-based format for transferring processes between platforms while remaining platform-independent, BPEL is now looking like an important element in the taxonomy of Web services and BPM, given BEA and SAP are also supporters. Former Collaxa has long declared its support for BPEL and Oracle now consequently boasts the above-mentioned high-profile users of its engine.

For example, customers could now supposedly use recently released or re-branded Oracle BPEL Process Manager to orchestrate processes deployed across either a Java or Microsoft's .NET infrastructure. Oracle might rightfully assert that its product is the only native BPEL server on the market. However, several nominally non-native BPEL product from Oracle application server competitors, including BEA and webMethods, enable import and export between BPEL and their own proprietary formats, such as through partnerships with The Middleware Company. Although having mighty backers, BPEL still remains one of a number of emergent standards in the general area of BPM. Others would be Web service choreography interface (WSCI), which is still also backed by BEA, Intalio, SAP, and Sun Microsystems, and a number of other specifications like business process modeling language (BPML) or XML processing description language (XPDL). There are also some aspects that BPEL currently does not address, such as complex transformations, data translation, trading partner agreements, manual (human) processes, and connectors to specific back-office systems.

For that reason, large enterprises will still tend to look to other more complete solutions or even to the above mentioned BPM, SOA, and Web services specialist vendors to create, manage, and orchestrate complex, high-volume processes that include people, structured data, unstructured content, and exceptions handling.

User Recommendations

Although the widespread acceptance of Web services inter-enterprise implementations will not happen any time soon, the major players' involvement in leveraging these should prompt large global enterprises to start learning the new protocols, standards and technologies in order to grasp the potential underlying business advantage of abating the traditional problems of integration, while focusing more on the processes underlying IT systems than the actual technology. They should try to grasp how developers will leverage Web services, SOA, and BPM, what their ongoing needs are, and what intricacies may arise from their utilization, such as cultural and standards issues, in addition to many essential features such as reliability, security, scalability, performance, and manageability.

To casual and power users of business applications on a desktop, conversion to SOA should be fairly transparent, which is not the case with the army of IT staffers though, for which the move will represent a significant reworking of the IT infrastructure that is typically a complex mishmash of disparate technologies.

On the other hand, major ERP providers should partner with the above-mentioned Web services software firms on UDDI registries, management platforms, security, and ESB functionality, and build support for Web services into their products, as to give their customers compelling reasons to keep their current ERP instance as a core part of their future SOA blueprint. For example, vendors should explore using SOAP messaging for communications and integration to other applications within the user enterprise, or wrap WSDL around the existing product to expose the functionality for use in evolving users' business processes. For more information, see Rewrite or Wrap-Around Old Software?.

While SOA and Web services may make integration easier through some imposed interoperability, they will not eliminate the need for venerable application integration via adapters, connectors, or so, since they are not any kind of panacea. The SOA is not an answer to everything, since it is still often possible and more viable to synchronize disparate systems using data integration that is typically more coarse-grained and with less business logic than SOA (e.g., it would transfer entire purchase orders, rather than change the description of a single line in a single purchase order as might happen with a human interface).

Also, although these new concepts may provide new business opportunities and create some dynamism and efficiency , they are not going to transform businesses on their own, given that they are only a piece of new technology. Even if large organizations are the first to dabble with deploying Web services, their impact will ultimately be also felt by companies that supply products and services to consumers, regardless of their size. Enterprises should scrutinize the applications they already have and then define what services it is that they really need. Even many latest applications that are already SOA-enabled might still be at a low level of business abstraction, while ironically, some legacy applications might be easier to encapsulate and integrate.

Businesses can already create and utilize Web services that can be reused by other applications, such as services to authorize credit card or to authenticate a person's identity while logging onto several systems. Yet, to fully benefit from Web services and SOA, companies should carefully and painstakingly reexamine their business processes and best practices and look for the efficiencies a revamped infrastructure could bring. The starting point for building a SOA blueprint would be to identify and create Web services around common business reference objects for the entire organization, which will be largely dependent on the organizational strategic alignment and the industry in case.

Likewise with a public and private Internet exchanges comparison, Web services seem to have more potential within a trusted environment of business partners. Hence, in addition to the question whether BPEL will be the prevailing standard, there is the question whether the enterprises will be willing to share their business process models with one another. Organizations evaluating Web services and SOA may benefit from following the pertinent consortia activities, while those that have already leveraged Web services may benefit from joining it so as to share the experiences with their peers and to make sure that the consortium focuses on their business issues. However, as the consortium cannot impose much authority on vendors and as it is not performing compliance testing at this stage, users should question vendors directly on compliance to the standards.

Before customers make any attempt at choosing products or suites of products for EAI, middleware, Web application servers, or other software solutions that require seamless interoperability, they must be sure they understand the difference in the approaches used by J2EE and .NET. For additional information see Understand J2EE And .NET Environments Before You Choose. While one of the main goals of Web services was to make the platform choice less important, that reality is still a long way off. Despite anyone's platform preference and the roster of programmers with certain skill sets, it is therefore prudent to gather as much as possible information from both camps, as both will have their pros and cons.

Although competition typically results in both camps keeping each other on their toe tips to be more creative, it does not help users and prospects now. They should thus question vendors closely on which approach they are (or will be) taking in their current and future releases, and why. Once the choice is made, it will be difficult, although not quite impossible, to switch or abridge. Since application integration efforts are costly, complex and time-consuming, the decision may come back to haunt you if you do not choose wisely. Users must recognize that making a choice for an application server should encompass the entire stack (portal, personalization, directory, etc.).

The niche specialist Web services and BPM vendors should be considered, although within a tactical mindset and with a reasonably quick and justifiable feedback. In general, the market should stay very close to the commonly accepted standards, and beware of any vendor that is inclined to create much dependence on its proprietary technology, as it leads to unjustifiable price increases, and a declining openness in the future.

 
comments powered by Disqus
Popular Searches

Recent Searches
Others A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

©2014 Technology Evaluation Centers Inc. All rights reserved.