1 / 14

Successful Middleware Integration Using a Common Domain Model

Successful Middleware Integration Using a Common Domain Model. October, 2000 Gregor Hohpe. Middleware Enables Data Exchange Between Applications. Application A stores customer information (name, address, …) Application B stores customer information (name, address, …)

kirk-soto
Download Presentation

Successful Middleware Integration Using a Common Domain Model

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 B Application A Customer Customer

  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 B Application A Mapping Customer Customer

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

  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 B Application A Mapping Customer Customer Mapping Application C Mapping Customer

  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 Customer Customer Customer Customer Customer

  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 B Application A Mapping Mapping Customer Customer Application C Mapping Customer Common Domain Model

  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. 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 Reporting /Data Warehousing Application B Application A Mapping Mapping Customer Customer Application C BusinessLogic Mapping Customer Common Domain Model B2BIntegration ExternalPartners

  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) Entity Customer Contact Aggregation(Customer has Sites) 0..N Association Location Primary Contact Specialization(Billing Location is a type of Location) BillingLocation ServiceLocation More info on UML: Book “UML Distilled, 2nd ed.” by M. Fowlerhttp://www.omg.orgUML Brownbag (wrsc/sf/portal)

  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 Contact 0..N Location Primary Contact Message Specification Domain Model

  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. 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. Resources, Questions, Comments • Contact Info: Gregor Hohpe, 415-783-5255, ghohpe@dc.com • Internal Web Site: http://wrsc/vitria • Internal Web Site: http://eTI • Book: “UML Distilled, 2nd Edition” by Martin Fowler, Addison-Wesley ?

More Related