Patterns: Implementing Self-Service in an SOA Environment

Chapter 4. Runtime patterns 57

򐂰 Domain firewall node

The domain firewall is typically implemented as a dedicated server node. See

“Protocol firewall node” on page 56 for a description of firewalls.

򐂰 Existing applications and data node

Existing applications are run and maintained on nodes, which are installed in

the internal network. These applications provide for business logic that uses

data maintained in the internal network. The number and topology of these

existing application and data nodes is dependent on the particular

configuration used by these existing systems.

򐂰 Business service directory

The role of the

business service directory is to provide details of services that

are available to perform business functions identified within a taxonomy. The

business service directory can be implemented as an open-standard UDDI

registry. Catalogs, such as a UDDI registry, can achieve one of the primary

goals of a business service directory: to publish the availability of services

and encourage their reuse across the development activity of an enterprise.

The vision of Web services defines an open-standard UDDI registry that

enables the dynamic discovery and invocation of business services. However

although technologies mature toward that vision, more basic solutions are

likely to be implemented in the near term.

򐂰 Enterprise service bus

The

ESB is a key enabler for a SOA as it provides the capability to route and

transport service requests from the service requester to the correct service

provider. The true value of the ESB concept, however, is to enable the

infrastructure for SOA in a way that reflects the needs of today’s enterprise: to

provide suitable service levels and manageability, and to operate and

integrate in a heterogeneous environment.

Furthermore the ESB needs to be centrally managed and administered and

have the ability to be physically distributed.

4.1.1 Why use an enterprise service bus?

Using an ESB node is key to designing an SOA solution. For that reason, we will

go into the ESB node in more detail to help you understand the advantages.

Selecting a Runtime pattern that uses an ESB helps you achieve the following:

򐂰 Minimizes the number of adapters required for each point-to-point connection

to link service consumers to service providers.

򐂰 Improves reuse in multiple point-to-point scenarios.

58 Patterns: Implementing Self-Service in an SOA Environment

򐂰 Addresses any technical and information model discrepancies between

services.

򐂰 Provides a single configuration point for distributed deployment.

򐂰 Decouples service requesters from providers

򐂰 Provides a common access point for service requesters

򐂰 Provides centralized security for services

The service bus can span across multiple system and application tiers, and can

extend beyond the enterprise boundary.

Figure 4-1 shows a first level decomposition of the major components that make

up an ESB node.

Figure 4-1 ESB runtime pattern: Level one

The ESB is a key enabler for an SOA because it provides the capability to route

and transport service requests from the service consumer to the correct service

provider. The ESB controls routing within the scope of a service namespace,

indicated symbolically in Figure 4-1 by the oval on the ESB Hub.

The true value of the ESB concept, however, is to enable the infrastructure for

SOA in a way that reflects the needs of today’s enterprise: to provide suitable

service levels and manageability and to operate and integrate a heterogeneous

environment. Furthermore, the ESB needs to be centrally managed and

administered and have the ability to be physically distributed.

Hub

Namespace

Directory

Enterprise Service Bus

Administration and

Security Services