CS551 Object Oriented Middleware (III) (Chap. 5 of EDO)

CS551 - Lecture 141

CS551 Object Oriented Middleware (III) (Chap. 5 of EDO)

Yugi Lee

STB #555(816) 235-5932

[email protected]

www.cstp.umkc.edu/~yugi

2CS551 - Lecture 14

OutlineOutline

• Heterogeneous Programming Languages– Common Object Model– Common Interface Definition Language– Programming Language Bindings

• Heterogeneous Middleware– Interoperability– Interworking

• Heterogeneous Data Representation– Standardized Data Representation– Application-Level Transport Protocol– Virtual Machines

• Heterogeneous Programming Languages– Common Object Model– Common Interface Definition Language– Programming Language Bindings

• Heterogeneous Middleware– Interoperability– Interworking

• Heterogeneous Data Representation– Standardized Data Representation– Application-Level Transport Protocol– Virtual Machines

3CS551 - Lecture 14

Heterogeneous Programming Languages

• Components of distributed systems are written in different programming languages

• Programming languages may or may not have their own object model

• Object models largely vary

• Differences need to be overcome in order to facilitate integration

4CS551 - Lecture 14

PLPL66

PLPL22

PLPL55

PLPL11

PLPL44

PLPL33 PLPL66

PLPL22

PLPL55

PLPL11

PLPL44

PLPL33IDLIDL

Why do we use an IDL?Why do we use an IDL?

5CS551 - Lecture 14

IDLIDL

CommonObjectModel

CommonObjectModel

SmalltalkSmalltalk

CobolCobol

JavaJava

Ada-95Ada-95C++C++

CC

CORBA Programming Language BindingsCORBA Programming Language Bindings

6CS551 - Lecture 14

Interface Definition LanguageInterface Definition Language

• Language for expressing all concepts of the middleware’s object model, e.g., OMG object model and OMG/IDL; MIDL

• Object Model: Meta-model for middleware’s type system – defines meaning of object type, operation, attribute, request,

exception, subtyping,

– defines general enough for mappings to most programming languages

• Interface Definition Language (IDL)

– Programming-language independent

– Bindings to different programming languages are needed

– not computationally complete

• Language for expressing all concepts of the middleware’s object model, e.g., OMG object model and OMG/IDL; MIDL

• Object Model: Meta-model for middleware’s type system – defines meaning of object type, operation, attribute, request,

exception, subtyping,

– defines general enough for mappings to most programming languages

• Interface Definition Language (IDL)

– Programming-language independent

– Bindings to different programming languages are needed

– not computationally complete

7CS551 - Lecture 14

Heterogeneous Middleware

Component

Component

Component

MiddlewareVendor A

Component

MiddlewareVendor B

Component

Component

Component

MiddlewareVendor C

8CS551 - Lecture 14

Often Different Middleware RequiredOften Different Middleware Required

• Middleware implementations differ:– Available programming language bindings– Available services & facilities – Supported hardware platforms– Supported operating system platforms

• Separation of security domains.

• Large scale distributed systems.

• Middleware implementations differ:– Available programming language bindings– Available services & facilities – Supported hardware platforms– Supported operating system platforms

• Separation of security domains.

• Large scale distributed systems.

9CS551 - Lecture 14

ORBORB

OLE

RPC

BridgeBridge

ORB

ComponentComponentComponentComponent

ComponentComponent

ComponentComponent

ComponentComponent

ComponentComponent

ComponentComponent

Middleware IntegrationMiddleware Integration

10CS551 - Lecture 14

BridgingBridging

Client

ORB CoreORB Core

Obj. Imp.Client

ORB CoreORB Core

Obj. Imp.

DSI DII

• in-line: built into the middleware (interoperability protocol)

• in-line: built into the middleware (interoperability protocol)

• request-level:built on top of middleware (client and server surrogate objects)

• request-level:built on top of middleware (client and server surrogate objects)


Middleware IntegrationMiddleware Integration

• Interoperability: the ability of different implementations of the same middleware standard to work together. – Definition of interaction protocols

– General Inter-ORB Protocol(GIOP), Internet Inter-ORB Protocol (IIOP), etc.

• Interworking: how different middleware standards are integrated. – Mapping of different object models

– Definition of interaction protocols

• Interoperability: the ability of different implementations of the same middleware standard to work together. – Definition of interaction protocols

– General Inter-ORB Protocol(GIOP), Internet Inter-ORB Protocol (IIOP), etc.

• Interworking: how different middleware standards are integrated. – Mapping of different object models

– Definition of interaction protocols


Interoperability vs. InterworkingInteroperability vs. Interworking

• Interoperability between different implementations of the same standard (CORBA, DCE)

• Interworking between different standards– CORBA COM/DCOM/OLE

• The order to resolve:– First CORBA interoperability– Then COM/CORBA interworking

• Interoperability between different implementations of the same standard (CORBA, DCE)

• Interworking between different standards– CORBA COM/DCOM/OLE

• The order to resolve:– First CORBA interoperability– Then COM/CORBA interworking


Interoperable Object ReferencesInteroperable Object References

• Object references are opaque for clients.

• Vendors choose reference implementation.

• Reference cannot be interchanged.

• Interoperable object references are used to present references to ORBs in their native format.

• Object references are opaque for clients.

• Vendors choose reference implementation.

• Reference cannot be interchanged.

• Interoperable object references are used to present references to ORBs in their native format.


