Successful middleware integration using a common domain model
This presentation is the property of its rightful owner.
Sponsored Links
1 / 14

Successful Middleware Integration Using a Common Domain Model PowerPoint PPT Presentation


  • 42 Views
  • Uploaded on
  • Presentation posted in: General

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, …)

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Successful middleware integration using a common domain model

Successful Middleware IntegrationUsing a Common Domain Model

October, 2000

Gregor Hohpe


Middleware enables data exchange between applications

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


Generally a translation between the application specific data formats is required

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


Adding another application requires additional mapping

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


What happens if more than one application is allowed to update the information

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


This approach introduces a large number of tightly coupled point to point connections

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


Define a common domain model to replace an unmanageable number of point to point mappings

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


A common domain model addresses a variety of issues related to middleware integration

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)


A common domain model is the platform for future extensions

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


The common domain model is described in uml notation

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)


The common domain model is different from the middleware message specification

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


Using a common domain model successfully requires special skill and experience

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


How to get started

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“


Resources questions comments

Resources, Questions, Comments

  • Contact Info: Gregor Hohpe, 415-783-5255, [email protected]

  • Internal Web Site: http://wrsc/vitria

  • Internal Web Site: http://eTI

  • Book: “UML Distilled, 2nd Edition” by Martin Fowler, Addison-Wesley

?


  • Login