1 successful middleware integration using a common domain model october, 2000 gregor hohpe

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

Upload: abigayle-gray

Post on 25-Dec-2015

212 views

Category:

Documents


0 download

TRANSCRIPT

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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