• General Inter-ORB Protocol (GIOP) – Define seven messages: Request, Reply, Locate Request,

Locate Reply, Cancel request, Close Connection, Message Error

– Common Data Representation is defined as part of GIOP for Mapping of IDL data types to transport byte stream

• Internet Inter-ORB Protocol (IIOP): – Maps GIOP to TCP/IP.

– Provides operations to open and close TCP/IP connections.

– Is required from ORBs for CORBA compliance.

– Supported by Netscape Communicator.

• General Inter-ORB Protocol (GIOP) – Define seven messages: Request, Reply, Locate Request,

Locate Reply, Cancel request, Close Connection, Message Error

– Common Data Representation is defined as part of GIOP for Mapping of IDL data types to transport byte stream

• Internet Inter-ORB Protocol (IIOP): – Maps GIOP to TCP/IP.

– Provides operations to open and close TCP/IP connections.

– Is required from ORBs for CORBA compliance.

– Supported by Netscape Communicator.

Interoperability Protocols


Motivation for InterworkingMotivation for Interworking

• COM and OLE/Automation are widely used for desktop integration of PC applications– Compound documents– Visual Basic / Visual C++ User Interfaces.

• OMG has no support for compound documents and user interfaces yet.

• COM and OLE do not support distribution.

• CORBA was designed to support distribution.

• COM and OLE/Automation are widely used for desktop integration of PC applications– Compound documents– Visual Basic / Visual C++ User Interfaces.

• OMG has no support for compound documents and user interfaces yet.

• COM and OLE do not support distribution.

• CORBA was designed to support distribution.


COM-CORBA InterworkingCOM-CORBA Interworking

• Goal: provide transparent bi-directional mapping between COM/OLE and CORBA.

• Adopted specification was submitted by consortium of 11 ORB vendors.

• Most of them have COM/OLE Interworking implemented in their ORB products.

• Adopted in March 1996.• Microsoft decided not to be involved in this effort but

rather pursue its own distributed object environment (DCOM).

• Goal: provide transparent bi-directional mapping between COM/OLE and CORBA.

• Adopted specification was submitted by consortium of 11 ORB vendors.

• Most of them have COM/OLE Interworking implemented in their ORB products.

• Adopted in March 1996.• Microsoft decided not to be involved in this effort but

rather pursue its own distributed object environment (DCOM).


Object System AObject System A Object System BObject System B

objrefin A

objrefin A

BridgeBridge

objrefin B

objrefin B

View in A oftarget in BView in A oftarget in B

target objectimplementation in B

target objectimplementation in B

Interworking ArchitectureInterworking Architecture


Interworking Mapping IssuesInterworking Mapping Issues

• Interface Mapping

• Interface Composition Mapping

• Identity Mapping

• Mapping Invertibility

• Interface Mapping

• Interface Composition Mapping

• Identity Mapping

• Mapping Invertibility


Heterogeneous Data RepresentationHeterogeneous Data Representation

• Hosts of client and server might use different data representation formats.

• Different Character Encoding Schemes

• Different programming languages use different data representations, e.g. Character string “abc” in Pascal or C++:

• Hosts of client and server might use different data representation formats.

• Different Character Encoding Schemes

• Different programming languages use different data representations, e.g. Character string “abc” in Pascal or C++:


MotivationMotivation

• Data representations have to be converted between heterogeneous client and server objects

• Conversion should be transparent to application developer

• Conversion may be done in– Presentation layer implementation– Application layer implementation– Platform implementation

• Data representations have to be converted between heterogeneous client and server objects

• Conversion should be transparent to application developer

• Conversion may be done in– Presentation layer implementation– Application layer implementation– Platform implementation


ApproachesApproaches

• Presentation Layer: Standardized Data Representation– Sun’s External Data Representation (XDR)– OMG’s Common Data Representation (CDR)– OpenGroup’s Network Data Representation (NDR)

• Application layer: use of abstract syntax notation e.g– ASN.1– XML & SGML– STEP

• Platform: Virtual Machine, e.g. Java

• Presentation Layer: Standardized Data Representation– Sun’s External Data Representation (XDR)– OMG’s Common Data Representation (CDR)– OpenGroup’s Network Data Representation (NDR)

• Application layer: use of abstract syntax notation e.g– ASN.1– XML & SGML– STEP

• Platform: Virtual Machine, e.g. Java


Key PointsKey Points

• Heterogeneity can arise in– Programming Language– Middleware– Data Representation

• CORBA and COM resolve programming language heterogeneity by using an IDL with programming language bindings

• Middleware heterogeneity is resolved by interworking and interoperability specifications

• Heterogeneity can arise in– Programming Language– Middleware– Data Representation

• CORBA and COM resolve programming language heterogeneity by using an IDL with programming language bindings

• Middleware heterogeneity is resolved by interworking and interoperability specifications


Key PointsKey Points

• Data Heterogeneity may be resolved by– Standardized Data Representations

• CDR, NDR, XDR– Application-level Data Structuring

• XML, SGML, Step, ASN.1– Virtual Machines

• JVM

• Data Heterogeneity may be resolved by– Standardized Data Representations

• CDR, NDR, XDR– Application-level Data Structuring

• XML, SGML, Step, ASN.1– Virtual Machines

• JVM

CS551 Object Oriented Middleware (III) (Chap. 5 of EDO)

Documents

Transcript of CS551 Object Oriented Middleware (III) (Chap. 5 of EDO)