Choose an ESB topology to fit your business model

Selecting the Enterprise Service Bus (ESB) topology that most closely matches the design of your business is an important step in applying service-oriented architecture (SOA) principles to achieve your business transformation goals. This step brings your IT infrastructure into alignment with your business design in light of your style of governance. Topology describes those properties of a geometric shape that remain unchanged by deformation. An ESB topology, therefore, is composed of related ESB segments with their properties and relationships. Both the structure of the business and the company’s approach to governance -- in other words, the placement of decision-making authority within the organization -- should dictate the visibility and management of ESB-enabled services. Choosing the ESB topology that best fits your business structure and governance approach maximizes business benefit. This article analyzes some multisegment ESB topology patterns in view of this paradigm and offers guidance to help you make this important choice.

Chris Nott (chris_nott@uk.ibm.com), Consulting IT Specialist, IBM 

Chris NottChris Nott is a Consulting IT Specialist with IBM Software Group in the UK. He has 15 years of IT experience in software development, technical presales consulting, and solution architecture. His current area of expertise is business integration, and he has a strong background in relational systems design and database technology. He has written extensively on business integration and the Enterprise Service Bus. He holds a BSc degree in mathematics from the University of Durham and is registered in the UK as a Chartered Engineer.



Marcia Stockton, Senior Technical Staff Member, IBM 

Author photoMarcia Stockton is a Senior Technical Staff Member with IBM Software Group. She leads a core Software Group Architecture Board workgroup responsible for the definition and evolution of the programming model for SOA and is coauthoring a book on SOA implementation. Marcia is also an IBM Master Inventor with more than 70 patent filings on a spectrum of software and networking technologies. Her 18-year IBM career has included leadership roles on high -performance routing, advanced peer-to-peer networking, Bluetooth technology, IBM WebSphere Edge Server, and Broadband Networking, as well as authorship of numerous papers and articles. She is a senior member of the IEEE. Since 2001, she has performed these duties from a remote location, off the grid somewhere in the Sierra Nevadas.



15 March 2006

Also available in Chinese Russian

Introduction

This article is organized as follows. First, we introduce some common business designs and describe the related governance patterns. For each business model, we suggest a matching ESB pattern and analyze its special considerations and tradeoffs. We conclude with two topics of special relevance to complex ESB topologies: a service registry and monitoring.

Business structure patterns

The structures of large business organizations, despite their complexity, can be abstracted into several common patterns that reflect widely-used organizing principles embodied in many companies today:

  • Single Global Company -- Companies that project a single worldwide image must offer consistent and unified interactions with their global business processes to customers, partners, and suppliers everywhere, yet accommodate local suppliers and variations, such as legislative and taxation differences. A company that wishes to offer services consistently, regardless of location, may adopt this pattern. While many companies aspire to this, for most it's unnecessary and not optimal -- not the least because it's hard to achieve.
  • Multiple Geographies -- Companies may organize geographically, each region operating independently yet synergistically in support of the company’s global goals. Such a company offers its services to customers and interacts with partners and suppliers within a specific country or region. Global engagement is by exception. Each regional organization is responsible for meeting local legislative requirements. This is a common model for multinational companies.
  • Multiple Business Divisions -- Companies may divide their operations by product, service, or function, giving each division autonomy over its own services. Business efficiency can often be realized by sharing core services -- for example, customer management. Core services that aren't shared differ or are duplicated, potentially incurring unnecessary costs. Banks often fit this model with separate divisions for retail banking, credit card, and mortgage services.
  • Store/Branch Network -- Companies with branch networks often deploy integration functionality, processes, and capabilities under central or regional control. They vary in their need to permit customization of branch services. A central infrastructure to which all branches are linked, and from which all branches are managed, is the key trait. Many retailers and branch-based financial institutions fit this model.
  • Hierarchical -- In a Hierarchical organization, different business divisions define and execute their own processes autonomously, possibly making use of some centralized services. Or -- applying the same model at a finer degree of granularity -- a division may provide services to its local operations, which in turn define and operate their own business processes and services composed from these services.

Complex blends of several structures may arise. One common hybrid is a matrix organization in which secondary structures overlay line management reporting (a single, well-defined organization). For example, a company whose divisions are primarily product oriented might also have a geographically structured organization with product development responsibility in the product organization but marketing responsibility in the country organization. Authority in a matrix structure could depend on the type of issue to be decided. For example, some companies delegate the responsibility for complex business decisions to cross-functional teams representing the affected facets of the organization.

