cs551 object oriented middleware (iii) (chap. 5 of edo)
DESCRIPTION
CS551 Object Oriented Middleware (III) (Chap. 5 of EDO). Yugi Lee STB #555 (816) 235-5932 [email protected] www.cstp.umkc.edu/~yugi. Outline. Heterogeneous Programming Languages Common Object Model Common Interface Definition Language Programming Language Bindings - PowerPoint PPT PresentationTRANSCRIPT
CS551 - Lecture 141
CS551 Object Oriented Middleware (III) (Chap. 5 of EDO)
Yugi Lee
STB #555(816) 235-5932
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)
11CS551 - Lecture 14
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
12CS551 - Lecture 14
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
13CS551 - Lecture 14
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.
14CS551 - Lecture 14
• 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
15CS551 - Lecture 14
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.
16CS551 - Lecture 14
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).
17CS551 - Lecture 14
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
18CS551 - Lecture 14
Interworking Mapping IssuesInterworking Mapping Issues
• Interface Mapping
• Interface Composition Mapping
• Identity Mapping
• Mapping Invertibility
• Interface Mapping
• Interface Composition Mapping
• Identity Mapping
• Mapping Invertibility
19CS551 - Lecture 14
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++:
20CS551 - Lecture 14
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
21CS551 - Lecture 14
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
22CS551 - Lecture 14
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
23CS551 - Lecture 14
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