Lecture Course Service-Oriented Computing 2. Basics ...research.nii.ac.jp/~f-ishikawa/work/Soken-SOC/SOC... · CORBA: Overview ORB:Object Request Broker Functionalities for interoperation

Fuyuki Ishikawa （石川冬樹）[email protected]

Lecture CourseService-Oriented Computing

2. Basics: Distributed Objects2012/04/18

1 Introduction

2 Basics: Distributed Objects

3 Basics: XML

4 Web Services: Foundations

5 Web Services: Composition

6 Web Services: Implementation

7 Related Topics (1): Reliability

SOC'12 @ Sokendai 2Fuyuki Ishikawa

Course Plan

8 Related Topics (2): Security

9 Related Topics (3): Engineering

10 Related Topics (4): Semantic Web

11 Cloud Computing (1): Overview

12 Cloud Computing (2): Experience

13 Discussion and Summary

14 Students’ Presentation


Course Plan

Review of Object-Oriented ProgrammingDistributed Objects

MotivationsRequired Mechanisms

CORBAOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms

TOC

4Fuyuki IshikawaSOC'12 @ Sokendai

Structured Programming (Procedure-Oriented)

Dependencies through global variablesDifficulties in preventing destructive modification of variable values, or unexpected side effects


Before OO (1)

var1var2

var3var4

proc1proc2

proc3proc4

program1

program2

Data (Global Variables) Functionalities (Procedures)


Decomposition of the application functionality into procedures

Procedures understandable and meaningful only from the global viewpoint of the application, not reusable in a more general context


Before OO (2)

var1var2

var3var4

proc1proc2

proc3proc4

program1

program2



Implicit interdependencies among data and functionalities

Side effects of modification to other parts Difficulties in reusing meaningful combinations of data and functionalities, especially extending them


Before OO (3)

var1var2

var3var4

proc1proc2

proc3proc4

program1

program2


Combine related data and functionalities as a unit of modularizationCan explicitly model the relationships among data and functionalitiesMove from functionality-oriented to object-orientedModularization becomes dependent on not the application but the natural concepts in the real world

OO Approach: Object (1)

Object : a thing that has - attributes (or fields, properties)- methods (operations or behaviors)

Object1attribute1 method1attribute2 method2


Message passing or method invocationObjects interact with each other by sending messages (requests)

The result can differ depending on the state of the receiving object, even if the same messages are sent


invoke method3!


Object1attribute1 method1attribute2 method2

Object2attribute3 method3

method4

EncapsulationAs objects interact with each other only by message passing (not by manipulating data directly):The requester object does not need to know inside of the provider object but need only to know the interfaceThe provider object can change its inside without affecting its requester objectsThe provider object can be sure its data can be modified only in a way it defines in the object



Provide a notion to group objects that have same types of attributes, and same methods

OO Approach: Class (1)

Class: abstract characteristics that define a thing (object), including its attributes and methods

Object1attributeA1 method1attributeB1 method2


Object2attributeA2 method1attributeB2 method2

ClassPattributeAattributeA method1method1attributeBattributeB method2method2

InheritanceA class (subclass) can inherit attributes and methods from another (superclass), and have more:Reusability is improved based on specialization relationships: creating a new subclassReusability is improved based on generalization relationships: creating a new superclassCommon parts and specialized parts are separated clearly



ClassPattributeAattributeA method1method1

method2method2

Class-subPattributeAattributeA method1method1attributeBattributeB method2method2

method3method3

PolymorphismDifferent functionalities can be obtained by invoking a method of the same name, appropriately according to the context A subclass can define a method of the same name as in the superclass, and give it a different functionality (override)A class can define multiple methods of the same name with different arguments, and give them different functionalities (overload)





CORBAOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms

TOC


Distributed: use functionalities and resources provided by remote computers through networks

Difficulties in allocating all the required functionalities and resources (e.g., CPU, memory, etc.) in one local computer

Objects: embed functionalities with data as a unit for deployment on a networked computer

Difficulties in managing functionalities and data separately given their inter-dependenciesDifficulties in managing combinations without a granular unit of combined components


