When dealing with Web services, or any service-level integration technology, you must understand the notion of service frameworks and how they differ from more traditional frameworks. This is the idea behind composite applications, which are applications made up mostly of back-end application services. Service frameworks, in contrast to object frameworks, lack inheritance. Although they provide services, they generally don't provide access to the source code for the distributed objects, making it difficult though not impossible (depending on the tool or language) to modify or extend the behavior of distributed objects (e.g., Web services) and service frameworks for an application. As such, service frameworks are the best fit for most application integration problem domains. Distributed object frameworks, including Web services, provide the best example of service frameworks in that they allow applications to invoke application services that are encapsulated in centrally located distributed application services. Distributed objects, such as those created around CORBA and COM, offer a common approach to create and deploy objects. CORBA-compliant distributed objects are sold through a number of third-party vendors. The Distributed Component Object Model (DCOM) comes with the infrastructure of the Windows operating system. The goal in addressing an integration problem domain is to create a set of distributed objects, using either technology, and then to access those objects either locally or remotely through a well-defined interface from the application that needs a service. For example, distributed objects are built into service frameworks to provide access to accounting functions, financial trading functions, database access functions, and so on. Distributed objects also provide the "plumbing" for easy access to objects that reside on network-connected computers. As we have noted, object frameworks tend to be tool and language dependent. Distributed objects represent one of the best hopes for frameworks because they offer tool- and language-independent frameworks for applications. C++, PowerBuilder, Delphi, and Smalltalk applications can all access distributed object services. The ability to mix and match components allows application integration architects to purchase expertise they may not already possess. For example, vertical-market component vendors from the petroleum, financial, and retail industries offer developers specialized functionality that requires little or no custom coding. In contrast to object frameworks, service frameworks usually contain fewer features and functions than applications, but they provide more services than a simple program function or object (see Figure 4.6). In a number of respects, components are "retro." They adhere more to the modular program model of the past than to object-oriented development. Figure 4.6. Service frameworks contain fewer features than object frameworks.
|