Transcript SOFTWARE DEVELOPMENT - Zhejiang University

DISTRIBUTED SOFTWARE
DEVELOPMENT
Lan Jin
Tsinghua University
California State University, Fresno
 Component Based Development
 Remote Calling Communication
Model
 Design by Contract
 Component Assembly
 Jini Connection Technology
COMPONENT-BASED
DEVELOPMENT
BASIC IDEAS
 CBD — the 3rd “spark” of s/w development.
 to build s/w out of prepackaged components.
 S/w component — binary unit of independent
production, acquisition, and deployment.
 S/w comp. encapsulates state & functionality.
 A s/w component can be plugged into distributed applications in its predesigned form.
 S/w component has a behavior specification
as its formal description, that can be used
for the purpose of software verification.
 S/w component’s interface is defined by IDL.
COMPONENT-BASED
DEVELOPMENT
MOTIVATION
 Motivation 1: emphasis on software reuse.
 Motivation 2: success of the techniques for
building GUIs, DBs, … out of components.
 Motivation 3: the push for interconnection
technologies: CORBA, DCOM, JavaBeans.
 Motivation 4: generalization of object tech.
 Motivation 5: high cost of monolithic products.
 Motivation 6: The distributed computing model
fosters the development of s/w components.
COMPONENT-BASED
DEVELOPMENT
Characteristics
 a well-defined, well-documented interface
defining the services the comp. provides
 software independence from its clients
 encapsulated implementation
 remote access
 reusability thru abstraction and encapsulation
characteristics of objects.
 robustness: incorporate self-managing features,
comm. seamlessly via messaging protocols.
REMOTE CALLING
COMMUNICATION MODEL
Interface Definition Language
 2 factors for s/w components to work together:
• a well-defined interface
• a common mechanism of communication
 IDL+behavior specification give the 1st factor.
 IDL defines the names and type signatures of
the component’s attributes and operations.
 Distributed component infrastructures:
• Sun’s Java RMI
• Object Management Group(OMG)’s CORBA
• Microsoft’s DCOM
REMOTE CALLING
COMMUNICATION MODEL
Remote Method Invocation (RMI)
 Remote object reference specifies the remote
object to receive RMI.
 Remote interface provides a definition of the
methods available for RMI, same as using IDL.
 Remote reference module translates b/w local
& remote object references & creates a table.
 RMI compiler generates the proxy (one per
remote object), dispatcher and skeleton (for
each class of a remote object).
REMOTE CALLING
COMMUNICATION MODEL
Major Steps of a RMI
1. invoke RMI via proxy for B.
2. martial arguments, call rrm to translate to remote object
3,4. Send the message and receive the message.
ref.
5. select the method in the skeleton.
6. call rrm to translate into remote object B, unmartial the arg.
1
Object A
remote
ref. module
2
6
2
Proxy for B
11
3
4
Comm.
module
Comm.
module
10
9
dispatcher
CLIENT
remote
ref. module
SERVER
6
5
Skeleton
for B
8
11
7. execute the method, return the result.
8. martial the result in a reply message.
9,10. send the message and receive the message.
11. call rrm for the object A, unmartial the result.
Object B
7
REMOTE CALLING
COMMUNICATION MODEL
OMG’s CORBA
 A language- & platform-independent architecture
for interoperable distributed s/w components.
 allows client to invoke methods in a server
written in a different language by using IDL.
 4 categories of distributed objects defined in
OMG IDL communicate over the ORB bus.
1. Basic
services
Object
services
2. Horizontal,
4. end-user
3. useful in
across
functions
appl. domains vertical areas which use 1,2,3
Common
facilities
Domain
objects
Application
objects
ORB
Object Request Broker
REMOTE CALLING
COMMUNICATION MODEL
C-S Computing with CORBA
 ORB provides bidirectional location-independent
remote object access.
 GIOP or IIOP: Inter-ORB Protocol, a common
backbone for inter-vendor compatibility.
 ORB intercepts method invocation from client
object & routes it to a server.
 Object adapter: runtime functionality demanded
by servers, component registration support.
 Interface Repository API: allows component to
obtain & modify published interfaces.
 Flexible dynamic interface services (DII, DSI)
 Naming service and Trader service
REMOTE CALLING
COMMUNICATION MODEL
Microsoft’s DCOM
 first shipped with Windows NT 4.0.
 employs a binary standard to provide language
independence across multiple platforms.
 separates interface from functionality using
an IDL based on the Open Group’s DCE.
 A type library is created by compiling the
component’s IDL. Clients use type libraries
to determine component’s interface.
 IDL is neither CORBA-, nor DCE-compliant.
 DCOM’s RPC mechanism extends DCE RPC.
REMOTE CALLING
COMMUNICATION MODEL
DCOM’s Components
Globally unique CLSID identifies COM comp.
Globally unique IID identifies interface.
All COM interfaces inherit from IUnknown.
QueryInterface() method of IUnknown obtains
a specific pointer from a comp. instance.
 All published interfaces are immutable.