Why Distributed Objects?

Basic Client Server Model

Networked Applications

Client Server

Client Application

DBMS(Database Server)

Presentation Application Logic Data

High Complexity(Bad Maintainability)

High Load(Low QoS)


Initial Web Application Model (e.g., CGI)


Client Server

Web Browser Web Server DBMS(Database Server)

High Complexity(Bad Maintainability)

High Load(Low QoS)

Server


PresentationApplication Logic Data

Three-Tier Web Application Model


Client Server

Web Browser Application Server

DBMS(Database Server)

Complexity and Load Managementby Component Decomposition

Server

Web Server

Server


Presentation Application Logic Data

Application Server

N-Tier Model, or Distributed Objects


Client ServerServersServer

Complexity and Load Managementby Further Component Decomposition


Web BrowserDBMS

(Database Server)

Web Server

Presentation

Application Logic

Data

Note: a component is also a unit of duplication


Load Distribution and Fault Toleranceby Component Duplication

More flexibleif components are granular(e.g., duplicate only a high-

load calculation component)

Deploy the same functionalityon different servers




CORBA and Other MechanismsOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms

TOC


Call a method m of an object o with an argument of a variable x!

Obtain the memory addresses of o and m

Read and run the command sequences of m while accessing the value of x


How to Access Local Objects?

Call a method m of a remote object o with an argument of a variable x!

Obtain the memory addresses of o and mThe requester side does not know this information

Read and run the command sequences of m using the value of xThe provider side does not know this information


How to Access Remote Objects?

Call a method m of a remote object o with an argument of a variable x!

Obtain the memory addresses of o and mThe requester side does not know this informationNeed identifiers of the object and the method with other information for access via networkRead and run the command sequences of m using the value of xThe provider side does not know this informationNeed a request including the variable value (not the reference) for access via network


How to Access Remote Objects?

Location Transparency: in short, we want to access remote objects as if they were local, not to care about where the target objects are

Preferably, Migration Transparency: we do not need to care about migration of deployed remote objectsFault Transparency: we do not need to care about faults in (part of) remote objects, network connections, or servers

Needs supporting infrastructure


General Requirements: in a Nutshell

Need identifiers of the object and the method with other information for access via network

The identifiers need to include pairs of a network address and a port numberThe identifiers should be abstract names rather than meaningless id values

Use some mechanism to correlating global identifiers and local ones(including common problems in information sharing in distributed computing: e.g., in advance or on demand? centralized or P2P/multicast?)


General Requirements (1)

Need a request including the variable value (not the reference) for access via network

It is very helpful if we can use remote objects implemented in different languages/platforms

Use common formats through networks while hiding the differences (e.g., little v.s. big endian)

Such functionalities for interoperation may beImplemented statically as components dedicated to access to specific objects/methodsOr activated dynamically through general-purpose components to handle interoperation


General Requirements (2)

ORB: Object Request BrokerA piece of middleware that allows for messaging (or programming calls) via networks

IDL: Interface Definition LanguageA type of language used to describe interface (e.g., available methods) of objects

General Terminology (1)


Stub and SkeltonComponents that handle format translation and so on for interoperation, at the requester side and the provider side, respectively

Marshalling and UnmarshallingTranslation from platform-dependent formats to common network formats, and the opposite, respectively

General Terminology (2)





TOC


CORBA: Common Object Request Broker Architecture

Defines a specification of infrastructure for interoperable distributed objects

Not an implementation (system, library, or middleware)

Provided by OMG (Object Management Group)A consortium for standardization of (originally) distributed object-oriented systems

Implemented in many languagesJava, C++, .NET, Python, Ruby, ...

CORBA: Overview



CORBA: Overview

ORB: Object Request Broker

Functionalities for interoperation between distributed objects

Application ObjectsDefinition of interfaces for access to application-specific objects

CORBA FacilitiesApplication-level common functionalities such as DB access

Objects

CORBA ServicesBasic functionalities such as naming, transaction, etc.

