|
 |
Level: Intermediate Ali Arsanjani, Ph.D. (arsanjan@us.ibm.com), Chief Architect, SOA and Web services Center of Excellence, IBM 13 Jul 2005 As the IT industry matures, we will witness the emergence of more and more successful designs and implementations of Service-Oriented Architectures (SOA). We will also encounter challenges that appear to be recurring in slightly different forms but fundamentally have the same underlying problems. We also tend to repeat solutions with slight variations. To address this, the following patterns have arisen in the context of projects involving Service-Oriented Architecture (SOA) and Service-Oriented Integration (SOI). These projects have focused on the migration, modeling, design, and implementation of Service-Oriented Architecture and in the loosely-coupled integration enabled through services, which is termed Service-Oriented Integration. In this series, we will share these patterns and experiences related to their use. We will provide guidance on how to use them in combination to help solve commonly encountered problems in the migration, modeling, design, and implementation of SOA and SOI. Introduction: SOA adoption and SOA approaches It becomes increasingly important to understand that a single SOA solution is seldom the right fit. Rather, SOA solutions should be tailored to the approach and level of maturity of the organization to ensure a smoother path to adoption and success. There are four levels of adoption of SOA, which are identified and explained in Table 1 below. Companies are at different levels of maturity in the adoption and incorporation of Service-Oriented Architectures (SOA). Some are just beginning to explore the world of SOA using its technology instantiation: Web services. They are wrapping legacy functionality and exposing it for invocation for third-parties, clients, and business partners. This gets them into the game: they ramp up the development team, start the process of changing the corporate culture to better support SOA, and take the first steps in the exploration of new technologies and the business capabilities that may be impacted. This is level one. Level two of SOA adoption is when the initial testing of Web services has been successfully overcome and now the organization is beginning to integrate systems and applications using services. This is a step beyond Enterprise Application Integration (EAI). As proprietary protocols, glue code, and point-to-point connections give way to more open, standards-based protocols and interaction based on service descriptions that each system externalizes, we step into the realm of Service-Oriented Integration (SOI). In this world, the enterprise service bus reigns supreme: a mechanism for mediation, routing, and transformation of service invocations irrespective of the target service provider. It helps overcome many of the shortcomings associated with point-to-point connections. Table 1. SOA layers of adoption
Six approaches for creating an SOA It has been said that in flying an aircraft, takeoff and landing are the two most difficult things. You can land on an airstrip with various approach patterns, depending on air traffic control guidelines due to weather, traffic density, wind speed, and so on. The landing strip to successful SOA also comes with at least six approaches. Some clients want to start with their business processes and work their way down to services required to support those processes. Others have existing functionality in legacy systems that they want to expose to clients, partners, and a service ecosystem. A significant variation of the latter approach is that the functionality is embedded and not readily accessible, so a fair amount of legacy transformation and componentization needs to be done to pull the functionality out and expose it as a service -- whether it will be a good service or not is another matter. We will deal with this matter in another article under the guise of the "Service Litmus Test," and present criteria to determine whether something should indeed be exposed or not. Another top-down way of approaching SOA is through MDA -- Model-driven architecture -- tools allowing the definition of models that can generate code to build services. So far, we have considered two top-down and two bottom-up approaches. Other projects need to provide access to data and the status associated with that data. This is the information architecture or data architecture approach to SOA. Yet others seek to integrate systems and care more about how to integrate systems and applications through messaging than anything else; no lofty business driven ideals or access of partners to internal processes, but rather definition of system integration through messaging. Table 2. The six approaches to SOA
As an organization matures in its path towards a more agile and robust architecture that is aligned with its rapidly changing business requirements, it will do two things: it will a) choose to focus on a key set of differentiating initiatives that are centered around its core competencies, and it will b) move towards increasing levels of loosely coupled and dynamically recomposable integration of people, partners, processes, and data. Note that the dynamic recomposition in terms of building composite applications out of existing services is key. This allows services to be exposed in a reusable manner inside and outside an enterprise. As organizations start to move towards SOA, one of the main adoption methods or entry points into the SOA world is through Service-Oriented Integration (SOI). One of the key value propositions of doing this is the leveraging of existing investments in IT systems, rather than revamping/rewriting new ones. Realistically, service integration is a step beyond enterprise application integration and will define and leverage a loosely-coupled set of services over nonproprietary protocols, with minimal "glue code". This approach hinges on the use of services as the key enabler to access and on the interaction of data and processing between multiple systems or even business partners in an ecosystem. In order to succeed with this SOI approach, and to start from a practical point in terms of IT systems and gradually move incrementally toward the evolution of services within the enterprise, we need to overcome several principal obstacles or challenges. These problems can seem to form a spectrum from simple, almost trivial issues, to increasingly complex ones that must be resolved as we move to greater maturity in the use and implementation of SOA and garner the corresponding business and IT benefits. The patterns outlined here help resolve those challenges; one pattern per challenge. As we move towards increasing sophistication, we see a trend -- we are using finer grained patterns to build solutions of increasing complexity to solve more complex problems. For example, rather than jump to having an ESB from day one, we may find it more judicious to start with a service strategy, create some service adaptors and proxies, move to a virtual provider, then a service integrator, and then to an ESB. The use of these patterns will depend upon the practical considerations of your project, and you will use them differently on different projects, as Alexander says, ?without doing it the same way twice." Often an initial challenge is the concrete determination of the value proposition for using SOA within a project, line of business, or organization. This has to do with flexibility and the ability to alter the actual service provider who implements a service once their quality of service dwindles or they fail to provide the required functionality. This flexibility, which is the primary value of SOA, is overcome by understanding the steps in achieving flexibility through a remote service strategy. There are two more challenges that we describe and overcome with the use of patterns presented here. These patterns form the core of a pattern language covering a wider spectrum of issues around SOA and SOI as you move into higher levels of maturity in the adoption of SOA (shown below in Figure 1). Organizations that are migrating to an SOA through incremental adoption of increasing levels of integration of services typically start from strongly coupled systems with proprietary interfaces and glue code and move to point-to-point connections between partially-exposed services that often merely wrap existing functionality and make it accessible. These two points represent the first two steps in the spectrum of realizing the full potential of SOA. Each step represents greater maturity and a corresponding increase in business value and IT benefit. For example, Point-to-Point Exposure of otherwise inaccessible and embedded functionality, designed to rapidly support access to existing functionality, is a step up from the hard-coded silos. These silos contain embedded and often inaccessible functionality. Rather than bother to access hard-to-access embedded functions, organizations often resort to creating redundant functions that are themselves inaccessible in other contexts. Often application portfolio consolidation (in other words, reduction) can be accomplished by identifying common functions in disparate systems, extracting, isolating, and encapsulating the most promising one(s) and then providing a Single Point of Access, to facilitate ease of maintenance, lower costs, and enable, for example, rapid consolidation during mergers and acquisitions. The patterns mentioned in Table 3 below are some of the patterns for SOA and SOI that have been "mined" from a variety of projects: Table 3. Patterns and their corresponding benefits
Each point in the diagram below may be justifiable or appropriate for a given situation, and going to the right side of the spectrum may not always be the right thing to do or solution to adopt. The progression represents an increasing degree of maturity and the need for greater sophistication to handle increasing complexity and overcome new and more daunting business challenges as supported by IT. Figure 1. Points in the patterns spectrum of SOA and SOI towards the Integrated Service EcoSystem  The following sections will introduce some of the fundamental patterns that form the foundation of the pattern language for SOA/SOI. By "fundamental", I mean that clients tend to run into the problems associated with these patterns first and foremost and need to solve them in order to make progress in their path to SOA. SOA is a journey of gradual, small transformations that increasingly decouple service descriptions from service implementations offered by multiple service providers. The solutions below are descriptions of how these issues have been recurrently solved and may serve as a pattern to help you on your next project. Like any other pattern, these must also be adapted to fit the context and the forces that shape your individual problem space: the tradeoffs and considerations of your project, whether organizational or technical, make a difference, and you can determine if you need to skip a step from one pattern to another or to partially implement the pattern. Discussion and context for the patterns Most organizations have multiple heterogeneous backend legacy systems, only some of which are funded to be enabled to participate in an SOA. Often an organization is divided into lines of business that each may own a portion of the overall suite of systems without having control over a horizontal set of applications that supports a single business process. Thus, a business process may cut across multiple business lines with various system owners being involved. Each system will support (be used to update or create) one part of the business process. Each participant in the end-to-end process may not be in a position to fund or comply with an SOA migration or do so in a timely fashion. Thus, it is important to note that one organizational unit?s decision to migrate its capabilities to SOA does not imply that other line of business or the partners that provide dependent functionality. Thus, in the initial stages, efforts to migrate towards SOA involve a learning and integration curve that organizations must overcome. The SOI pattern virtual provider, for instance, helps pave the way. Companies can overcome these issues with incremental migration to SOA by leveraging, changing, or augmenting existing infrastructure, systems, governance, and policies. A Service Provider may rely upon a set of external services, provided by other lines of business or organizations in the ecosystem. These services may not be ready or meet quality of service needs in a given snapshot of time. The virtual provider pattern helps address this issue by allowing a prospective provider to create an SOA on the service consumer side and create a virtual provider of ervices on the service provider side. Any one of the systems it depends on may not yet be ready to fully migrate to SOA. In the interim, the service consumer can use a virtual provider to make progress, build an SOA, and link to the services of the provider once they come on board with their actual SOA implementation through a service strategy. Once you have a virtual provider in place, creation of an Integration Layer in your SOA becomes easier. You can then apply the service integrator to better flesh out such a layer. The full maturity and benefit for the Integration Layer comes with the creation of an Enteprise Service Bus. The [remote] service strategy can be used independently or in conjunction with the other two main patterns. This pattern essentially simulates the notion of polymorphism for services and embodies a strategy design pattern, but not in the object-oriented sense. Instead, it applies within the service-oriented world of remote invocation where there is a need to allow flexible re-assignment and migration to new endpoints that provide the service in a more cost effective, scalable, compatible, and consistent manner from the view of the service consumer. Thus, when consumers require changes to their non-functional requirements, or when their current provider deviates from their desired method of delivering the functionality or the non-functional requirements, the use of service strategy allows the re-allocation of other service providers as endpoints to your service(s) with minimal changes to the applications and your infrastructure. Essentially, you move from a more conservative set of rudimentary Web services to a more mature SOA with single points of access that eliminate redundancy, provide consistency in which you may have registries, repositories, and brokers. Note that we are not opting for the term "Gateway," which although might be a more appropriate word, has connotations that refers back to products developed in this space, such as the Web Service Gateway product. Here, we are focusing on the functional aspects of a unified point of access to business functionality. So, if you ask the question, "to arrive at an end-state of SOA, through service integration, what are the stepping stones to incrementally move towards a solid integration (layer) architecture, based on a service bus?" The first pattern talks about the value of SOA from a flexibility perspective. The second one is about creating critical mass to get your SOA off the ground and operational across the enterprise. And the third is about taking the virtual provider to the next level and act as a service integrator. Sooner or later, you will want to implement a step further, which is the ESB. Here we describe the steps you may need to take to get there. Note that in some cases, you can go straight to an ESB if the organizational culture and tools, technologies, and middleware are in place. This may be viable for the more mature part of your organization, for a subset of your applications will need to hand-hold and gradually, gently migrate another selected subset through the patterns described here. Pattern 1: Remote service strategy Context and problems: This is a variation of the strategy design pattern that can be applied in architectural contexts for SOA. It deals with the problems associated with loose coupling and is used when we want to have the flexibility of changing the service implementation based on input context, for example, or quality of service characteristics that different service providers can offer. The purely object-oriented strategy pattern primarily relies on inheritance-based polymorphism to create a family of interchangeable algorithms that are swapped out based on context. Rather than have an object hierarchy, in an SOA context, we need to be able to change the service provider with minimal or no impact on the consumer?s perception of the service, thus varying the actual implementer of the service description. The implementer may, in most cases, be a provider of a remote unit of functionality, somewhere in the internal network or Internet. Therefore, for example, a service provider for a VerifyAddress service in an OrderEntry application may need to be changed because our quality of service needs have changed due to higher transaction volumes or security constraints. Or, the provider has decided to charge twice the amount for the same basic service, which we have relied on, in the past. Now, we would like to have the flexibility of changing service providers with IT and Business impunity, which means minimal changes to IT systems and no impact on the business or customer experience in their online shopping experience. Figure 2. An SOA provides flexibility  In many cases the service providers are remote, and the binding to the actual implementer is through a Web service binding (SOAP invocation of a WSDL interface, perhaps discovered or pre-set to a given URI). Solution: Instead of hard-coding the access and communication mechanism to the service providers, create a service layer that separates the interface of the service you require from a layer of possible implementers of the service, the Enterprise Component Layer, for example. This provides the flexibility to change service providers who implement the service interface without having to make large changes in the code of your IT systems. "Reconfiguration," rather than hard-coded customizations, is the name of the game: a dynamically re-configurable, architectural style that provides flexibility is one of the key value propositions of SOA. Figure 3. Alternatives showing the remote service strategy  Consequences and Variations: There are degrees of implementing this pattern. You can start with a higher degree of coupling and move to a lower degree. Instead of a hard-coded URI to the existing service provider?s WSDL, gain the ability to alter the provider by creating a service registry of providers and changing providers dynamically (UDDI, LDAP, and so on). If a further degree of dynamism is required, then the discovery and negotiation process occurs in a registry that you do not control, but is offered by an external service broker who will find you the "best-fit" or "best-match". Note that there is a need for a standardization of the semantics required to easily change service providers. There are fortunately a set of standards emerging in different business areas for a variety of industries that can form the basis for the semantics needed to change providers in more complex scenarios. (Also known as the service wrapper) Context and problems: The purpose of a service adaptor is to provide a mechanism that allows systems that are not service-oriented to participate in a Service-Oriented Architecture. Such services are usually legacy systems or packaged applications that do not offer cleanly defined, large-grained interfaces of the type specified by an SOA. This is a frequently recurring problem, as many core business processes today are supported by long-established systems that may use technology not within the mainstream for SOA and may be of significant complexity, and are thus not amenable to change. So, while they may be good candidates for re-use within an SOA, some work is required to provide a service-based access to them. In some cases, vendors provide the service adaptor, which makes the job easier (for example, Web services for CICS). In order to provide a wrapper service to a legacy system, some form of adaptor technology, or "service adaptor" is required. The purpose of this technology is to integrate with the non-SOA system and apply whatever data or protocol transformations are required to expose a clean service interface representing the legacy functionality. This interface is published as a "wrapper service". Service consumers can then bind to the wrapper service through the adaptor. Figure 4. A service adaptor  As we require more intelligence and capabilities from the Adaptor, we grow into needing the other patterns within this language. So, sometimes merely writing a wrapper is all that is needed. Other times, there is a need for more variation and intelligence to bring in a piece of functionality into an SOA, depending on whether we actually own it or not, what its performance characteristics are, and so on. Consequences: Application or legacy code can be changed to provide a clean interface. This may be particularly appropriate where the container for the code (for example, CICS) supports appropriate technologies (CICS SOAP support or support for XML and messaging technologies, for example). Other things that should be considered:
Context and problems: Your consumer does not have the sophistication to support services directly or make service invocations using WSDL. Yet you need to give them the chance of using the functionality and quality of service associated with a given service offering by some future provider. Remember that today, perhaps, the provider is not providing the functionality as a Web service but in a legacy format and plans to migrate in the future. The service provider may not have the sophistication of service exposure yet. Forces: If the functionality is not ready for service enablement to the fullest degree, by the candidate provider, you still may need to provide a handle to the service even if the actual WSDL and Web services-enabled technologies are not in place. Solution: In order to shield the consumer from the sophistication required to access functionality using a service interface, you may opt to, as a stepping stone, provide clients with a service proxy that acts as a surrogate to the future SOA-enabled capability. This pattern is used in conjunction with a service adaptor for the support of virtual providers. You may have a service adaptor (or more) and service proxy in place. Now you can start building your virtual provider. Context and problems: You are in an ecosystem with service consumers that rely on you for services. Likewise you rely on the services provided by service providers. However, in the real world, this ecosystem develops gradually -- not all services you require are available as Web services or through a service specification, yet. You need to develop the critical mass of services that enable your line of business, enterprise, or ecosystem. Figure 5. The SOA ecosystem  Forces: You want to obtain the functionality of existing providers you depend on not as API calls, but as services; but they are not ready to be exposed as services yet. You need to negotiate with the potential providers to obtain the services you need, not only functionally, but with the required service level agreements or non-functional requirements, all based on a service specification or description you provide (plus, perhaps, a service policy). You may face challenges because the providers may not provide services in the way you require them. You may ultimately face problems such as: a) the providers may not provide the services in a timely fashion for your immediate needs, b) they may provide different functionality not matched to your granularity, or c) they may not deliver the non-functional requirements you need. You want to have someone provide you with a service, but no one is prepared to do so yet. Solution: Create a virtual provider by specifying the service you need and assuming it is being provided. Create the provider yourself by using a proxy to communicate with the legacy system, while using an adaptor to transform the protocol used to one you want/need/have specified in your service description/contract. You encapsulate the proxy and adaptor in a façade because the number of adaptors may increase at random based on new systems and protocols that have to be transformed in the future. Therefore, use a façade to encapsulate the set of adaptors that will allow communication with existing API?s. Figure 6. The virtual provider SOA Pattern combines the façade, service proxy, service adaptor, and rule object patterns to enable critical mass in service enabling a consumer even when the ecosystem is not ready to provide all required services  Consequences: You now have a means to migrate in a graceful and incremental fashion to an SOA, even though your ecosystem is not quite ready. You can now plug in directly to the service of the provider once they have actually created, published, and offered the service for consumption. But now you do not have to write any new code, only new adaptors for new protocols coming from existing provider API?s. Related patterns: The latter is referred to as an Enterprise Service Bus, if rule objects for mediation, routing, transformation, and policies are added to the virtual provider. Virtual provider includes a façade, a proxy, and one or more adaptors for target system connection types. It becomes a service bus once you add rule objects for routing and policy management within the virtual provider. Some patterns that need to be in place to realize a virtual provider are related to governance. The matching donation pattern says that a central organization will match the fund equally divided between two organizational units in order to fund the enablement or creation of services they each require, but may not be within their budgets to fund, as it will "only" benefit the other business line. Note that gradually, these issues tend to dissolve as central points of access become more ubiquitous within the organization. Context and problems: You are applying a virtual provider and possibly employing a remote service strategy to meet the needs of business requirements. However, integrating with redundant back-end functionality, locked-in legacy systems (custom and packaged applications) remains a challenge. You want to have a single point of access to your back-end functionality in order to be able to recompose the individual pieces of that functionality in new combinations along with the need to monitor and manage those new services. We are in an ecosystem of service providers with existing functionality that is often brittle and developed ad-hoc: connections may often be "one-offs." Integration is proprietary and ad hoc; a single point of access is not available in order to compose services. Forces: Current systems do not present the right level of granularity of interfaces. This occurs when modeling, or identification, of services is not conducted through a mechanism where the granularity of the service is aligned with the business goals and IT systems (such as goal-service modeling in the SOMA method [1]). In addition, the services are refactored inappropriately, and not exposed in a connectionless (stateless) manner. Therefore integration is left at a point-to-point state with glue code bloating with every new change that is implemented. You want to have a robust and flexible single point of access that also leverages your virtual providers and service strategies. Solution: Therefore, introduce a specific layer of integration into the architecture for the integration of services and manage that layer through a service integrator. The service integrator provides a single point of access for otherwise redundant services. To facilitate this, externalize the variations into remote service strategies, within the context of a virtual provider at the implementation end. In this way, start to build the foundation for a graceful transition from a tightly coupled brittle architecture to a more loosely-coupled, dynamically reconfigurable architecture. Figure 7. Focus on integration layer managed by service integrator  The service integrator is responsible for managing multiple integration layers, as depicted in Figure 3 (layer 6). Within a service-computing ecosystem, the service integrator allows a single point of integration, monitoring, and managing for the ecosystem. This ecosystem is fractal in nature: this organization in its architecture can be found at various scopes. It starts within an organization at a project level, goes up to a business line, and covers its various existing applications across lines of business into the enterprise architecture. This allows the integration of two or more enterprise architectures for collaboration within the ecosystem. In order to further evolve the ecosystem that was "jump-started" by applying the virtual provider and the remote service strategy patterns, we now need to reduce or right-size our application portfolio by consolidating functions and services from across multiple back-end systems and sources and recompose them into a cohesive single point of access for a cohesive set of functions. Often this consolidation is based on multiple business process compositions (choreography). A lot of times, this choreography may not be actualized in a loosely-coupled, externalized technology, like a BPEL, because the cost on non-functional requirements may be too high. To alleviate non-functional (operational) concerns, the composition may even be hardcoded. This alternative/tradeoff to the pattern is toned down by the fact that the services composition is tapping into multiple application sources with the service integrator, being consolidated, recomposed, and then rendered at the presentation layer as a portal. Figure 8. Service integrator mediates between consumers and providers  Note that the virtual provider, if used as a service integrator, becomes a service bus, if we also add rule objects for routing and policy management within the virtual provider (service integrator). Figure 9. Service integrator SOI patterns  Consequences: You can now monitor, manage, and migrate functionality and services within an ecosystem that is either within your company or external to your enterprise. You can integrate and recompose applications that tap into other external service providers, packaged applications, and other legacy functionality and provide a single point of access and composition for new combinations of services that can be rendered to a portal within the SOA?s consumer layer (the presentation layer, for example). Discussion: Then how does this story differ from that of an Enterprise Service Bus (ESB)? Briefly, we are discussing the stepping stones that can enable a successful, gradual migration to a pre-ESB state. After that, an ESB can be created and leveraged to provide enhanced service capabilities. Therefore, we typically see clients starting from a hard-wired integration, then go on to a point-to-point service integration. The virtual service provider and then service integrator provide two additional steps along the spectrum to an incremental transformation toward an ESB. Pattern 5: ESB (Enterprise Service Bus) Context and problems: The patterns described in this paper have illustrated some commonly used techniques to deliver in reality some elements of the flexibility promised by SOA in a realistic and incrementally realizable manner. However, as an organization progressively adopts service orientation across applications, legacy systems, channel technologies, and more, the middlware required to support services and the management of services and technologies used to support them become complex issues. An important part of the solution to managing this complexity is the provision of a common infrastructure for service communication, mediation, transformation, and integration. This infrastructure can also act as a point of control to apply service management, security, monitoring, and instrumentation to the Service-Oriented Architecture. Such a common infrastructure is described by the Enterprise Service Bus. Forces: An organization with a large number of services will increasingly need a common administrative and operational model for the control of capabilities to:
Solution: Create an Enterprise Service Bus to provide the middleware capabilities throughout the organization to support service interactions. The ESB should support the communication, mediation, transformation, and integration technologies required by those services and should be capable of a distributed geographical deployment, but with a common model for management and administration. Figure 11, shown below, is from the IBM Redbook, "Patterns: Implementing a SOA using an Enterprise Service Bus", and illustrates the key features of an ESB, which include:
This configuration allows the ESB to support the virtual service provider pattern and remote rervice strategy for any number of services across an enterprise in a common way. In addition, the ESB can provide transformations between a variety of security, data format, or transactional models between service requesters and providers. In this way, the ESB acts as a control and encapsulation point for the inevitable complexity and heterogeneity encountered in an enterprise context. Figure 10. The ESB pattern  Please refer to the ESB Redbook, listed below in Resources, for more information on ESB patterns. Figure 11. Alternative view: The service bus as a service broker  The ESB pattern can be implemented using a variety of technologies and products -- the particular implementation choices depend on the requirements of specific organizations. The IBM Redbooks referenced in Resources include a more detailed examination of the ESB pattern and guidance for its implementation in a variety of IBM Software technologies. Common implementation technologies for the ESB include EAI middleware (WebSphere BI Message Broker, for example), Web services routers (WebSphere Web Services Gateway, for example) or more custom implementations using CORBA technology or basic XML through HTTP protocols. Discussion: Note that not only the infrastructure must be at least at the highest level required by any of the consumers and providers, but the consumer or provider must themselves be at the level desired. For example, security and other non-functional requirements are end-to-end notions that will affect quality of service of your SOA. An ESB can help manage services, but "managing services" is more complex notion. For example, from a Web services view, managing a service could mean not only adding or removing JAX-RPC handlers, but also starting/stopping, managing the namespace of the services (registry), and so on.
These patterns can be used in combination to solve the problems associated with migration to an SOA. Also, in many cases, clients need to proceed to a service-oriented integration model as a stepping stone to more large-scale SOA efforts within their organization. The use of these patterns helps clients in the following areas:
The virtual provider helps create an ecosystem of services (I will write about that separately) by enabling the creation of first-class constructs of the service paradigm. The granularity of the project is important: smaller projects should use service adaptors and service proxies to connect to legacy functionality, or functionality not SOA-enabled. When a line of business within an organization decides on standardizing on SOA, then it should consider creating a virtual provider. Or if, at the enterprise level, there is a project cutting across various lines of business (like a payment processing service or a pricing service), then it would justify the creation of a virtual provider as a first step towards the creation of a service bus (which includes building service adaptors to desired functionality, if you want to access that functionality as a service, then you would provide service proxies to service consumers). If you want to embed the access due to performance or security reasons, then you only need a service adaptor to access the function. The enterprise component realizing the service will need such an adaptor to be able to invoke the function. But it does not have to expose it as a service to its consumers. Only those services that have to be exposed to the consumers of a provider need have a service proxy or a request handler. As organizations evolve to higher levels of maturity in their usage and adoption of SOA, they will begin to step out of the boundaries of their internal systems, beyond point-to-point piecemeal integration with a few partners, into an ecosystem of services that require new capabilities. Among these capabilities are the patterns we have outlined above that assist in positioning the architecture to enter into the realm of the service ecosystem. Other capabilities include a service-oriented enterprise architecture (SOEA), a service-oriented modeling and architecture method (SOMA), a service-oriented reference model (as depicted in Figure 7), governance, and the patterns needed to ensure flexibility in re-composition within the service ecosystem.
Many friends and colleagues have both inspired and contributed to this article in various ways. Special thanks to Kerrie Holley, Rick Robinson, and Arnauld Desprets. Other colleagues, to whom go my deepest gratitude, who have contributed and given insight and ideas are, in random order: Donald Ferguson, George Galambos, Jonathan Adams, Ed Kahan, Michael Ellis, Paul Verschueren, Abdul Allam, Rolando Franco, Tony Fricko, Kishore Channabasavaih, Liang-Jie Zhang, Joe Hardman, Kyle Brown, Bobby Wolf, Emily Plachy, Stefan Puehl, and Sri Ramanathan.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Posts