Mergers and acquisitions often produce complexity. Typically the merging organizations’ business processes and data repositories overlap and generally employ different architectures and technologies. In selecting the most appropriate ESB topology for the merged entity, the enterprise architect considers how any pre-existing infrastructure is being used, then draws together multiple integration components with overlapping capability to support the newly merged company’s business.

These patterns raise many challenges. In reality, business processes span multiple business areas; the structure of the organization usually reflects a series of organic changes over time as a function of striving to optimize the management of the business. Interaction across business areas is required to obtain a complete picture of the organization’s customers, to facilitate cross-selling and up-selling, and to promote customer loyalty initiatives. Analysis and marketing often bring together information from different areas. And brand management may span multiple divisions and geographies.

Today’s organizations must not only look within themselves; they must exploit horizontal integration opportunities with customers, partners, and suppliers. The extension of business processes beyond the enterprise and their optimization for efficiency and improved customer service are common business goals. There are ESB topologies that span companies, but these are beyond the scope of this article.

Ultimately, the supporting technology infrastructure must be designed to ease or overcome these challenges. Today organizations are looking to SOA with Web services to create a simple, unified, standards-based approach to seamless application interoperability across disparate systems to greatly improve business agility and efficiency.


Governance models and patterns

Fundamental to the success of an SOA is its governance. Business flexibility depends on how the business elects to manage and control the services that are provided. Typically, different parts of the organization have their own management control and governance.

Here, governance refers to the set of services, policies, and best practices that allow IT organizations to effectively control the definition, creation, use, amendment, and retirement -- the life cycle -- of business processes and the constituent parts from which they are composed. Having an effective and clearly specified set of governance processes promotes reuse, facilitates the definition and enforcement of policies, and eases the task of life cycle management.

Business units that request or provide services are mutually interdependent. The business agility derived from loose coupling, reuse, and extensibility of services can only be attained when the services offered to other business units are kept in good working condition. The relationships between the providers and consumers of services should be made explicit, enabling the services to be managed, updated, evolved, and retired based upon factual knowledge about their role in meeting business needs. Each business unit must be able to depend upon the performance, reliability, integrity, and currency of services from which its processes are composed. This assurance can only come from IT governance.

Approaches to governance range from centralized to distributed.

A central governance model has a governing body representing all areas of the business, plus experts who understand and are responsible for the technical aspects of the architecture and the components of the solution. This body reviews plans for adding, changing, or deleting services before authorizing their implementation. Centralized governance requires more initial effort to establish this governing body and more ongoing effort to manage. However, it can benefit the entire enterprise by promoting reuse and the sharing of best practices across teams.

Distributed governance allows each business area full control over the services it provides, although a central body might exist to recommend common guidelines and standards. It enables separate parts of the business to get started on their own, but does not facilitate reuse or the sharing of best practices.

After weighing advantages and disadvantages, organizations typically choose a governance model somewhere between the two extremes. Another critical decision is whether to limit the governance model to IT or include responsibility for behavior of the business (through the behavior of services) within its scope.

Governance patterns are derived from studying how different parts of the business interact to support the overall business operation and provide services to customers. Any interaction involving multiple business areas potentially needs governance over its supporting technology. Below, several examples of governance patterns (obviously not an exhaustive list) illustrate this point.

  • Sole Governance -- An interaction may lie wholly within the area of the business that provides its governance and not be accessible from outside of it. For example, the responsibility for a manufacturing plant may lie solely within a country business. In this case there are no special provisions for governance.
  • Local Governance -- An interaction (see Figures 1 through 3) lying completely within one division is made accessible to other business areas by publishing the service interface. Others who want to use the service must abide by the interface specification. Behind the interface, the implementation is governed solely by the owner. For example, a manufacturing facility may fulfil orders placed by customers interacting with other parts of the company.
Figure 1. Local governance pattern
Local governance pattern
  • Intermediary Governance -- The interaction occurs within a special business area whose role is to facilitate interactions between other business units. Business areas request and provide services, and the interactions between them are governed separately, or jointly, in the intermediary area. For example, finance and administration services may be provided centrally to other business areas.
Figure 2. Intermediary governance pattern
Intermediary governance pattern
  • Federated Governance – Each subset of an interaction spanning multiple divisions is governed by the respective division; these subsets collaborate using agreed interfaces. For example, the interaction may be a negotiation between a division that accepts orders and the factory that fulfils them.
