Chapter Seventeen. The Verticalization of Application Integration Technology

Chapter Seventeen. The "Verticalization" of Application Integration Technology

It has been a clear trend in the world of application integration to customize solutions for particular problem domains, such as vertical industries. This means providing specific connectors, formats, transformation, and behaviors that have value for verticals such as finance, manufacturing/retail/distribution (MRD), telecommunications, health care, and other areas that have particular application integration requirements, inter- or intracompany.

Typically, vertical application integration solutions are built around standards such as RosettaNet, UCCnet, and ebXML (see in-depth coverage in Part III) for MRD; HIPAA for health care; and GSTP, Omgeo, and SWIFT for finance. However, we'll spend the most time on supply chain integration as a concept, which is becoming more important as we move closer to the real-time economy.

What you need to get out of this chapter is the simple fact that application integration is no longer just about connecting one application to another; sometimes it is a business application unto itself, with the support of an underlying application integration infrastructure including the use of well-defined interoperability standards and mandatory behaviors. By the time this book is published, this will be even more apparent, which is why this is a long, but very important, chapter.

Clearly, middleware is taking on properties that are more business application-like, something that flies in the face of the traditional middleware role of linking one application to the next. At the time middleware first appeared, EAI had not yet emerged as a new set of technologies and a new discipline, so the notion of domain-specific middleware seemed a bit far-fetched.

Today, it's a new world. As we look to add more value to application integration, many application integration technology vendors have announced their movement into more vertical domains, including finance, health care, and manufacturing.

So, why create vertical-specific subsystems for application integration? It's really about providing more out-of-the-box value to the end user, moving well up the stack to business process and logic layers, and creating reusable behavior applicable to a vertical business domain such as finance, health care, manufacturing/retail/distribution (MRD), and telecom. Moreover, specific standards-based connectivity and transformation solutions provide value, such as HIPAA processing for health care, or GSTP (Global Straight Through Processing) TFM (Transaction Flow Manager) connections for finance. We can also add supply chain integration to that list using standards such as ebXML, RosettaNet, and EDI.

This is a bit of a paradigm shift for traditional application integration technology vendors that dealt with primitive technology such as routing and transformation rather than specific business applications containing both business logic and business application schemas. While vendors did deal with vertical domains, in most cases, they applied custom one-off solutions, with few components transferable to similar problem domains. The end users had to foot the bill for the custom development work as well as absorb future maintenance costs.

Application integration vendors have to understand much more than the connectivity technology. They must understand business requirements to support a true business application. As such, the industry is rethinking what ultimately drives application integration, and it is moving toward a solutions-oriented type of offering. These product offerings do things that would previously be described as "unnatural acts," moving from general-purpose horizontal middleware to the subsystems that are vertical specific.

To understand the shift in thinking, it's helpful to refer to a reference model (see Figure 17.1). As with any layered model, the lower levels are the most primitive in function.

Figure 17.1. Vertical subsystems sit on top of the application integration stack.

graphics/17fig01.gif

Resource adapters, the lowest level of services in the stack, provide the connectivity into any number of source or target systems using standards such as XML, EDI, Web services, or JCA, or more likely, proprietary packaged application interfaces or direct database access. Furthermore, you may have specialized vertical-oriented adapters here including connections to the GSTP TFM adapters, HIPAA, EDI, ebXML, RosettaNet, and so on. The common pattern is consumption and production of both information and schema and, in some cases, adhering to a standards-based processing requirement. This is also where service-oriented access occurs.

Integration services, which encompass traditional integration server functions, would include the transformation and routing of information that make the information sharable among many different applications and standards. New here is the abstraction of application services, using newer standards such as Web services or perhaps distributed objects.

This layer enables the integration server to employ remote application behavior and fit this behavior inside a composite application or business process. Service-Oriented Application Integration is valuable to vertical markets that are considering the reusability aspect of this paradigm, and thus the reusability of business applications that may now be combined with more traditional application integration capabilities.

Process execution and modeling is, in essence, the business process modeling, management, and integration layer. The purpose of this mechanism is to provide a platform for modeling and process execution that orchestrates the movement of information and the invocation of remote application services in support of a business application in this case, a vertical application that applies to many problem domains within a vertical market and can be extended for a particular application.

Reusable processes are the fundamental value of vertical subsystems within the world of application integration. They are canned process models that, when connected to specific resources (e.g., packaged applications), provide a quick solution for a vertical need.

In additional to reusable processes, we also have the opportunity to create reusable verticalized application services as well. Better yet, we can leverage reusable verticalized application services that others build and make available to us. Again, this is the promise of Web services.

Finally, this layer provides business activity monitoring (BAM) capabilities, or the ability to monitor processing in real time, making adjustments as required. This is particularly important with vertical domains such as finance, where adjustments in processing and visibility into transactions or groups of transactions are important during runtime.

Vertical process subsystems are the vertical applications created within the process execution and modeling layer. (Keep in mind, in some cases, they may have specialized processing that needs to occur at the resource adapter layer.) This is where the vertical behavior resides, and thus is the ultimate value for the end user. These are, in essence, the business applications that have as much to do with business information processing as application integration. The value of these systems is that they are nearly complete out of the box. While they typically require some domain-specific extensions (see the next paragraph), they should provide most, if not all, of the functionality to service a specific vertical market application requirement.

Domain-specific extensions, as you may expect, are extensions to the precanned processes that customize these processes for a specific implementation. In many cases, they will connect precanned verticalized processes with enterprise processes, or even trading community processes. Within some projects, vertical subsystems are connected together, along with the enterprise processes; for example, leveraging GSTP connectivity and processing along with ISO 15022, Omgeo, and transaction matching in the finance vertical market.



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