1. 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe

2. 2 Middleware Enables Data Exchange Between Applications Application A stores customer information (name, address, …) Application B stores customer information (name, address, …) Changes to the data in Application A are propagated to Application B Application A Application B Customer

3. 3 Generally, a Translation Between the Application Specific Data Formats Is Required Application A stores customer information in a specific format Application B stores customer information in a different format The middleware needs to translate between the formats (the adapters don’t perform this task!) Simple field mapping or structural mapping may be required Middleware packages provide GUI tools to perform field mapping: TIBCO Integration Manager, Vitria Connection Modeler Application A Application B Customer Mapping

4. 4 Adding Another Application Requires Additional Mapping One mapping unit has to be created between each pair of applications Application A Application B Customer Mapping Customer Application C Mapping

5. 5 What Happens If More Than One Application Is Allowed to Update the Information? One mapping unit has to be created between each pair of applications If B is allowed to update customer information, we need to build 4 mapping units With a larger number of applications, this can lead to an effort that is proportional to the square of the number of applications Application A Application B Customer Mapping Customer Application C Mapping

6. 6 This Approach Introduces a Large Number of Tightly Coupled Point-to-point Connections n / 2 * (n – 1) connections between n systems Each mapping depends on two specific packages Customer

7. 7 Define a Common Domain Model to Replace an Unmanageable Number of Point-to-Point Mappings Define a common model for all entities and their relationships When publishing a message, translate each application’s private model into the common model and broadcast the message Manage the Common Domain Model for all entities in a central repository –Provided by the Middleware package or –Through XML and a set of DTDs (or XML Schemas) Application A Application B Customer Mapping Customer Application C Mapping Common Domain Model

8. 8 A Common Domain Model Addresses a Variety of Issues Related to Middleware Integration Applications communicate with each other through a common model rather than through point-to-point translations –Linear effort of integrating an additional application –Loose coupling between application data format The common model is abstract not specific to any application –The model represents the client’s business domain, not a specific package implementation –Improved ability to replace applications (e.g., legacy to best-of-breed app) –Ability to receive data from more than one source The Common Domain Model for all entities can be managed in the Middleware Repository –Single point of reference (and maintenance)

9. 9 A Common Domain Model Is the Platform for Future Extensions The business logic in the middleware (e.g., Automator, Integration Manager) operates on a common, package independent format More meaningful reporting The common model can be (selectively) exposed to external partners for B2B exchanges, Web Services Application A Application B Customer Mapping Customer Application C Mapping Business Logic B2B Integration Reporting / Data Warehousing Common Domain Model External Partners

10. 10 The Common Domain Model Is Described in UML Notation Unified Modeling Language is a standard notation defined by OMG UML Class Diagram defines entities and their relationships Even though we use the same notation, the design process differs from OO design (e.g. a Java program) Customer Location Billing Location Service Location Contact Primary Contact Entity Aggregation (Customer has Sites) Specialization (Billing Location is a type of Location) Association 0..N More info on UML: Book “UML Distilled, 2 nd ed.” by M. Fowler http://www.omg.org UML Brownbag (wrsc/sf/portal)

11. 11 The Common Domain Model Is Different From the Middleware Message Specification The Domain Model defines entities and their associations Message specifications define actions on the entities –TIBCO Repository Classes or Vitria Event IDL define Message Specifications, not the Domain Model! Message specifications are derived from the Domain Model –Messages act on entity attributes  Message fields –Message need to respect the association between entities  Key management Customer Location Contact Primary Contact 0..N SelectPrimContact LocationID ContactID Message SpecificationDomain Model

12. 12 Using a Common Domain Model Successfully Requires Special Skill and Experience Developing a Common Domain Model is a substantial task –Needs to be integrated into the task plan as a parallel activity –Needs to be part of the development methodology, not an afterthought Simple integration points require 2 translations instead of 1 –Performance considerations –Initial development effort may be higher Dependency on application packages –Should be independent from the applications, but needs to be similar enough to enable mapping –Avoid lowest common denominator Additional expertise and skill sets required –Object modeling –UML or other notation –Tool skill like Rational Rose

13. 13 How to Get Started? Get familiar with UML Class Diagrams –Look at the whole UML spec; it supports a great use-cases driven development cycle –Read the book, not the OMG spec (unless you suffer from insomnia) Get a tool like Rational Rose or Visio Professional Dedicate a resource to be the owner of the Domain Model More in the upcoming presentation: “Middleware Integration Methodology“

14. 14 Resources, Questions, Comments Contact Info: Gregor Hohpe, 415-783-5255, ghohpe@dc.comghohpe@dc.com Internal Web Site: http://wrsc/vitriahttp://wrsc/vitria Internal Web Site: http://eTIhttp://eTI Book: “UML Distilled, 2 nd Edition” by Martin Fowler, Addison-Wesley Book