Figure 3. Federated governance pattern
Federated governance pattern

Governance patterns identify who has the responsibility to monitor, define, and authorize changes to existing services and decide when a new service in their area is required.

Usually organizations choose a single governance model and apply it uniformly. However, sometimes an organization selects one governance model for the design of services and a different one for service execution. You can find a discussion on this special case toward the end of the article.


ESB topology patterns

This section explores various ESB topology patterns in terms of their management, governance, virtualization of services, and deployment requirements. Various ESB topologies are introduced in the IBM Redbook, "Patterns: Integrating Enterprise Service Buses in a Service-Oriented Architecture." This article advances the previous work by mapping each of the business organizational models from the previous section to a matching SOA, and then applying the appropriate ESB topology.

Figure 4. Business design, SOA, and matching ESB topology
Business design, SOA, and matching ESB topology

We also discuss the impact of each ESB topology upon mediation patterns and user roles [see "SOA programming model for implementing Web services, Part 10: SOA user roles" (developerWorks, February 2006)]. For a single ESB, these have been described in Part 4 of the series, "An introduction to the IBM Enterprise Service Bus" (developerWorks, July 2005). The existing literature addresses single-ESB, single-namespace topologies in which each provider is visible to every requester across a heterogeneous, centrally administered environment (see publications listed in the Resources section). This article elaborates upon prior work by analyzing new patterns derived from multiple ESB segments.

Single Global Companies generally choose a matching SOA pattern in which services are specified and owned by the entire organization. Even if they allow multiple physically distributed instances of services, there is one abstract definition for each -- managed by the organization as a whole -- and a common implementation. The governance model is centralized.

The corresponding ESB model is the Single Logical ESB, which shares many characteristics with a single ESB: a single namespace, all providers visible to all requesters. However, making services available in all geographies -- regardless of the requester’s location -- is challenging:

  • Performance may demand multiple geographically distributed service instances so that requesters can interact with local services. Yet the associated data must be consistent, implying a need for data synchronization.
  • High availability may dictate compensating for the loss of a local service by routing the request to an equivalent service elsewhere; thus, service providers (both their logic and data) must be capable of failover and failback. Furthermore, a mechanism is needed to pass requests to an alternate ESB when the preferred one is unavailable.
  • The physical ESB instances must route service requests to the appropriate providers transparently.

Significant complexity arises from aligning these multiple service-provider instances. When looking up the appropriate provider, the service registry must consider the requester’s location and the availability of services at all locations. The supporting infrastructure can be managed locally (under global policy and control), but the services themselves must be managed centrally to enable their uniform presentation across the globe.

ESB and SOA user roles are affected in the following ways:

  • The Business Analyst identifies business requirements and processes across geographies, as global uniformity is the hallmark of this approach. Clear quality of service specifications, stated from a business perspective, help the architect assess where and how to provide services.
  • The hardest job for the Solution Architect involves the components supporting the ESB topology. Decisions impacting data management and data integrity should be founded on use cases. The design must reflect quality-of-service needs and nonfunctional requirements without limiting the location of service requesters.
  • The Solution Administrator must assemble and deploy solutions so that each of the physical ESBs provides the same functionality in a way that supports failover in the event that a physical ESB is lost. Security must be aligned.
  • The Operator needs to be able to monitor the physical route and associated behavior of service requests to manage and meet expected service levels.

The mediation patterns resemble those found in a single ESB, except that:

  • Data used to enrich mediations must be synchronized across physical ESB instances to ensure consistent execution, and therefore data integrity.
  • Runtime routing should reflect the geographic affinity between requester and provider. When a local service is unavailable, requests are transparently rerouted to a service provider elsewhere.

Only an organization that vigorously projects a unified global image is likely to pursue this pattern, which requires worldwide consistency and centralized governance. Not all of the technology required to implement this pattern with ease exists today. A clear understanding of business requirements, an analysis of use cases, and a broad consideration of data are prerequisite to defining and specifying how this SOA can meet business needs.

Directly Connected ESB with single registry

In the Multiple Geographies and Multiple Business Divisions models, services are generally owned by individual business units. Distributed governance enables all areas of the business to join in defining service specifications and implementations; some degree of centralized governance can foster service reuse and interoperability across business areas. Both the Local and Federated Governance patterns are likely to be employed to own and control the integration scenarios.

Both the Directly Connected ESB (discussed in this section) and the Brokered ESB pattern (discussed in a later section) fit these business models

