Published in DM Review Online in August 2004.|
Printed from DMReview.com
Thoughts from the Integration Consortium: Dynamic Interoperability and Service-Oriented Architectures, Part 2by Integration Consortium
This month's column contributed by Ian Bruce, director of Marketing for Systinet Corporation.
In Part One of this series we discussed Web services and widely adopted standards that underpin the technology. In this second article we'll discuss how Web services are being applied to create a service-oriented architecture (SOA).
A SOA is the design blueprint for the IT infrastructure of the near future. Web services are the foundation building blocks that constitute an SOA.
Service orientation is an approach to designing software systems. An SOA is a system for linking resources on demand. In an SOA, resources are made available to other participants in the network as independent services that are accessed in a standardized way. A "service" is typically a group of software components that together carry out a high-level function or business process, such as placing an order or reconciling an invoice. At its most basic, an SOA is simply a collection of services on a network that communicate with one another. All services share some common characteristics:
Service orientation isn't a new approach to software design - some argue it dates to the late 1970s when discrete software applications were first designed with well-defined interfaces - but it has become powerful because of the widespread adoption of Web services technology, which make creating an SOA easy and inexpensive.
SOAs have some distinct advantages over other architectures. First, SOAs make interoperability an innate characteristic of IT systems and applications because services share common interfaces, are loosely coupled and modular. When interoperability is an inherent characteristic of all IT systems, then the pervasive problem of application integration becomes moot. At Systinet we call this dynamic interoperability. Organizations don't have to invest inordinate amounts of time and resources writing code to connect applications, only to have to rewrite code again if small changes are made to the system. SOAs make integration simple, fast and standards based.
Second, SOAs make IT more agile and more responsive to organization requirements. Since services represent high-level business logic, IT is encouraged to think in business terms. With SOA, IT systems begin to accurately reflect organizational goals and processes. SOAs also make IT highly tolerant of change because reconfiguring loosely coupled services is simple, fast and low cost. With an SOA, IT is able to react quickly to changing organizational demands, new requirements or new processes.
Dynamic Interoperability and the SOA Registry
We've touched on the concept of dynamic interoperability, and we've discussed how Web services are the building blocks for enabling an SOA. However, as Web services proliferate inside the enterprise, an immediate need arises for a means of discovering, reusing and effectively managing all these services. To be effective, an SOA needs an enterprise registry. Here are the four "abilities" an SOA registry provides:
A business cannot use what it doesn't see. IT cannot manage what it can't identify. Organizations grow organically. They unwittingly implement multiple systems that expose information that is redundant, conflicting or distributed across their organization. The seemingly simple task of gaining a unified view of an enterprise's assets is a significant challenge.
Dynamic business services is about gaining visibility into the workings of the various systems and applications that you build and deploy. For the business analyst, it's about providing the visibility needed to determine what business services are available to automate processes; which services the organization can reuse to address a business need; and to assess the impact of changes in business requirements make on existing processes. For the technologist that deploys and manages these systems, it's about gaining visibility of the applications and business services he's managing or needs to. For the architect and the development team, it is about visibility of component that the organization as a whole has built.
The ROI for SOA is reuse. A registry promotes reuse and as a result avoids reinvention. It is the essential discovery tool that catalogs services so they can be invoked at design time or runtime. This accelerates development time and improves productivity, while reducing maintenance costs. It becomes possible to "wrap and reuse" applications and systems, rather than "rip and replace" them.
Dynamic business services adaptability is about taking the benefits of SOA and reusability to the next level by building and deploying business services using the well-known and evangelized service-oriented architectural principle of location and transport independence and declarative policy in order for a client to dynamically discover and negotiate the method to use to bind and the behavior to exhibit to interact with a business service. It is the role of IT to build and maintain the abstraction layer between business services and the underlying technology. It is the role of the architect to build clients that are resilient to infrastructure and organizational policy changes.
Building in resilience to change and the ability to catalog and categorize an enterprise's business service portfolio is important but only part of the dynamic business service architecture. If, indeed, an enterprise is going to successfully tip the balance of investment in favor of business innovation over IT, it must build in manageability from the outset; otherwise it won't be able to fully reap the reward it's seeking. Dynamic business service manageability is about building and deploying the ability to understand and manage relationship between business services, component versioning and dependencies, and effecting reconfiguration of various aspects of a deployment such as location, transport, security and policy parameters.
UDDI (universal description, discovery and integration) is the standards-based approach for creating an SOA registry. UDDI allows organizations to standardize the way businesses organize, catalog, discover and reuse Web services and is an essential element of a SOA. A UDDI-based SOA registry provides a mechanism for developers of a Web service to advertise its existence and provides a way for others to search and discover this service and invoke it. By thus promoting reuse of Web services, and prevent needless reinvention, a SOA registry can provide significant ROI by eliminating redundancies. As enterprises embark on creating and deploying Web services they are well advised to create a registry early to provide the visibility, reusability, adaptability and manageability they need.
Ian Bruce is director of Marketing at Systinet, a leading independent software provider for service-oriented architecture (SOA) enablement. You can reach him at email@example.com.
The Integration Consortium is a non-profit, leading industry body responsible for influencing the direction of the integration industry. Its members champion Integration Acumen by establishing standards, guidelines, best practices, research and the articulation of strategic and measurable business benefits. The Integration Consortium's motto is "Forging Integration Value." The mission of the member-driven Integration Consortium is to establish universal seamless integration which engages industry stakeholders from the business and technology community. Among the sectors represented in the Integration Consortium membership are end-user corporations, independent software vendors (ISVs), hardware vendors, system integrators, academic institutions, non-profit institutions and individual members as well as various industry leaders. Information on the Integration Consortium is available at www.integrationconsortium.org or via e-mail at firstname.lastname@example.org.
Copyright 2005, SourceMedia and DM Review.