Categorization of Open Standards
In the world of application integration we can divide standards into three categories: service standards, format standards and orchestration standards.
Service standards, including Web services, seem new but in fact are very old. Early attempts at standardizing service-oriented interfaces, such as OMG's CORBA and Microsoft's COM, have a long history in the world of IT. They both have attempted to provide access to program services that exist on remote computers without the need to understand any of the low-level details such as location, APIs, etc. Instead, they placed a common interface layer on top of the native services, allowing remote programs to both discover and invoke these services.
Web services are really just another instance of this model. By leveraging common Web protocols, Web services seem to be getting more traction than their predecessors. Web services also deliver a lot to the application integration world as well, providing common interfaces and protocols which allow standard-based communication and service invocation from machine to machine, either local or over the Internet.
Despite the usual drawback of emerging technology, Web services - or at least the notion of Web services - are an interesting technology for the world of inter- and intra-company application integration. Web services hold the promise of moving beyond the simple exchange of information - the dominating mechanism for application integration today - to the concept of access application services that are encapsulated within old and new applications. This means we can not only move information from application to application but also create composite applications, leveraging any number of back-end application services found in any number of applications, local or remote.
The key to this concept is determining how Web services fit into existing application integration technology and approaches. For example, when is the use of a Web service appropriate and how do we determine cost-effectiveness? Keep in mind: implementing Web services is bound to be an invasive process, thus more expensive when compared to enabling systems for simple information exchange.
Format standards are those standards that define a common way of formatting information so that it is understood as it is being shipped from application to application. EDI, XML and SOAP (messaging) are examples of format standard with XML leading the charge as the dial tone for application integration in many problem domains.
Format standards are not as complex as service standards; the only requirement is that both the source application and target application are able to understand each other. XML is particularly helpful since the meta data comes along for the ride; however, that also means that the amount of information sent from point to point is much larger than more traditional binary messages, a trade-off that many have accepted.
Orchestration standards, such as BPEL4WS, layer a set of easily defined and centrally managed processes on top of existing sets of processes/services contained within a set of enterprise applications, intra- or inter-organization.
We can think of orchestration as the science and mechanism of managing the movement of data and the invocation of services in the correct and proper order to support the management and execution of common processes that exist in and between applications. Orchestration provides another layer of easily defined and centrally managed processes that exist on top of an existing set of processes and data contained within a set of applications.
The goal is to bring together relevant processes found in an enterprise or trading community to obtain the maximum amount of value, while supporting the flow of information and control logic between these processes. These products view the middleware, or the plumbing, as a commodity and provide easy-to-use visual interfaces for binding these processes together.
Evolving Approaches in Leveraging Open Standards
Let's review the fundamentals. Application integration is innate to almost all business system development. Applications can no longer exist as standalone entities, but instead must share information with other information systems, inside and outside the corporations. Indeed, we've been moving closer to a well-integrated enterprise and (in some instances) supply chain that provides most information systems with access to information from other applications when needed, and in real time. We can call this information-oriented application integration. This is the most popular way of doing application integration today, and it leverages format standards such as the ones listed above.
However, as we're getting better at real time information exchange between systems, the trend has been to view application integration at a higher level of abstraction, or through business processes or services. This approach allows those exchanging information between various applications to view the information flow in the context of a business model, or business processes that define business logic, sequence, sub-processes, hierarchies of processes, etc. In other words, the ability to control application integration through abstract business process automation abstractions that also accounts for lower level mechanisms such as transformation and intelligent routing. We can call this orchestration-oriented application integration.
While information-oriented and orchestration-oriented integration provides a functional solution for many application integration problem domains, it is the integration of both application services and application methods that generally provides more value in the long run, albeit at a cost
