Enterprise Services Bus
Radovan Janecek points to a set of posts (Jump of the bus, take a cab I, II and III) by Jean-Jacques Dubray in which Jean-Jacques indicates that the Enterprise Services Bus (ESB) is far from essential for SOA.
In principle I agree: the implementation of services does not require the use of an ESB. In practice however I like to use an ESB to solve a lot of infrastructures issues related to the implementation of services.
My "ideal" service implementation consists of a business logic kernel wrapped by a service infrastructure shell. The business logic, implemented in a business component , contains as little infrastructure logic (logging, authentication, authorisation, encryption, caching, transaction management, message encoding/encryption/compression, etc.) as possible. The service infrastructure may host the business component and must ensure the business component can be found and reached by the outside world. It must also enable the definition and enforcement of infrastructure policy for messages sent to and from the service.
The ESB can ease the implementation of service clients as well, by shielding service clients from the implementation details of locating service endpoints, selecting the preferred endpoint, selecting the optimal transport protocol and negotiating the policy for service invocations.
As long as an ESB supports WS standards (SOAP, WSDL, WS-Policy, WS-MetadataExchange) it's use is not necessary to create service clients and providers, but it certainly makes the life of the developers creating services a lot easier. It also decouples service consumers and providers from technical implementation details, which provides considerable flexibility for optimisation and management of services.
Update:
Phil Wainewright gives an insightful overview of the ESB playing field in the posts Top ESB Choices and More on ESB.
In principle I agree: the implementation of services does not require the use of an ESB. In practice however I like to use an ESB to solve a lot of infrastructures issues related to the implementation of services.
My "ideal" service implementation consists of a business logic kernel wrapped by a service infrastructure shell. The business logic, implemented in a business component , contains as little infrastructure logic (logging, authentication, authorisation, encryption, caching, transaction management, message encoding/encryption/compression, etc.) as possible. The service infrastructure may host the business component and must ensure the business component can be found and reached by the outside world. It must also enable the definition and enforcement of infrastructure policy for messages sent to and from the service.
The ESB can ease the implementation of service clients as well, by shielding service clients from the implementation details of locating service endpoints, selecting the preferred endpoint, selecting the optimal transport protocol and negotiating the policy for service invocations.
As long as an ESB supports WS standards (SOAP, WSDL, WS-Policy, WS-MetadataExchange) it's use is not necessary to create service clients and providers, but it certainly makes the life of the developers creating services a lot easier. It also decouples service consumers and providers from technical implementation details, which provides considerable flexibility for optimisation and management of services.
Update:
Phil Wainewright gives an insightful overview of the ESB playing field in the posts Top ESB Choices and More on ESB.
0 Comments:
Post a Comment
<< Home