Database Reference
In-Depth Information
Is the city too big for you to handle (
Enterprise Inventory
)? Don't take it personally.
There could be many reasons, and most of them are out of your control—you are an archi-
tect and not a CEO after all. Start with one district (
Domain Inventory
) and constantly
prepare for expansion. However, remember that neglecting even one of the patterns
(presented in bold earlier in this section) will cause significant trouble in your domain.
Thus, ideally, this chapter should have been at the beginning.
Nevertheless, nothing can prevent experienced architects from reading this chapter first. If
you've played enough with ESB and BPEL and are now looking to get things organized,
you know by now the principles to enforce and the gaps to fill.
However, the objectives we chase by implementing the Service Repository and the design
rules we will implement to achieve these objectives (utilities) remain worth highlighting.
Objective
Design rules to achieve the objectives
•
The component/modular approach
•
The optimal number of components in the compositions (this is the balance between composition complexity
and components size, validated during the JIT testing phase)
•
Avoiding long-running multiphase commit transactions
Reliability
•
Implementing an atomic transaction coordinator
•
Rigorous and continuous automated assembly/testing during development
•
Building only when necessary
•
Maintaining potential single points of failure redundantly
•
Business agnostic components
•
Designing with reusability in mind
•
Having Discoverability during design time and, consequently, at runtime
•
The standardization of the service contract, including CDM and the implementation of SBDH, MC, Audit and
Acknowledge messages, and protocol standardization
Reusability
•
MEPs standardization/optimization
•
Promoting changes through configuration
•
Unified scalable components with measurable and predictable behavior
•
Centralized configuration store/management
•
Automated assembly and deployment framework
•
Unified Utility patterns (Logger, ErrorHandler, and PolicyAudit)
Maintainability
•
Autonomous implementation of services
•
Observing service layering (do not mix Utility and Task Orchestrated services in one layer (horizontal) or com-
bine entity services with proprietary adapters (vertical))
•
Single-purpose scalable components
•
Minimal-to-none state maintenance
•
A minimal number of transformations/translation
•
Minimal protocol bridging and staying with lightweight protocols, with the possibility to minimize marshalling/
serializations
•
Optimizing message sizes
Performance
•
Optimizing of queue processing, parallel, balanced multi-consumer, advanced datatype queues with message
filtering and queue content propagation
•
Preparing components for clustered, cached, or balanced deployment
•
Adjustable logging/audit levels
•
Avoiding singletons
Search WWH ::
Custom Search