CLSID,IID
IUnknown
vtable
COM
Class
COM factory
component
component
COM server
Object
creation
REMOTE CALLING
COMMUNICATION MODEL
C-S Computing with DCOM
 vtable: a table of double pointers to implement
a component interface.
 Client instantiates a component instance by
calling CoCreateInstance function.
 DCOM runtime system returns a pointer to the
desired interface.
 3 exec. contexts to instantiate components:
◊ in-process — vtable directly points to comp.
◊ local — vtable points to the proxy for IPC.
◊ remote — same as local w/ proxy/stub pair.
Design by Contract
Behavioral Specification
 the formal description of what is supposed
to happen when software executes.
 Tools can use specification to verify software
behavior statically or dynamically.
 Specification constructs can be embedded in
a high-level language for the same purpose.
 Design by contract solves the problem of
behavioral specification for classes in an
object-oriented program.
 Design by contract makes behavioral specification more accessible to programmers.
Design by Contract
Boolean Invariants,
Preconditions, & Postconditions
 The model views a contract between a class
and its clients in the form of assertions.
 Boolean invariants & preconditions document
the contractual obligations for a client.
 Boolean invariants & postconditions document
the class supplier’s contractual obligations.
 Design by contract assumes the language
support of assertions.
 During testing, the system can monitor assertions embedded in the source code.
Design by Contract
BISCOTTI
 A Java extension to evaluate the use of design
by contract to add behavioral specification
constructs to Java RMI interfaces.
 carry behavioral-specification constructs
through to the Java class that implements
an interface.
 use Java’s exception-handling capabilities
to enable runtime monitoring of assertions.
 ensure that a valid Java program is a valid
Biscotti program.
 ensure that the JVM does not need any change
to run a Biscotti program.
Component Assembly
Challenges
 Challenges of building component based DS:
 not to change component’s source code
 to maintain objects’ implicit dependencies
 Solution: assembly approach separates
architecture, component, and distributed
object infrastructure concerns.
 Architecture defines components in the system.
 Component view concerns comp. composition
and implementation.
 Distributed object infrastructure view concerns
inter-comp. communication and protocols.
Component Assembly
JavaBeans
 use ports and links to isolate core component
functions from inter-comm. mechanisms.
 implement the framework using JavaBeans.
 JavaBeans uses facilities for reflection:
dynamically discover an object’s structure
 manipulate the object using the information
extracted from its .class file

 extend JavaBeans using SoftBeans to refer
to components.
 A PortDescriptor class extends PropertyDescriptor class. A SoftBeanInfo interface
extends BeanInfo interface.
Component Assembly
JavaBean’s Component Model
 Four elements define component’s boundary.
Service
provided
m
m
e
Events observed
Internal
component
Service
required
e
e
Events generated
e
m
m
m
e
 Three component interaction styles:
• event-event:
publish event-listener registration and
event dispatch methods.
observe events by event-listener interface
• service-service
IUnknown interface & QueryInterface op.
• event-service
Event generated triggers service provided
Component Assembly
Ports and Links
Port
ServicePort
EventPort
DiscreteServicePor
SessionServicePort
t
DiscreteServiceProvidePor
similar to
the left
tDiscreteServiceRequirePort
EventGeneratePort
EventObservePort
Link
ServiceLink
SessionServiceLink
EventLink
DiscreteServiceLin
k
LocalSessionServiceLink
IIOPServiceLink
RMISessionServiceLink
EventServiceLink
Component Assembly
Sample Component Assembly
 An architectural design of the Shopper pattern
RMIDiscreteServiceLink
IIOPDiscreteServiceLink
session
Shopper
m
getSuppiers(…)
m
Supplier
DB
m
Consumer
m
m
session
m
Warehouse
Store
shop(…)
m
discrete
buy(…)
buy(…)
Consumer
m
m
IIOPSessionServiceLink
LocalDiscreteServiceLink
discrete
getSuppiers(…)
e
Warehouse
shop(…)
lowSupply event
m
lowSupply event
principals
m
e
shop(…)
Store
getSupply(…)
m
getSupply(…)
sell(…)
RMIEventLink
m
Store
AssociatedStore
m
Store
Jini Connection Technology
“Plug and Play”
 Jini — a way to add new devices to a network.
 An approach to creating distributed systems
based on services implemented as h/w or s/w.
 Real core of Jini technology:
dynamic combination of moving objects from
the service to the client on demand.
 Jini takes over two services:


Discovery and Join: find the Jini lookup services on a network and join the party.
lookup: list the services available on the
network and the pointers to them.
Jini Connection Technology
Infrastructure
 Three sets of interfaces that define common
interaction patterns b/w client and server:
a way of leasing resources for some
period.
 a two-phase commit protocol to coordinate
diff. services in a transactional fashion.
 a way of receiving event notification.

Network
services
Jini
Java spaces
Other services
Discovery & Join
Lookup
Java
Java
Mac
Platform Solaris
Sparc PowerPC
Three Interfaces:
 Leasing
 Transactions
 Distributed events
Java
Java
Windows Other OS
Intel X86 Other cpu