INTRODUCTION
In large organizations, typical systems portfolios consist of a mix of legacy systems, proprietary applications, databases, off-the-shelf packages, and client-server systems. Software systems integration is always an important issue and yet a very complex and difficult area in practice. Consider the software integration between two organizations on a supply chain; the level of complexity and difficulty multiply quickly. How to make heterogeneous systems work with each other within an enterprise or across the Internet is of paramount interest to businesses and industry.
Web services technologies are being developed as the foundation of a new generation of business-to-business (B2B) and enterprise application integration (EAI) architectures, and important parts of components as grid (www.grid.org), wireless, and automatic computing (Kreger, 2003). Early technologies in achieving software application integration use standards such as the common object request broker architecture (CORBA) of the Object Management Group (www.omg.org), the distributed component object model (DCOM) of Microsoft, and Java/RMI, the remote method invocation mechanism. CORBA and DCOM are tightly coupled technologies, while Web services are not. Thus, CORBA and DCOM are more difficult to learn and implement than Web services. It is not surprising that the success of these standards is marginal (Chung, Lin, & Mathieu, 2003).
The development and deployment of Web services requires no specific underlying technology platform. This is one of the attractive features of Web services. Other favorable views on the benefits of Web services include: a simple, low-cost EAI supporting the cross-platform sharing of functions and data; and an enabler of reducing integration complexity and time (Miller, 2003). To reach these benefits, however, Web services should meet many technology requirements and capabilities. Some of the requirements include (Zimmermann, Tomlinson & Peuser,2003):
• Automation Through Application Clients: It is required that arbitrary software applications running in different organizations have to directly communicate with each other.
• Connectivity for Heterogeneous Worlds: Should be able to connect many different computing platforms.
• Information and Process Sharing: Should be able to export and share both data and business processes between companies or business units.
• Reuse and Flexibility: Existing application components can be easily integrated regardless of implementation details.
• Dynamic Discovery of Services, Interfaces, and Implementations: It should be possible to let application clients dynamically, i.e., at runtime, look for and download service address, service binding, and service interface information.
• Business Process Orchestration Without Programming: Allows orchestration of business activities into business processes, and executes such aggregated process automatically.
The first five requirements are technology oriented. A solution to these requirements is XML-based Web services, or simply Web services. It employs Web standards of HTTP, URLs, and XML as the lingua franca for information and data encoding for platform independence; therefore it is far more flexible and adaptable than earlier approaches.
The last requirement relates to the concept of business workflow and workflow management systems. In supply chain management for example, there is a purchase order process at the buyer’s side and a product fulfillment process at the supplier’s side. Each process represents a business workflow or a Web service if it is automated. These two Web services can be combined into one Web service that represents a new business process. The ability to compose new Web services from existing Web services is a powerful feature of Web services; however, it requires standards to support the composition process. This article will provide a simplified exposition of the underlying basic technologies, key standards, the role of business workflows and processes, and critical issues.
WHAT ARE “WEB SERVICES”?
The phrase “Web services” has been defined in many different ways (Castro-Leon, 2002; Ambrosio, 2002). In the working draft of Web Services Architecture (W3C, 2003), it is defined as:”…a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”
A simplified Web service architecture based on this definition is conceptually depicted in Figure 1.
Main features of Web services are that services (Burner, 2003):
1. Expose programmable application logic.
2. Are accessed using standard Internet protocol.
3. Communicate by passing messages.
4. Package messages according to the SOAP specification.
5. Describe themselves using WSDL.
6. Support the discovery of Web services with UDDI.
7. Are loosely coupled.
WEB SERVICES TECHNOLOGIES
Three XML-based protocols—one for communication, one for service description, and one for service discovery—have become de facto standards (Curbera et al., 2002). They are:
• SOAP (the Simple Object Access Protocol) provides a message format for communication among Web services.
• WSDL (the Web Services Description Language) describes how to access Web services.
• UDDI (the Universal Description, Discovery, and Integration) provides a registry of Web services descriptions.
Another area of importance in Web services is the capability of constructing new composite Web services from existing Web services. Many standards in this area are being developed (Van der Aalst, 2003), for example, Business Process Execution Language for Web Services (BPEL4WS) by IBM and Microsoft (Fischer, 2002). It is not clear if there will be a common standard. However, regardless of the differences among vendor groups, the composition of Web services uses the concept of business processes and workflow management.
As noted earlier in this article, the development and deployment of Web services do not require a particular platform, nevertheless most Web services development is being accomplished today using either Microsoft .NET or Sun Microsystems’ J2EE specifications (Miller, 2003). It is not clear which of the two competing platforms is most suitable for the developers and their future directions (Miller, 2003; Williams, 2003).
Figure 1. A simplified Web services architecture (W3C, 2003)
THE ROLE OF BUSINESS PROCESSES AND WORKFLOW MODELING IN WEB SERVICES COMPOSITION
The need to integrate software components within and across companies is to economically re-use components for supporting business processes automation. A business process such as borrowing a topic from a library may involve: ‘check user identification’, ‘enter call numbers’, and ‘generate a receipt’ activities. Each activity in the business process is a piece of work and is performed according to a sequence defined by business rules. That is, a business process contains a workflow (Allen, 2000).
The Workflow Management Coalition (Norin & Shapiro, 2002) defines the business process as:“.a set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally with the context of an organizational structure defining functional roles and relationships.”
Workflow management is further defined as:“.the automation of a business process, in whole or part, during which documents, information, or tasks are passed from one participant to another for action, according to a set of procedural rules.”
To understand complex business processes, workflow modeling techniques provide logical descriptions of the flow of activities that achieves the goal of the process. Companies compete to provide workflow-based tools for Web-service integration (Ganesarajah & Lupu, 2002). Such tools allow developers to use the concept of workflow to build complex business processes from Web services. Since a complex business process contains a large number of activities, managing the execution of these activities, (e.g., monitoring the workflow progress, sending activities to the right servers, and scheduling activities for execution) can be critical. The advent of the workflow management system or the workflow engine software is to serve this purpose.
Existing methods for creating business processes are not designed to work with cross-organizational components and Web services platforms (Peltz, 2003). This gives rise to multiple Web services standards for business process modeling and execution (Van der Aalst, 2003). However, regardless of standards, the composition of Web services requires the modeling (and construction) of a Web service from one party perspective and the interaction among each involved party. This is accomplished by using business process and workflow modeling in two aspects: 1) specifying internal details of the composition to offer an executable business process, and 2) planning the message sequences between parties and sources. The former is called orchestration and the latter is called choreography in creating business processes from composite Web services (Peltz, 2003).
OUTSTANDING AND CHALLENGING ISSUES IN WEB SERVICES
Web service technology is still emerging, and researchers are still developing important functionalities for meeting technical and business requirements. Although some Web service standards such as SOAP, WSDL, and UDDI have been widely accepted, others such as Web services composition language are being developed by many organization and industry groups (Van der Aalst, 2003). These languages build upon the concept of workflow management systems to allow for orchestrating a group of required Web services in support of a business process. Due to real-world demands for more complex business problems integration, many companies and standards organizations have built extensions to the core specifications. Unfortunately, few of these extensions are interoperable. To resolve this problem and ensure application interoperability and extensibility, the W3C (2003) is developing a formal Web service architecture. There are different competing approaches (Kleijnen & Raju, 2003) to this problem, notably, the ebXML specifications suite, an independent technology for business-to-business integration (Patil & Newcomer, 2003). Additional challenges lie in XML and Web services security standards (Naedele, 2003). Obviously, the creation and support of Web service standards for mission-critical applications is a challenging, complex, and time-consuming process. Figure 2 adapted from W3C (2003) shows more completely the critical service areas of Web services.
A brief explanation of some Web service architectural components follows:
• Packing/Transport: This is the message layer that packs information into messages and transports it between parties.
• Service/Interface: Describes operational interfaces of a Web service.
Figure 2. A Web service architecture
• Composition/Choreography: Describes how services interact with each other in business processes.
• Agreements: The service level agreement defines the specific performance, usage, costs, and so forth, and the business level agreement defines a contractual agreement between the two business partners in business engagement using Web services.
• Security Management and Quality of Service: Describes reliability and security characteristics.
Each component has varying degrees of achievement by industries and standard setting organizations. However, standards are not enough to realize the great expectations of Web services. Langdon (2003) describes several key inhibitors of Web services adoption, including the lack of complementary service providers for metering, accounting, and billing services; the lack of ready-to-use Web services from either internal sources or third parties; and the lack of third-party support of how to decompose an automation problem and how to deliver it.
CONCLUSION
Web services involve many technologies and standards. Although a very young field, it has made tremendous progress in the last two years. Software vendors like Microsoft’s .NET and Sun’s J2EE have tools for Web services development. However, the field has many challenging issues, with standards being one of them. This article provides an overview of Web services in general and the role of workflow in developing a Web services application in particular. Since workflow modeling in the composition of Web services utilizes knowledge of business processes, that is where MIS professionals should be actively involved.
KEY TERMS
EAI: Projects involving the plans, methods, and tools aimed at modernizing, consolidating, and coordinating the computer applications and data in an enterprise.
Grid Computing: A form of distributed computing that involves coordinating and sharing computing, application, data, storage, or network resources across dynamic and geographically dispersed organizations.
HTML (Hypertext Markup Language): A standard language for representing text, formatting specifications and hyperlinks.
HTTP (Hypertext Transfer Protocol): The standard for requesting and transmitting information between a browser and a Web server.
Java/RMI: A Java application programming interface known as remote method invocation.
Protocol: A set of rules and procedures governing transmission between two points in a network.
URL (Universal Resource Locator): A text string used as a reference to a Web resource. A URL consists of a protocol, a host name, and a document name.
XML (Extensible Markup Language): An extension of HTML that is being extensively used for transmitting data/information on the Internet.
