lecture course service-oriented computing 2. basics...
TRANSCRIPT
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
SOC'12 @ Sokendai 3Fuyuki Ishikawa
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
SOC'12 @ Sokendai 5Fuyuki Ishikawa
Before OO (1)
var1var2
var3var4
proc1proc2
proc3proc4
program1
program2
Data (Global Variables) Functionalities (Procedures)
Structured Programming (Procedure-Oriented)
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
SOC'12 @ Sokendai 6Fuyuki Ishikawa
Before OO (2)
var1var2
var3var4
proc1proc2
proc3proc4
program1
program2
Data (Global Variables) Functionalities (Procedures)
Structured Programming (Procedure-Oriented)
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
SOC'12 @ Sokendai 7Fuyuki Ishikawa
Before OO (3)
var1var2
var3var4
proc1proc2
proc3proc4
program1
program2
Data (Global Variables) Functionalities (Procedures)
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
SOC'12 @ Sokendai 8Fuyuki Ishikawa
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
OO Approach: Object (2)
invoke method3!
SOC'12 @ Sokendai 9Fuyuki Ishikawa
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
OO Approach: Object (3)
SOC'12 @ Sokendai 10Fuyuki Ishikawa
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
SOC'12 @ Sokendai 11Fuyuki Ishikawa
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
OO Approach: Class (2)
SOC'12 @ Sokendai 12Fuyuki Ishikawa
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)
OO Approach: Class (3)
SOC'12 @ Sokendai 13Fuyuki Ishikawa
Review of Object-Oriented ProgrammingDistributed Objects
MotivationsRequired Mechanisms
CORBAOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms
TOC
14Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai 15Fuyuki Ishikawa
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)
SOC'12 @ Sokendai 16Fuyuki Ishikawa
Initial Web Application Model (e.g., CGI)
Networked Applications
Client Server
Web Browser Web Server DBMS(Database Server)
High Complexity(Bad Maintainability)
High Load(Low QoS)
Server
SOC'12 @ Sokendai 17Fuyuki Ishikawa
PresentationApplication Logic Data
Three-Tier Web Application Model
Networked Applications
Client Server
Web Browser Application Server
DBMS(Database Server)
Complexity and Load Managementby Component Decomposition
Server
Web Server
Server
SOC'12 @ Sokendai 18Fuyuki Ishikawa
Presentation Application Logic Data
Application Server
N-Tier Model, or Distributed Objects
Networked Applications
Client ServerServersServer
Complexity and Load Managementby Further Component Decomposition
SOC'12 @ Sokendai 19Fuyuki Ishikawa
Web BrowserDBMS
(Database Server)
Web Server
Presentation
Application Logic
Data
Note: a component is also a unit of duplication
Networked Applications
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
SOC'12 @ Sokendai 20Fuyuki Ishikawa
Review of Object-Oriented ProgrammingDistributed Objects
MotivationsRequired Mechanisms
CORBA and Other MechanismsOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms
TOC
21Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai 22Fuyuki Ishikawa
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
SOC'12 @ Sokendai 23Fuyuki Ishikawa
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
SOC'12 @ Sokendai 24Fuyuki Ishikawa
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
SOC'12 @ Sokendai 25Fuyuki Ishikawa
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?)
SOC'12 @ Sokendai 26Fuyuki Ishikawa
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
SOC'12 @ Sokendai 27Fuyuki Ishikawa
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)
SOC'12 @ Sokendai 28Fuyuki Ishikawa
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)
SOC'12 @ Sokendai 29Fuyuki Ishikawa
Review of Object-Oriented ProgrammingDistributed Objects
MotivationsRequired Mechanisms
CORBA and Other MechanismsOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms
TOC
30Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai 31Fuyuki Ishikawa
SOC'12 @ Sokendai 32Fuyuki Ishikawa
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
SOC'12 @ Sokendai 33Fuyuki Ishikawa
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
SOC'12 @ Sokendai 34Fuyuki Ishikawa
1. The client program obtains the object reference of the server object by using a naming service
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
SOC'12 @ Sokendai 35Fuyuki Ishikawa
2. The client program uses either- Static Invocation Interface (generated in advance)- Or Dynamic Invocation Interface (generated on demand)
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
SOC'12 @ Sokendai 36Fuyuki Ishikawa
3. The underlying ORB handles translation from platform-dependent formats into common network ones
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
SOC'12 @ Sokendai 37Fuyuki Ishikawa
4. The underlying ORB handles translation fromcommon network formats into platform-dependent ones
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
SOC'12 @ Sokendai 38Fuyuki Ishikawa
5. The underlying object adapter, which manages object lifecycles, activating the required object if necessary
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
SOC'12 @ Sokendai 39Fuyuki Ishikawa
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
SOC'12 @ Sokendai 40Fuyuki Ishikawa
Review of Object-Oriented ProgrammingDistributed Objects
MotivationsRequired Mechanisms
CORBA and Other MechanismsOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms
TOC
41Fuyuki IshikawaSOC'12 @ Sokendai
ORB
CORBA: Invocation Model
Client Object Server Object
TCP/IP
ORBImplementation1
ORB Implementation2
Static Invocation Interface
(Stub/Proxy)
Dynamic Invocation Interface
Static SkeletonInterface
Dynamic SkeletonInterface
Object AdapterObject Adapter
SOC'12 @ Sokendai 42Fuyuki Ishikawa
SOC'12 @ Sokendai 43Fuyuki Ishikawa
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();…
SOC'12 @ Sokendai 44Fuyuki Ishikawa
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
SOC'12 @ Sokendai 45Fuyuki Ishikawa
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
SOC'12 @ Sokendai 46Fuyuki Ishikawa
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
SOC'12 @ Sokendai 47Fuyuki Ishikawa
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
SOC'12 @ Sokendai 48Fuyuki Ishikawa
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
SOC'12 @ Sokendai 49Fuyuki Ishikawa
CORBA: Call Types
ClientObject
ServerObject
Synchronous Call One-way Call Asynchronous Call
HandlerObject
request
response
request request
response
blocked not blocked
SOC'12 @ Sokendai 50Fuyuki Ishikawa
ClientObject
ServerObject
ClientObject
ServerObject
Review of Object-Oriented ProgrammingDistributed Objects
MotivationsRequired Mechanisms
CORBA and Other MechanismsOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms
TOC
51Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai 52Fuyuki Ishikawa
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
SOC'12 @ Sokendai 53Fuyuki Ishikawa
Review of Object-Oriented ProgrammingDistributed Objects
MotivationsRequired Mechanisms
CORBA and Other MechanismsOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms
TOC
54Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai 55Fuyuki Ishikawa
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
SOC'12 @ Sokendai 56Fuyuki Ishikawa
Review of Object-Oriented ProgrammingDistributed Objects
MotivationsRequired Mechanisms
CORBA and Other MechanismsOverviewInvocation ModelServicesCommunication ProtocolsNotes on Other Mechanisms
TOC
57Fuyuki IshikawaSOC'12 @ Sokendai
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
SOC'12 @ Sokendai 58Fuyuki Ishikawa
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
SOC'12 @ Sokendai 59Fuyuki Ishikawa
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
SOC'12 @ Sokendai 60Fuyuki Ishikawa
Apr 25Basics: XML
Characteristics as a Markup LanguageSchema Definition LanguagesProgramming ModelsUse in Distributed Computing
61Fuyuki Ishikawa
Next
SOC'12 @ Sokendai