Web Services, SOAs, and Integration

Today, we’re still in an early phase for Web Services and SOAs. The traditional mindset that needs changing is the view that Web Services are an extension of the component object model. To many developers, Web Services are simply “another interface to a compiled object.” Instead, enterprises should approach SOA as fundamentally a process-driven architecture that leverages distributed processes in addition to distributed Services.

Distributed processes are all about the creation of business processes that in turn depend on other business processes that may be defined anywhere in the organization. Such distributed, SO processes are the key to composite applications that run on an SOA.

Approaching SOAs and Web Services from this perspective simplifies and clarifies many of the troublesome issues relating to distributed computing and Web Services. Today, integration goes from being a troublesome chore that must be accomplished through implementing increasing layers of complicated and expensive technologies. In the SOA world, integration becomes a side effect of process execution. In fact, it’s virtually impossible to create an important business process that does not provide the fundamental benefits of application and business integration. The mere act of orchestrating a composite application achieves most integration goals.

The goals of integration are the same as the goals that business process approaches promise. Businesses today rely on an ever increasing number of systems and services to fulfill their business requirements. As a result, almost every survey of IT department issues has shown that the primary concern of enterprises is integration. Integration, or the ability to connect multiple systems together to accomplish a given business objective, is often very difficult to achieve cost-effectively. Most enterprises need to integrate legacy applications, enterprise systems, data sources, and applications of all sorts within the enterprise. This need to integrate internally is compounded by desires to integrate with external parties such as suppliers, partners, customers, and other third-parties. An often-attempted approach to simplifying integration problems and reducing the cost of integration is the use of common interfaces to application functionality. However, common interfaces are not enough to change the economics of integration. Simply replacing proprietary interfaces with standard, common interfaces just reduces the development cost of having to deal with multiple interface formats. What is needed is a change in the way systems interact with each other, not the particular language or technology they use to communicate.