Figure 5. Directly connected ESB with single registry
Directly connected ESB with single registry

The Directly Connected ESB makes all of the services in several interconnected ESBs visible through a common services registry, which reflects each service’s affinity for one of the ESBs. A requester calls its local ESB, which consults the registry and then passes the request to the identified service provider’s ESB. Regardless of the number of ESBs in the topology, each interaction involves two ESBs that are directly linked.

This pattern fits organizations with multiple divisions or geographies. Services that are provided and managed by division are made accessible enterprisewide by listing them in a common registry. Each division secures its own ESB and regulates access to its services. To exploit services in another division, a mediation defined in the local ESB permits requesters to access the provider’s ESB and the service itself. Policies may be defined to control how services may be used. Both the deployment infrastructure and the registry also need access control, to prevent misuse.

This pattern supports the virtualization of services in the following manner: To invoke another business unit’s services, you define a service stub on the local ESB, encapsulating the registry lookup. Thus, with the appropriate management of access rights and policy in the two ESBs, a requester in one division can invoke services provided by another by directly connecting the two divisions’ ESBs.

Let’s examine how this pattern impacts ESB and SOA user roles:

  • The Business Analyst focuses on mapping ESB infrastructure boundaries to business divisions or geography and on the management of business processes spanning boundaries that are executed in parts. Computing key performance indicators or monitoring processes end to end might require metrics from multiple divisions.
  • The Solution Architect considers how to maximize the reuse of IT assets in different divisions. Interactions between ESBs -- including policy and security -- need to be defined, and services and data structures need to be mapped, to enable service sharing across divisions.
  • When the Integration Developer assembles service endpoints into solutions, adherence to the Solution Architect’s specifications facilitates their use by other divisions.
  • The Solution Administrator assembles the solutions, deploys them into the appropriate ESB(s), and imports the service definitions into the common registry, applying appropriate security and access controls from an enterprisewide perspective.
  • The Operator concentrates on monitoring and managing the use of services cross-divisionally. Business processes and transactions spanning multiple ESBs require aggregation of infrastructure services.

Mediation patterns differ from the single ESB as follows:

  • Enrichments and custom mediations may require access to (or local copies of) data from other locales, such as the service provider’s business unit.
  • The Monitor pattern might be used at all of the ESBs involved in servicing a request.

Directly Connected ESB with multiple registries

A variation on the Directly Connected ESB pattern uses one registry per ESB (possibly augmented by a central registry, to the extent governance is centralized). Without a central registry, each business unit must define and meet commitments for services provided to other divisions. Either variation requires careful thought about 1) how service metadata is replicated, synchronized, partitioned, transformed, and so on between multiple registries, and 2) how nonfunctional characteristics (not only security, but performance, reliability, transactionality, and so on) are maintained when service interactions traverse multiple ESBs.

Brokered ESB

Like the previous pattern, the Brokered ESB pattern fits businesses with multiple geographies or divisions. It also makes locally owned services available across divisions by publishing them centrally. However, outlying ESB segments are connected only to a Broker ESB, not directly connected to one another. This decoupling enables the infrastructure to reflect business change more quickly. The Intermediary Governance pattern applies, in which service specification and implementation are governed at the business-unit level, with a degree of centralized governance to enable cross-divisional service reuse and interoperability.

Figure 6. Brokered ESB pattern
Brokered ESB pattern

In the brokered ESB, a common broker offers bridge services that selectively expose requesters to partners in other domains to regulate sharing among multiple ESB installations that each manages its own namespace.

Brokered ESB exhibits the following request flow: A requester requests a service from its local ESB. The request is mediated and routed to the broker, which performs a second mediation, routing the request to the ESB with which the provider is affiliated. This ESB passes the request to the service provider, fulfilling the original request.

The broker helps overcome the maintainability challenges of the Directly Connected ESB pattern’s point-to-point connectivity. While brokering has a clear advantage when several ESBs participate, the expected volume of service invocations is also relevant. Unlike the Directly Connected ESB, here, cross-ESB brokering logic is placed centrally, while each outlying ESB has its own service registry, and the central registry contains entries to facilitate brokering.

In a brokered ESB, each business unit is responsible for the governance, life cycle, and management of its own ESB. To mediate differences in data formats and policy, the common broker is centrally governed. To promote flexibility and reuse, common approaches, such as standard enterprise message formats, enable interoperability through the broker.