Domain InterfacesInterfaces defined for business domains, such as financial, manufacturing, etc.

TCP/IP

ORB

CORBA: Overview

ORB Implementation 1

Object1 (C++ on Linux)

ORB Implementation 2

Object2 (Java on Windows)

- Hide differencesin implementation

- Use commonprotocols to interact

Client Server


ORB

CORBA: Overview of Invocation Procedure

Client Object Server Object

TCP/IP

ORBImplementation1

ORB Implementation2

Static Invocation Interface

(Stub/Proxy)

Dynamic Invocation Interface

Static SkeletonInterface

Dynamic SkeletonInterface

Object AdapterObject Adapter


1. The client program obtains the object reference of the server object by using a naming service

ORB



TCP/IP

ORBImplementation1

ORB Implementation2


(Stub/Proxy)






2. The client program uses either- Static Invocation Interface (generated in advance)- Or Dynamic Invocation Interface (generated on demand)

ORB



TCP/IP

ORBImplementation1

ORB Implementation2


(Stub/Proxy)






3. The underlying ORB handles translation from platform-dependent formats into common network ones

ORB



TCP/IP

ORBImplementation1

ORB Implementation2


(Stub/Proxy)






4. The underlying ORB handles translation fromcommon network formats into platform-dependent ones

ORB



TCP/IP

ORBImplementation1

ORB Implementation2


(Stub/Proxy)






5. The underlying object adapter, which manages object lifecycles, activating the required object if necessary

ORB



TCP/IP

ORBImplementation1

ORB Implementation2


(Stub/Proxy)






6. The server program receives the request via either- Static Skelton Interface (generated in advance)- Or Dynamic Skelton Interface (generated on demand)

CORBA 1.x (1991-)Core concepts such as remote invocation modelsLack in heterogeneity support(only the C language, no communication protocols)

CORBA 2.x (1996-)Extensions for heterogeneity support

Mapping to C++, Smalltalk, COBOL, Ada, and JavaCommunication protocols for interoperability

CORBA 3.x (2002-, 3.2 in Nov 2011)Script languages, asynchronous invocation, ...

CORBA: History





TOC


ORB

CORBA: Invocation Model


TCP/IP

ORBImplementation1

ORB Implementation2


(Stub/Proxy)







CORBA: Static Invocation Interface

IDL: Interface Definition Language

Module HelloWorld {interface{string sayHello();

}}

StubClass

