When it comes to integration, some Web services advocates have promised everything short of solving world hunger. We've been told that Web services will streamline integration, provide a higher level of system interaction within companies, and promote robust B2B interactions. Ultimately these promises may come true, but the current trend in Web services technology actually complicates an integration battle already rife with challenges.
To date Web services efforts have focused on creating discrete XML-based interfaces to wrap existing applications and data. Web service proponents consider these standardized interfaces integration building blocks, claiming that integration will be a snap if you expose systems and data via a standard interface, such as WSDL. This concept of wrapping systems with standard interfaces is not new. Organizations have adopted standards such as COM, CORBA and EJB to normalize application interfaces. The goal has been to create a library of reusable components that encapsulate applications, data and business rules that can be connected to create new applications rapidly. Companies have spent significant time building these libraries only to discover that additional effort is required to integrate the components and create useful applications.
Having a component library does not mean you can drive business. Adopting standardized mechanisms to access disparate systems is one thing—getting those systems to interact is a different story.
Enter Web services, the new way to encapsulate and expose applications, data and business rules. Standards have evolved rapidly, and Web services has been positioned as the technology to drive future integration and B2B endeavors. Limited code binding, disparate data representation and shortcomings of other technologies have been eliminated, making it easier to wrap components. By using XML, based on Web Services standards, you can now wrap applications and data in a way that transcends the technology implementation. Factor in standards such as BPEL4WS and integration looks even easier.
The problem with this approach is the assumption—or requirement—that everything be "Web-service enabled" (Figure 1). This includes data stores, objects, components, applications and even companies. Early efforts have shown that this is problematic. Current tools and platforms are immature and focus almost exclusively on wrapping, without addressing the daunting task of integrating XML-based interfaces. This is more difficult than integrating components programmatically. Writing Java code to integrate components on an application server is fairly straightforward, but writing Java code to integrate XML documents is not. XML is great for data representation and messaging but not as a programming mechanism.
Figure 1: Building Web services for discrete system interactions
So, some questions arise. Are companies willing to dive headlong into a project that rewrites each component or wraps every system to the Web-services standard? Do they want to write the complex glue to manage interactions between XML documents? Can they afford to migrate continually to the newest standards—whatever they may be? What organizations want is to enable interactions with partners and customers. This is what Web services is about. Partners and customers don't care whether you use Web services internally.
This is where business process integration (BPI) comes into play. BPI emerged in the late 90s out of a need to reduce integration complexities. BPI's simplified approach may be the missing link that brings Web services to the next level. In the context of integration technology, a business process refers to any multi-step activity that manipulates data or business logic from multiple—generally incompatible—systems. Business process integration typically is described as the ability to automate business processes inside the firewall and with outside suppliers, partners and customers. BPI enables organizations to realize the benefits of streamlined B2B interactions without changing the underlying applications.
With the proliferation of data-centric EAI tools, message-oriented middleware and application servers, integration efforts have required significant investments in infrastructure and resources. Typical projects take 18 months or more. A majority of time is spent wrapping systems with common interfaces such as EJB or messages, writing glue code and implementing infrastructure. BPI eliminates much of this tedious work by providing robust infrastructure, simplified connectivity options and high-level tools to ease integration. Using BPI to tackle integration takes far less time than the conventional approach of wrapping objects and write glue code.
A good BPI product lets an organization orchestrate interactions between systems without going through the effort of wrapping (Figure 2). The BPI platform will manage system interactions regardless of each application's underlying technology. BPI tears down the walls that previously did not allow legacy systems to interact with packaged applications or COM objects to work with EJBs. BPI allows you to link systems together easily without forcing you to normalize interfaces before getting started.
Figure 2: Reducing layers and simplifying integration with BPI
BPI also brings a top-down approach that is missing from the Web services equation. The focus is on processes that must execute to complete a business transaction as opposed to the details of the interfacing mechanism or data representation. Business processes must drive integration efforts and be supported by internal applications and data. Once you can tie together, into a powerful process, a collection of interactions with individual components, systems or Web services, and expose the entire process as a Web service, you will have robust transactions that your partnersand customers can invoke. This is the true power of Web services. There is no intrinsic value to wrapping every system as a Web service, gluing them together and exposing the result as a Web service (Figure 3). As recent articles indicate, Web services is gaining acceptance as a way to streamline interactions between organizations rather than as a technology to integrate systems internally. The result of integration—a business process–should be exposed as a Web service.
Figure 3: Creating unnecessary complexity by "double-wrapping" with Web services
The Web services model provides a relatively straightforward approach for exposing, registering, locating and executing interactions between systems. It facilitates communication between enterprises, allowing each to participate in distributed transactions by exposing business functions or data in a standard way. So far these interactions have been fairly simplistic. Today's Web services track packages, get a quote, or look up a book. These transactions do not drive business. Companies need to expose transactions that add true value–not simple interfaces to discrete functions. Transactions such as place an order, purchase a product, or submit a claim will do far more for the bottom line.
Web services will enable cross-company business. As for internal integration efforts—companies are better off using BPI and taking advantage of systems as they are. In the context of a business process, all components and applications are treated equally, regardless of the standard or technology with which they were born. There is no need to expend resources to adopt yet another component standard. Once you integrate your processes and systems, simply expose your processes as Web services and begin doing business.
Copyright 2003, Metaserver, Inc. Reprinted with permission. Metaserver provides mid-market organizations and enterprise departments with a Business Process Integration (BPI) software solution that enables disparate systems to work together and be leveraged for new composite applications.
For More Information:
- Click here to visit our BPEL Learning Guide
- Click here for more articles on Business Process Integration
- Click here to visit our comprehensive glossary of terms and definitions