Tasks for the SOA user roles match those in the Directly Connected ESB pattern except for a few differences:

  • The Integration Developer may, in addition, develop mediations to common message formats and policies.
  • The Operator’s task is the same, except that monitoring and management centers around the brokering of service invocations.

Governance focuses on service interactions and mediations through the broker and on the promotion of reuse and flexibility by defining and managing common formats. The responsibilities for mediation and policy adherence must be clear.

The mediation patterns are similar to the Directly Connected ESB, but looser coupling increases service virtualization.

The Brokered ESB pattern applies when business areas develop and manage their own services but share a few of them, or selectively access another business unit’s services. When service ownership changes -- for example, if a division is outsourced -- this pattern alleviates the task of altering the affected service interactions, because, due to virtualization, only the broker is affected.

Hub and Spokes ESB

The Store/Branch business design is characterized by centralized governance over business processes and their underlying services, possibly with some local services in the branches. Services that can function connected to the center or standalone may be deployed into the branches to enable local operation. There may be a degree of distributed governance along with branch-specific services. The Local Governance pattern with a strong central organization is most common. Some integration scenarios may benefit from federated governance.

Figure 7. Hub and Spokes ESB
Hub and Spokes ESB

In the Hub and Spokes ESB pattern, which best fits a Store/Branch business design, several branch ESBs are directly connected to a hub ESB with no direct connections between branches. Service consumers and providers access services throughout the network through one of these ESBs. This topology can federate a set of moderately autonomous branches under the umbrella of a supervising organization; it also provides the flexibility of local services at each branch. Specific functions in the branches can be delegated to the central ESB, yet the branches can have autonomy if appropriate and consistent with local support capability.

In a branch, service requests are made to the local ESB, which mediates and routes the request to the central ESB and on to a central service provider. Service invocations originating in the central ESB can likewise be routed in the reverse direction to services hosted in a branch, but branch-to-branch interactions are nonexistent.

A branch may locally support limited business functionality in the event connectivity to the hub is interrupted, with subsequent synchronization once connectivity resumes.

The branch ESB infrastructure is provided centrally, as are transformations, policies, security, and service registry entries. However, if branches have the autonomy to define and implement additional local services -- or variations on centrally defined, locally deployed services -- the governance model needs to cater to this. Investment in local branch IT skills is likely to be small, but sufficient to handle the analysis, design, implementation, and operation of any locally required services. Infrastructure monitoring and management may be both central and local and should reflect the governance model.

SOA user roles are affected as follows:

  • The Business Analyst focuses on the architectural placement of central processes and services that sustain branch activity and on how they access the required data. Any branch-to-branch interactions are mediated through the center. Business Analysts in branches capture additional local requirements and variations.
  • The Solution Architect defines the interaction between the branches and central site, including security, policy, monitoring, and management. Some of the issues include secure user access in the branch, disconnected operation, service-level monitoring, and deferred data synchronization. Bandwidth may limit performance or impact the ability to move data in support of local service execution. The Architect also defines mechanisms for creating local services or varying central services.
  • The Integration Developer complies with specifications for branch-to-hub and hub-to-branch interoperability, including the emission of specific monitoring events from mediations.
  • The Solution Administrator assembles solutions and ensures coordinated deployment across the central ESB and all branches. User access in the branches is often centrally managed. Service variations and additions need local administration, and should also be secured.
  • The Operator monitors the Hub and Branch ESBs to maintain availability when service levels are not met or branch connectivity is interrupted or restored; there may also be local operation in the branches.

The mediation patterns resemble those for a single ESB, except:

  • Routing varies, depending on connectivity. When a branch becomes disconnected, requests that normally go to the hub are sent to a local provider instead, so the branch continues operating. Centrally mediated branch-to-branch interactions may be similarly affected.
  • The distribution of requests to multiple interested parties is dynamically adjusted to maintain an acceptable service level for the requester, depending on connectivity and performance.
  • To enable service-level management, message traffic is monitored, revealing activity across the distributed topology, especially as it pertains to interrupted branch connections.
  • Mediations that aggregate multiple messages to create new, complex events must meet business needs even when expected events arrive late or not at all.

Imposed ESB

The Imposed ESB pattern, a more extreme version of the Hub and Spokes ESB, fits a Store/Branch business design in which all services are centrally governed. The headquarters or regional office provides all the IT services -- with little or no investment in IT skills at the branch level -- as no local autonomy is permitted. As in Hub and Spokes, services may be deployed into the branches to support hub-connected operation with a stand-alone fallback capability.

