Database Reference
In-Depth Information
Service Bus as a pattern provides structural ways to solve the problems we most probably
have while applying these programmatic and methodological tools in order to fulfill the
requirements. First, similar to enterprise business flows, we will also deal with composi-
tion controllers, managing complex transaction, but in Atomic, Consistent, Isolated, and
Durable way (so called ACID), compared to EBF's tolerant way, abbreviated as BASE for
Basic Availability, Soft-state, and Eventual consistency. Therefore, the ATC implementa-
tion is the one of the top requirements, usually fulfilled by composition controllers and
transaction registration services.
Synchronous service brokers together with message mediators are the natural elements of
ESB. Similar to the EBF framework, EBS has to consolidate and centralize the business
rules, as the magnitude of tasks is similar to asynchronous compositions:
• Rule-based routing and transformations
• Rule-based invocation and computation
It doesn't mean that rule stores must be separate for synchronous and asynchronous frame-
works. Decentralization must be conducted on technical requirements: performance and
the level of reliability. It is possible to have two (or more) rule engines and one centralized
rule store implemented with high availability options.
The same is true for the Policy store and Policy centralization itself, as they are vital parts
of EBS and service buses. The point here is that due to its more lightweight nature when
compared to EBF, service buses act as service gateways and service perimeter guards, at
least the core components of ESB such as Service Brokers do this. Security policies, mes-
sage mediation and invocation policies, and QoS policies are attached to the service con-
tracts, and most importantly, they are globally enforced through the implementation of
policy declaration and policy enforcement points on ESB.
We already mentioned several shared stores required for process-related entities and mes-
sage metadata. Looking at the broader picture, the physical service implementation re-
quires some sort of logical structure, providing a segregation of the services by types,
runtime roles, models, engines required for service executions, failover types, and so on.
Actually, we already segregated the Enterprise Business Flow framework for long running
services from the fast-spinning Enterprise Service Bus. It is simply inevitable, as technical
requirements for platforms holding and running these services are quite opposite, and this
fact is obvious enough to start this segregation from the modeling and analysis phase of a
service's lifecycle. That's a purely governance matter and will be addressed by a separate
framework.
Search WWH ::
Custom Search