Database Reference
In-Depth Information
•
Entities maintained
: 1-5
The main disadvantage of the previous approach is that we identified and implemented,
but didn't reuse it across all the domains' Utility layers within the Service Repository. The
Utility layer is too generic, so with some effort, it could be totally reusable. These efforts
were clearly identified in the previous approach as follows:
• Make a broker payload-independent, presenting the
<any>
block in the Message
Container
• Implement an SBDH-compliant Message Header as a reference to the payload
• Implement the Process Header as a persistent container to route the slip/execution
plan
• Implement the Audit/Message Tracking Data to track message information
The last point is a positive outcome of this implementation, as a universal Message/Ser-
vice Broker will endorse the implementation of other OFM common patterns, for ex-
ample, Error Hospital, Common Audit, and Centralized Logging. This is highly important
to maintain a unified contract for all Service Broker-connected components, which can be
fairly simple with the implementation of a Message Container as described previously.
Cross-layer Utility Services will be more thoroughly reviewed and tested against a
domain-specific implementation. Moreover, it will have a positive impact on reliability
and performance. The SB scalability must be treated with the utmost care as it may be a
success factor for a cached/clustered implementation. Apparently, SB/SR become single
points of failure; therefore, rigorous stress testing is absolutely required. A dedicated
framework must be devised for this. Due to the implementation of a Canonical Endpoint
for all composition members, an alternative implementation based on J2EE can be presen-
ted with relatively little effort.
Reusability and maintainability will be higher than those with previous methods.
However, as it is still at the domain level (GU), it is not yet at the top level and is quite de-
centralized.
All four of the preceding steps are identical to the previous solution, except that the imple-
mentation of the Utility layers/patterns is governed from a central location.
The Enterprise Service Repository
The Enterprise Services Repository (ESR) is the central repository, where we define, ac-
cess, and manage SOA assets such as services and data types. The repository stores the
Search WWH ::
Custom Search