1 successful middleware integration using a common domain model october, 2000 gregor hohpe
TRANSCRIPT
![Page 1: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/1.jpg)
1
Successful Middleware Integration Using a Common Domain Model
October, 2000
Gregor Hohpe
![Page 2: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/2.jpg)
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 Customer
![Page 3: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/3.jpg)
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 Customer
Mapping
![Page 4: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/4.jpg)
4
Adding Another Application Requires Additional Mapping
One mapping unit has to be created between each pair of applications
Application A Application B
Customer Customer
Mapping
Customer
Application CMapping
![Page 5: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/5.jpg)
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 Customer
Mapping
Customer
Application CMapping
Mapping
![Page 6: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/6.jpg)
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
CustomerCustomer
CustomerCustomer
CustomerCustomer
CustomerCustomer
CustomerCustomerCustomerCustomer
![Page 7: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/7.jpg)
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 AApplication B
Customer Customer
Mapping
Customer
Application C
Mapping
Mapping
Common Domain Model
![Page 8: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/8.jpg)
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)
![Page 9: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/9.jpg)
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 CustomerMapping
Customer
Application C
Mapping
MappingBusinessLogic
B2BIntegration
Reporting /Data Warehousing
Common Domain Model
ExternalPartners
![Page 10: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/10.jpg)
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
BillingLocation
ServiceLocation
Contact
Primary Contact
Entity
Aggregation(Customer has Sites)
Specialization(Billing Location is a type of Location)
Association0..N
More info on UML: Book “UML Distilled, 2nd ed.” by M. Fowlerhttp://www.omg.orgUML Brownbag (wrsc/sf/portal)
![Page 11: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/11.jpg)
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 Specification Domain Model
![Page 12: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/12.jpg)
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
![Page 13: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/13.jpg)
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“
![Page 14: 1 Successful Middleware Integration Using a Common Domain Model October, 2000 Gregor Hohpe](https://reader036.vdocuments.us/reader036/viewer/2022072011/56649e0b5503460f94af2e30/html5/thumbnails/14.jpg)
14
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