This web archive is a result of a preparation that I am undergoing for a variety of reasons:
1: For a Certification
2: Acquainting myself with the IBM product stack for SOA Deployment
3: For my own Interest
4: As a part of the mandatory Skill Set required by my Project
2: Acquainting myself with the IBM product stack for SOA Deployment
3: For my own Interest
4: As a part of the mandatory Skill Set required by my Project
The reproduction here is of course a consolidation of multiple references.
An ESB is an architectural concept that is implemented through the use of one or
more products. IBM currently offers two ESB products.
WebSphere ESB is built on proven messaging and Web services technologies. It provides standards-based Web services connectivity and XML data transformation. WebSphere ESB is shipped with WebSphere Process Server.
WebSphere Message Broker provides universal connectivity, including Web services, and
any-to-any data transformation. In addition, such products as DataPower® and WebSphere Transformation Extender can be used to extend the capabilities of the core ESB products.
An ESB is a key part of a complete solution for connectivity. An ESB might need to be extended or complemented with additional features or products to deliver a complete solution to meet your connectivity requirements.
A Non SOA Solution:
In a non-SOA solution, communication between service requesters and providers is accomplished via a series of direct connections, one connection per requester/provider pair. This requires that the requester be aware of the requirements of the provider and vice versa, for example, the transport protocol, message format, and location of the service. As enterprise solutions grow, the web of direct connections and the complexity of managing those connections
also grows.
A SOA Solution:
In an SOA solution, an ESB acts as an intermediary between requesters and providers. Connections are made to the ESB, rather than directly between the communicating pair. The ESB makes the transition between transport protocols and message formats used by the requester and provider. The location of each service is known to the ESB but not to the service.
The Role of an Enterprise Service Bus:
This decoupling of the consumer’s view of a service from the implementation of a service provides the following advantages:
An ESB is an architectural concept that is implemented through the use of one or
more products. IBM currently offers two ESB products.
WebSphere ESB is built on proven messaging and Web services technologies. It provides standards-based Web services connectivity and XML data transformation. WebSphere ESB is shipped with WebSphere Process Server.
WebSphere Message Broker provides universal connectivity, including Web services, and
any-to-any data transformation. In addition, such products as DataPower® and WebSphere Transformation Extender can be used to extend the capabilities of the core ESB products.
An ESB is a key part of a complete solution for connectivity. An ESB might need to be extended or complemented with additional features or products to deliver a complete solution to meet your connectivity requirements.
A Non SOA Solution:
In a non-SOA solution, communication between service requesters and providers is accomplished via a series of direct connections, one connection per requester/provider pair. This requires that the requester be aware of the requirements of the provider and vice versa, for example, the transport protocol, message format, and location of the service. As enterprise solutions grow, the web of direct connections and the complexity of managing those connections
also grows.
A SOA Solution:
In an SOA solution, an ESB acts as an intermediary between requesters and providers. Connections are made to the ESB, rather than directly between the communicating pair. The ESB makes the transition between transport protocols and message formats used by the requester and provider. The location of each service is known to the ESB but not to the service.
The Role of an Enterprise Service Bus:
This decoupling of the consumer’s view of a service from the implementation of a service provides the following advantages:
1: Reduces the number, size, and complexity of interfaces
2: Reduces the impact of changes made to the format and location of services, both in terms of impact to the applications and in terms of system management
3: Enables integration between disparate resources
4: Allows the substitution of one service provider for another without the service consumer being aware of the change or without the need to alter the architecture to support the substitution
The Basic Capabilities that an ESB should comply with:
The capabilities of an ESB vary depending on the products that are used to
implement it. An ESB should provide the following basic functions:
1: Routing messages between services
The requester sends the request to the ESB. The ESB makes the call to the service provider. The ESB determines the destination for the service provider.
2: Converting transport protocols between the requester and service
Without an ESB infrastructure, service consumers connect directly to service providers using a transport protocol that is supported by the provider. With an ESB, there is no direct connection between the consumer and provider. The service consumer connects to the ESB by using its preferred transport protocol without any knowledge of how the connection to the provider is
made. The ESB sends the request to the provider by using a protocol that is supported by the provider.
3: Transforming message formats between requester and the service provider
Typically, interfaces and operations of disparate services are not identical. The ESB transforms the message from the source into a format that can be accepted by the target. Handling business events from disparate sources. The same service provider that is responsible for a business function can be invoked from a variety of business contexts.
More on Message Broker as an ESB some time later :)
~ sayli :)
2: Reduces the impact of changes made to the format and location of services, both in terms of impact to the applications and in terms of system management
3: Enables integration between disparate resources
4: Allows the substitution of one service provider for another without the service consumer being aware of the change or without the need to alter the architecture to support the substitution
The Basic Capabilities that an ESB should comply with:
The capabilities of an ESB vary depending on the products that are used to
implement it. An ESB should provide the following basic functions:
1: Routing messages between services
The requester sends the request to the ESB. The ESB makes the call to the service provider. The ESB determines the destination for the service provider.
2: Converting transport protocols between the requester and service
Without an ESB infrastructure, service consumers connect directly to service providers using a transport protocol that is supported by the provider. With an ESB, there is no direct connection between the consumer and provider. The service consumer connects to the ESB by using its preferred transport protocol without any knowledge of how the connection to the provider is
made. The ESB sends the request to the provider by using a protocol that is supported by the provider.
3: Transforming message formats between requester and the service provider
Typically, interfaces and operations of disparate services are not identical. The ESB transforms the message from the source into a format that can be accepted by the target. Handling business events from disparate sources. The same service provider that is responsible for a business function can be invoked from a variety of business contexts.
More on Message Broker as an ESB some time later :)
~ sayli :)
No comments:
Post a Comment