Class HelloWorld {String sayHello(){

// generated codes to// invoke remote objects

}…

Client Program1. An IDL complier generates

a stub for the targetplatform/language2. The client program

uses the local stubobject and invokeits methods Stub (Proxy)

Object

3. An instantiated stub objectacts as a proxy for the remote objectand activates the remote invocation

generates

instantiatedTo

invokesRemoteMethod

invokes

…HelloWorld hw = …String str = hw.sayHello();…


CORBA: Static Skeleton Interface

IDL: Interface Definition Language

Module HelloWorld {interface{string sayHello();

}}

SkeletonClass

abstract Class HelloWorld {abstract String sayHello();// other generated methods to// handle remote invocation

}

Server Class1. An IDL complier generates

a skeleton for the targetplatform/language2. The server program

implements the skeletonclass

generates

implements

…String sayHello(){return "hello!";

}…

Runtime ServerObject

instantiatedTo

reveiveRequestsFromRemote

3. An instantiated server objecthandles requests from remote clients


CORBA: IDLIDL (Interface Definition Language) : A language for specification of object interfaces, independent of particular programming languages

module StockObjects {struct Quote {

string symbol; long at_time;…

}; exception Unknown{}; interface Stock {

Quote get_quote() raises(Unknown);void set_quote(in Quote stock_quote);readonly attribute string description;

};…};

IDL compliers generate codes in particular programming languages (language mapping)

Stub: codes for a client to handle remote objects as if they were local objectsSkeleton: code templates for a server to provide its own implementation

High performance (only) for fixed interactionsUse of type checking mechanisms with generated stubs or skeletons

CORBA: Static Interface


Stub: a client-side object that acts as a gatewayReceives requests from client programs and conducts actual remote invocationAllow client programs to handle remote objects as if they were local

Skeleton: a server-side object that acts as a gateway

Handles requests from remote objects to a local server objectAllow server programs to concentrate on the internal implementation of the server object


CORBA: Stub and Skeleton

Dynamic interfaces are also available: manually constructing/handling request messages

e.g., invokeRemoteMethod(objRef, methodName, args)

Heavy, but flexible binding to implementatione.g., runtime discovery, resolving and invocation of objects and their methodse.g., customized allocation of incoming requests to implementing objects

CORBA: Dynamic Interface


Needs for management of object lifecyclese.g., it is not necessary to keep all the server objects active (loaded on the memory) Manage the following

Threads to handle incoming requestsPersistence of objectsActivation of objects

Object adaptersPortable Object Adapter (POA) specification (ver 2.2)

Refinement of Basic Object Adapter (BOA, ver 1.0)

CORBA: Object Adapter


CORBA: Call Types

ClientObject

ServerObject

Synchronous Call One-way Call Asynchronous Call

HandlerObject

request

response

request request

response

blocked not blocked


ClientObject

ServerObject

ClientObject

ServerObject




TOC


CORBA Services for basic functionalitiesProvided as CORBA objects, which can be easily incorporated into application programsIncludes fundamental functionalities such as

Naming: discover available remote objects by namesEvent: register, publish and subscribe events either in the push model or the pull modelTransaction: use commitment protocols to manage rollback and commit operations for consistent execution

CORBA: CORBA Services


e.g., Naming ServiceProvides functionalities to register/unregister naming informationManages naming graphs

A hierarchical structure of naming contexts, which can contain other naming contexts and object references

e.g., Japan Tokyo Chiyoda NII LectureServiceNaming graphs are not necessarily "trees"

Can be DAG, or even can have loopsAn object can have multiple names

CORBA: CORBA Service





TOC


GIOP: General Inter-ORB ProtocolDefines message and data formats for interoperability between ORB implementation

The data format is called CDR: Common Data Representation

Is related to marshalling and unmarshallingMarshalling: the client-side ORB implementation translates its platform-dependent format into CDRUnmarshalling: the server-side ORB implementation translates CDR into its platform-dependent format

CORBA: Communication Protocols


IIOP: Internet Inter-ORB ProtocolComplements GIOP

GIOP is a pure application-level protocol, which does not define relationships with lower-layer protocols (typically TCP/IP)

Bridges the gap between GIOP and TCP/IPProvides object references based on network addresses

Using IP address, port number as well as the key (identifier) for the object

CORBA: Communication Protocols





TOC


Many of the presented notions are very common and not specific to CORBA(actually almost common in web services)

ORBIDLStub/SkeletonMarshalling/UnmarshallingSynchronous/Asynchronous Calls

Notes


DCOM by MicrosoftSimilar models to CORBA, but different strength (e.g., transaction support)History

From COM: Component Object Model (1995) for interoperability between local objects implemented by different languages and compiled into binary formatsTo DCOM: Distributed COM (1996, Windows NT 4.0), COM+ (2000, Windows 2000)(Recently .NET has become much more popular)

COM-based Distributed Objects


JavaIDLIDL compiler is provided in Java: CORBA objects can be developed in Java

Also supports call back e.g., later return the value when update occurs

JavaRMI (Remote Method Invocation)Distributed object mechanism in JavaSimilar mechanisms to those of CORBA

Does not need IDL but just use Java interfacesEasier development when the system is relatively small and developed only using Java

Java-based Distributed objects


Apr 25Basics: XML

Characteristics as a Markup LanguageSchema Definition LanguagesProgramming ModelsUse in Distributed Computing

61Fuyuki Ishikawa

Next

SOC'12 @ Sokendai

Documents

Lecture Course Service-Oriented Computing 2. Basics ...research.nii.ac.jp/~f-ishikawa/work/Soken-SOC/SOC... · CORBA: Overview ORB:Object Request Broker Functionalities for interoperation