The Basics

Service-Oriented Application Integration (SOAI) allows enterprises to share common application services as well as information. Enterprises accomplish this sharing either by defining application services they can share, and therefore integrate, or by providing the infrastructure for such application service sharing. Application services can be shared either by hosting them on a central server or by accessing them interapplication (e.g., through distributed objects or Web services).

Attempts to share common processes have a long history, one that began more than ten years ago with multitier client/server a set of shared services on a common server that provided the enterprise with the infrastructure for reuse and now provides for integration and the distributed object movement. "Reusability" is a valuable objective. A common set of application services among enterprise applications invites reusability and, as a result, significantly reduces the need for redundant application services and/or applications.

Although most application services exist for single-organization use, at times it makes sense to share between organizations. In a new twist on the longstanding practice of reusability, we now hope to expand this sharing beyond intraenterprise to external enterprises as well for example, sharing common logic to process customers' credit requests or to calculate shipping costs. This is the notion of Web services, the ability to access remote application services through a well-defined interface (Web Services Description Language, or WSDL), directory (Universal Description, Discovery and Integration, or UDDI), and transport protocol (Simple Object Access Protocol, or SOAP).

Unfortunately, we have yet to achieve absolute reuse on the enterprise level. It is a more distant goal between enterprises. The reasons for this failure are primarily political. They range from internal politics to the inability to select a consistent technology set. In most cases, the actual limit on reuse results directly from a lack of enterprise architecture and central control. With Web services in the picture we now have another opportunity to create an infrastructure that facilitates the sharing of application services as well as information. However, there is a long way between "we're able to do this" and "we've done it." Indeed, it is an evolution in thinking as well as the implementation of technology.

What Is an Application Service?

Good question. Here's a better question: How does an application service differ from information integration?

When using an application service, we leverage a remote method or behavior versus simply extracting or publishing information to a remote system. Moreover, we typically abstract this remote service into another application known as a composite application (see Figure 4.1).

Figure 4.1. A composite application is the aggregation of many remote applications into a single application.

graphics/04fig01.gif

A good example of an application service is a risk analysis process, which runs within an enterprise to calculate the risk of a financial transaction. This remote application service is of little use by itself, but when abstracted into a larger application for example, a trading system then that remote application service has additional value.

Note that we leverage the behavior of this remote service more than the information it produces or consumes. If you're a programmer, you can view application services as subroutines or methods; something you invoke to make something happen.

The basic notion of SOAI is to leverage these remote services using some controlled infrastructure that allows applications to invoke remote application services as if they were local to the application. The result (or goal) is a composite application made up of many local and remote application services. Think about the possibilities.

Application integration gives us the tools and techniques to learn how to share common application services. More than that, these tools and techniques create the infrastructure that can make such sharing a reality. By taking advantage of this opportunity, we can integrate applications to share information, even as we provide the infrastructure for the reuse of business logic.

Although IOAI generally does not require changes to source or target applications, SOAI does require changes to most if not all enterprise and B2B applications in order to take advantage of the paradigm. This downside makes the service-oriented approach a tough sell between enterprises. Web services promise to change this, putting everyone on the same technology standards, so to speak, but there are still some changes that inevitably have to occur within source and target systems in support of Web services. In other words, most systems that we desire to leverage using SOAI are existing systems, built prior to the arrival of Web services (or other SOAI technology, for that matter). Those systems will have to be changed or rebuilt from scratch.

As noted in Chapter 1, changing applications is a very expensive proposition. In addition to changing application logic, we need to test, integrate, and redeploy the application within the enterprise a process that often causes costs to spiral upward (see Figure 4.2).

Figure 4.2. As the number of changes to source or target applications increases, so do the costs.

graphics/04fig02.gif

When to Leverage SOAI

By now, some of you may be a bit confused about SOAI and its use when establishing B2B connections between two or more organizations. Although many businesses are looking to exchange information with enterprises, and even to participate in shared processes, few are looking to create applications that share application services with systems not under their control.

However, in some instances, SOAI is a good fit.

  • When two or more companies need to share common program logic, such as the calculation of shipping costs from a common supplier, which constantly changes.

  • When two or more companies want to share the development costs and the value of a common application.

  • When the problem domain is small and specialized, and is able to collaborate on a common application that all companies share.

A clear example of the potential benefit of SOAI is the simple binding of two or more applications in order to integrate both business processes and data. Let us assume that two applications exist within a given enterprise. One application is C++ based and runs on a Linux machine. The other is an NT-based client/server application written in Java on the front end, with Sybase serving as the back-end database.

Confronted with these independent applications, the application integration architect seeks to create a composite application using SOAI techniques and technology. To accomplish this, the applications need to be tightly coupled so that common business logic can be shared and the business logic of both applications can be exposed to other applications for future use.

Unlike other application integration levels, at the service level, the architect has no option but to rebuild the applications to support SOAI. The architect has only two choices in determining how to accomplish this. One, she can move much of the business logic to a shared server, such as an application server. Two, she can rebuild each application using an application service-sharing mechanism, such as distributed object technology, to create a tightly coupled application that allows easy cross-accessing of application services.

If the architect decides the second choice is the most attractive, she will have to "wrap" the application logic encapsulated inside both applications. To accomplish this, she will use a distributed object technology (CORBA, COM+, or perhaps Web services) that provides a common mechanism to share application services remotely. This will require rewriting the applications and then testing them. Fortunately, this task is not as daunting as it might appear. Tools exist for each environment to wrap each application, re-creating the applications as truly distributed systems able to share both application services and data.

Even with such tools, the process is laborious. For example, if both applications need to add a common customer to their systems, they may invoke different application services; for example:

 Add_Cust(); 

on the Linux/C++ system and:

 AddNewCustomer(); 

on the NT/Java system.

By using a distributed object standard or a custom programming solution, the architect could expose each application service. As a result, she could bind the application services, or invoke one or the other. Once the application services are bound, the applications move to a coupled state where application services and data are easily shared within both domains, thus solving the application integration problem.

Before embracing the invasiveness and expense of SOAI, enterprises must clearly understand both its opportunities and its risks. Only then can they objectively evaluate its value. The opportunity to share business logic that is common to many applications therefore making it possible to integrate those applications represents a tremendous benefit. However, that benefit comes with the very real risk that the expense of implementing SOAI will outpace its value.



Next Generation Application Integration(c) From Simple Information to Web Services
Next Generation Application Integration: From Simple Information to Web Services
ISBN: 0201844567
EAN: 2147483647
Year: 2005
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net