The general pattern of service request and fulfillment, and the possibility of disconnected operation followed by synchronization when connectivity resumes, are identical to the Hub and Spokes pattern.

The branch ESB infrastructure, transformations, policies, security, and service registry entries are all created and managed centrally with little or no local customization. Any branch requests for IT changes are submitted to the central IT administration for approval and rollout. Monitoring and infrastructure management is centralized.

The impact on user roles and mediations is similar, except governance and management are entirely centralized, as the branches have minimal IT staff.


Sophisticated application of a service registry

Hybrid governance patterns call for more sophisticated use of the service registry. In the Directly Connected and Brokered ESB patterns, for example, certain services may be governed by business units in a distributed fashion, while other services are governed centrally, or a service developed by one business unit may be provided or operated by another unit (or centrally).

Figure 8. Cascaded registries
Cascaded registries

The cascading registry style (with supporting ESB topology) enables a split approach to governance, in which service invocation is common enterprisewide, while service design and construction are federated. Each business area has its own registry that it governs. A top-level service registry is governed at the enterprise level, above the business areas that create the services. Services are deployed by registering them in the top-level registry, then cascading some or all of the entries down to the local registries.

This pattern employs an enterprisewide ESB plus one ESB per business area. Very large deployments might add a third hierarchical-level ESB per business unit to mediate service requests local to that unit. Services, including enterprise services, can be provided at any level in the topology. Requesters and providers interact directly, through the minimum number of ESBs (there is no need to enforce hierarchical routing through the enterprise ESB that hosts the top-level registry). This topology extends the Directly Connected ESB model by changing the registry governance model.

Two SOA user roles are impacted:

  • The Solution Architect defines mechanisms for service deployment and registry management that permit optimum routing for requests spanning several ESBs.
  • The Solution Administrator, in deploying and managing services, cascades registry entries from the top-level registry to other registries as required.

The success of this topology depends largely on effective enterprise-level governance. Even though service design is federated, deployment is initiated from the top-level registry. This topology fosters enterprisewide commonality of service definitions.

This architecture fits a company whose business divisions or geographic regions operate in a largely federated way -- divisions take responsibility for the majority of their business operations, yet enterprise-level governance promotes common business approaches across all divisions. The typical company is one that wants to provide common, shared business services or manage its brands across the whole enterprise.


Monitoring a complex ESB topology

Sometimes complex ESB topologies can benefit from a separate conduit to transport events.

Technical events are those used to monitor the infrastructure in support of service-level agreements. As defined by SOA, business events usually involve key performance indicators (business metrics) that may trigger subsequent logic (a business action). A simple business event is a direct result of a transaction, whereas a complex business event results from a series of changes, in combination, defined by a business analyst.

Business and technical events impose additional requirements on the ESB. Not only must transactional changes be noted and associated events recognized, but the infrastructure must be capable of handling event streams. Furthermore, events may be published to groups of subscribers, logged, or audited. Analysis determines whether the workload posed by events and their supporting mediations is best accommodated in a single ESB topology or a separate conduit.

Event producers are often remote from the site of the resulting action; this separation requires careful attention to governance. Pragmatically, distributed governance over event creation and the resulting actions is often combined with centralized governance for overall control.

The ESB mediates between event producers and event consumers. This may involve selective event propagation across ESB segments across the ESB topology. In designing the flow of events in an SOA, consider the following:

  • In publish-subscribe interactions, an event published once may be acted upon by multiple subscribers; subscribers may filter incoming events by topic using selectors.
  • It may be necessary to secure event payloads from unauthorized access using access control.
  • The same occurrence can be modeled as several simple events or a complex aggregate event -- either approach having different workload characteristics.
  • Precise identification of a given event within a stream, if needed, can be achieved with correlators.

Conclusion

These ESB patterns abstracted in this article are not exhaustive, but illustrate some common approaches and considerations you face in planning the ESB topology and governance pattern to realize your business design. Real organizational structures and governance models are more complex than these, and any topology pattern you adopt needs some adjustment. You can combine these abstractions to create an architecture with the flexibility promised by SOA that complements the unique needs of your organization.


Acknowledgments

The authors would like to thank Marc-Thomas Schmidt, Paul Verschueren, and Rick Robinson for their contributions to this article.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into SOA and web services on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=SOA and web services, WebSphere
ArticleID=105502
ArticleTitle=Choose an ESB topology to fit your business model
publish-date=03152006