Middleware CS3254

1
MiddlewareCS3254

• Joel Wein
• Note As is true of many of my slides, these draw
  heavily from the teaching slides of Coulouris,
  Dollimore and Kindberg
• (http//www.cdk4.net)

2
Outline

• Elevator Summary
• Cleaner way of thinking about communications and
  organization in distributed systems
• Background Concepts
• Heterogeneity (CDK 1.4)
• External data representation (CDK 4.3)
• RMI/RPC
• Examples
• Java RMI case study (CDK 5.5)
• CORBA
• XML/Webservices
• XML-RPC

3
Background Concepts Heterogeneity

• Applies to all of the following
• networks
• Internet protocols mask the differences between
  networks
• computer hardware
• e.g. data types such as integers can be
  represented differently
• operating systems
• e.g. the API to IP differs from one OS to another
• programming languages
• data structures (arrays, records) can be
  represented differently
• implementations by different developers
• they need agreed standards so as to be able to
  interwork
• Middleware provides a programming abstraction and
  masks the heterogeneity of networks etc.

4
Figure 4.1Middleware layers
5
External Data Representation and Marshalling (CDK
4.3)

• Data structures must be flattened (converted to a
  sequence of bytes) before transmission and
  rebuilt on arrival.
• Representations are machine and OS-specific.
• To enable two computers to exchange data values
• Values can be converted to an agreed external
  format before transmission and converted to local
  form on receipt.
• Values can be sent in senders format with a
  description of format.

6
Marshalling

• Marshalling The process of taking a collection
  of data items and assembling them into a form
  suitable for transmission in a message.
• Unmarshalling Disassembling them on arrrival to
  produce equivaent collection of data items at the
  destination.

7
Approaches

• Some approaches to external data representation
  and marshalling
• CORBAs common data representation
• Usable by multiple languages
• Javas object serialization
• Flattening and external data representation of
  any single object or tree of objects that may
  need to be transmitted in a message or stored in
  a disk.
• SUN XDR (RFX 1832). Developed by SUN for use in
  client-server communication in SUN NFS.
• All of these marshall primitive data types into
  binary form as opposed to ASCII text (HTTP).

8
CORBA CDR

• 15 primitive types
• Constructed types Primitive values that comprise
  each constuctued type are added to a sequence of
  bytes in a particular order.

9
CORBA CDR for constructed types (Figure 4.7)
10
CORBA CDR message (Fig. 4.8)
11
Marshalling in CORBA

• Marshalling operations can be generated
  automatically from the specification of the types
  of data items to be transmitted in a message.
• Types of data structures and basic data items
  described in CORBA IDL (Interface Def. Language)
• CORBA interface compiler generates appropriate
  marshalling and unmarshalling operations.

12
Java Object Serialization

• Object an instance of a java class
• Serializable interface allows instances to be
  serialized.
• Serialization Flattening an object or connected
  set of objects into a serial form that is
  suitable for storing on dis or transmitting in a
  message.
• Some information about the class of each object
  included in serialized form, allowing recipient
  to load appropriate class when object
  deserialized.
• Information about class name and version number.

13

• Java objects can contain references to other
  objects.
• When object serialized, all references serialized
  together with it to ensure that when
  reconstructed all references can be fulfilled at
  the destination.
• Handles
• Make sure object written only once.

14
Javas use of Reflection

• Reflection Ability to enquire about properties
  of a class, such as names and types of instance
  variables and methods.
• Enables classes to be created from names,
  constructors created.
• Makes it possible to do serialization and
  dserialization in a completely generic manner.
• No need to generate special marshallinh functions
  for each type of object.

15
Remote Object References

• Identifier for a remote object that is valid
  throughout a distributed system.

16
Representation of a remote object reference
Figure 4.10

• a remote object reference must be unique in the
  distributed system and over time. It should not
  be reused after the object is deleted. Why not?
• the first two fields locate the object unless
  migration or re-activation in a new process can
  happen
• the fourth field identifies the object within the
  process
• its interface tells the receiver what methods it
  has (e.g. class Method)
• a remote object reference is created by a remote
  reference module when a reference is passed as
  argument or result to another process
• it will be stored in the corresponding proxy
• it will be passed in request messages to identify
  the remote object whose method is to be invoked

17
Figure 4.11Request-reply communication
Server
Client
Request
doOperation
getRequest
message
select object
execute
(wait)
method
Reply
sendReply
message
(continuation)
18
Figure 4.12Operations of the request-reply
protocol
public byte doOperation (RemoteObjectRef o, int
methodId, byte arguments) sends a request
message to the remote object and returns the
reply. The arguments specify the remote object,
the method to be invoked and the arguments of
that method. public byte getRequest
() acquires a client request via the server
port. public void sendReply (byte reply,
InetAddress clientHost, int clientPort) sends
the reply message reply to the client at its
Internet address and port.
19
Figure 4.14RPC exchange protocols
20
Distributed object model
Figure 5.3

• each process contains objects, some of which can
  receive remote invocations, others only local
  invocations
• those that can receive remote invocations are
  called remote objects
• objects need to know the remote object reference
  of an object in another process in order to
  invoke its methods.
• the remote interface specifies which methods can
  be invoked remotely

21
Invocation semantics

• Local invocations are executed exactly once
• Remote invocations cannot achieve this. Why not?
• the Request-reply protocol can apply
  fault-tolerance measures

22
Invocation semantics failure model

• Maybe, At-least-once and At-most-once can suffer
  from crash failures when the server containing
  the remote object fails.
• Maybe - if no reply, the client does not know if
  method was executed or not
• omission failures if the invocation or result
  message is lost
• At-least-once - the client gets a result (and the
  method was executed at least once) or an
  exception (no result)
• arbitrary failures. If the invocation message is
  retransmitted, the remote object may execute the
  method more than once, possibly causing wrong
  values to be stored or returned.
• if idempotent operations are used, arbitrary
  failures will not occur
• At-most-once - the client gets a result (and the
  method was executed exactly once) or an exception
  (instead of a result, in which case, the method
  was executed once or not at all)

23
The architecture of remote method invocation
Figure 5.6
RMI software - between application level objects
and communication and remote reference modules

24
Introduction to CORBA

• The Object Management Group (OMG) was formed in
  1989. Its aims were
• to make better use of distributed systems
• to use object-oriented programming
• to allow objects in different programming
  languages to communicate with one another
• The object request broker (ORB) enables clients
  to invoke methods in a remote object
• CORBA is a specification of an architecture
  supporting this.
• CORBA 1 in 1990 and CORBA 2 in 1996.

25
Introduction to CORBA
Don't be put off by GIOP and IIOP They are just
names for familiar things
The architecture allows for mixed languages

• The main components of CORBAs RMI framework are
• An interface definition language known as IDL.
• An architecture.
• The General Inter-ORB protocol (GIOP) defines
• an external data representation, called CDR
• specifies formats for the messages in a
  request-reply protocol.
• including messages for enquiring about the
  location of an object, for cancelling requests
  and for reporting errors.
• The Internet Inter-ORB protocol (IIOP) defines a
  standard form for remote object references.
• IIOP is GIOP implemented in TCP/IP
• CORBA services - generic services useful in
  distributed applications e.g. Naming Service,
  Event Service.

GIOP is just about external data
representation and a Request-reply protocol
allowing for objects to be activated
IIOP is just about remote object references

26
CORBA RMI

• CORBA RMI is a multi-language RMI system.
• The programmer needs to learn the following new
  concepts
• the object model offered by CORBA
• the interface definition language and its mapping
  onto the implementation language. (e.g. a struct
  in IDL is mapped onto what in Java?)
• CORBA's object model
• similar to the remote object model in Chapter 5
  (what are the main features?)
• clients are not necessarily objects (why not?) a
  client can be any program that sends request
  messages to remote objects and receives replies.
• The term CORBA object is used to refer to remote
  objects.
• a CORBA object implements an IDL interface, has a
  remote object reference and its methods can be
  invoked remotely.
• A CORBA object can be implemented by a language
  without classes.
• the class concept does not exist in CORBA.
• therefore classes cannot be defined in CORBA IDL,
  which means that instances of classes cannot be
  passed as arguments.

27
CORBA IDL interfaces Shape and ShapeList
Differences from a Java remote inteface?
why are argument types defined in the IDL? (not
necerssary in Java remote interfaces)
struct Rectangle long width long
height long x long y
struct GraphicalObject string type
Rectangle enclosing boolean isFilled
interface Shape long getVersion()
GraphicalObject getAllState() // returns
state of the GraphicalObject
typedef sequence ltShape, 100gt All interface
ShapeList exception FullException
Shape newShape(in GraphicalObject g) raises
(FullException) All allShapes() // returns
sequence of remote object references long
getVersion()
Figure 17.1

28
Parameters in CORBA IDL

• Passing CORBA objects
• Any parameter or return value whose type is
  specified by the name of a IDL interface, e.g.
  Shape, is a reference to a CORBA object (see
  newShape)
• and the value of a remote object reference is
  passed.
• Passing CORBA primitive and constructed types
• Arguments of primitive and constructed types are
  copied and passed by value. On arrival, a new
  value is created in the recipients process.
  E.g., the struct GraphicalObject (argument of
  newShape and result of getAllState)
• Note the method allShapes returns an array of
  remote object references as follows
• typedef sequence ltShape, 100gt All
• All allShapes()
• Type Object - is a supertype of all IDL
  interfaces (its values are object references).
  When would it be useful? Hint
• Think about the name server

29
CORBA Naming Service (see Section17.3.1)

• It is a binder that provides methods including
• rebind for servers to register the remote object
  references of CORBA objects by name (e.g. rebind
  (path, Object) e.g of 2nd argument?
• resolve for clients to look them up by
  name.(e.g.Object resolve(path))
• these methods belong to an interface called
  NamingContext (Fig 17.10)
• The names are structured in a hierarchy,
• a path is an array of NameComponent (a struct
  with a name in it)
• the path starts from an initial context provided
  by CORBA
• This makes access in a simple example seem rather
  complex!
• The name service is present in all CORBA
  installations. (Its role is like the Java RMI
  registry)
• Its use will be shown in program examples

30
Illustration of programming CORBA

• We illustrate CORBA with a Java client and server
• The interface compiler is called idltojava
• when given an IDL interface, it produces
• server skeletons for each class (e.g.
  _ShapeListImplBase)
• proxy classes (e.g. _ShapeListStub)
• a Java class for each struct e.g. Rectangle,
  GraphicalObject
• helper classes (narrow method) and holder classes
  (for out arguments)
• the equivalent Java interfaces (e.g. ShapeList
  below)

31
(No Transcript)
32
The ShapeListServant class of the Java server
program for the CORBA interface ShapeList. Figure
17.3

• A Java server has classes for its IDL interfaces
  (e.g. Shape and ShapeList). Here is the class
  ShapeListServant

This class has to create CORBA objects of type
Shape. How does it do that?
import org.omg.CORBA. class ShapeListServant
extends _ShapeListImplBase ORB
theOrb private Shape theList private int
version private static int n0 public
ShapeListServant(ORB orb) theOrb orb
// initialize the other instance
variables public Shape newShape(GraphicalObjec
t g) throws ShapeListPackage.FullException
version Shape s new
ShapeServant( g, version) if(n gt100)
throw new ShapeListPackage.FullException()
theListn s
theOrb.connect(s) return s
public Shape allShapes() ...
public int getVersion() ...
CORBA objects are instances of servant
classes. In non-OO languages implementations of
CORBA objects cant be classes. What might they
be in C?

33
Java class ShapeListServer (the server class)
import org.omg.CosNaming. import
org.omg.CosNaming.NamingContextPackage. import
org.omg.CORBA. public class ShapeListServer
public static void main(String args)
try ORB orb ORB.init(args, null)

ShapeListServant shapeRef new
ShapeListServant(orb) orb.connect(shapeR
ef)
org.omg.CORBA.Object objRef
orb.resolve_initial_references("NameService")
NamingContext ncRef
NamingContextHelper.narrow(objRef) NameCompone
nt nc new NameComponent("ShapeList",
"") NameComponent path
nc ncRef.rebind(path, shapeRef)

java.lang.Object sync new
java.lang.Object() synchronized (sync)
sync.wait() catch (Exception e) ...
Figure 17.4

34
Java client program for CORBA interfaces Shape
and ShapeList
import org.omg.CosNaming. import
org.omg.CosNaming.NamingContextPackage. import
org.omg.CORBA. public class ShapeListClient pu
blic static void main(String args)
try ORB orb ORB.init(args, null)
org.omg.CORBA.Object objRef
orb.resolve_initial_references("NameService")
NamingContext ncRef NamingContextHelper.nar
row(objRef) NameComponent nc new
NameComponent("ShapeList", "") NameComponent
path nc ShapeList shapeListRef
ShapeListHelper.narrow(ncRef.resolve(path))
Shape sList shapeListRef.allShapes()
GraphicalObject g sList0.getAllState()
catch(org.omg.CORBA.SystemException e) ...
Figure 17.5

35
The main components of the CORBA architecture

• The CORBA architecture is designed to allow
  clients to invoke methods in CORBA objects
• clients and objects can be implemented in a
  variety of programming languages
• it has the following additional components
  compared to Figure 5.6
• object adapter, implementation repository and
  interface repository

36

Figure 17.6

37
Object adapter

• an object adapter bridges the gap between
• CORBA objects with IDL interfaces and
• the programming language interfaces of the
  corresponding servant (classes).
• it does the work of the remote reference and
  despatcher modules in Fig. 5.6.
• An object adapter has the following tasks
• it creates remote object references for CORBA
  objects
• it dispatches each RMI via a skeleton to the
  appropriate servant
• it activates objects.
• An object adapter gives each CORBA object a
  unique object name.
• the same name is used each time an object is
  activated.
• it is specified by the application program or
  generated by the object adapter.
• Each active CORBA object is registered with its
  object adapter,
• which keeps a remote object table to maps names
  of CORBA objects to servants.
• Each object adapter has its own name - specified
  by the application program or generated
  automatically.

38
Implementation repository

• Implementation repository
• it activates registered servers on demand and
  locates running servers
• it uses the object adapter name to register and
  activate servers.
• it stores a mapping from the names of object
  adapters to the pathnames of files containing
  object implementations.
• when a server program is installed it can be
  registered with the implementation repository.
• when an object implementation is activated in a
  server, the hostname and port number of the
  server are added to the mapping.
• Implementation repository entry

- not all CORBA objects (e.g. call backs) need be
activated on demand - access control information
can be stored in an implementation repository

39
Interface repository

• it provides information about registered IDL
  interfaces
• for an interface of a given type it can supply
  the names of the methods and for each method, the
  names and types of the arguments and exceptions.
• a facility for reflection in CORBA.
• if a client has a remote reference to a CORBA
  object, it can ask the interface repository about
  its methods and their parameter types
• the client can use the dynamic invocation
  interface to construct an invocation with
  suitable arguments and send it to the server.
• the IDL compiler gives a type identifier to each
  IDL type
• a type identifier is included in remote object
  references
• this type identifier is called the repository ID
• because the interface repository stoes interfaces
  against their IDs
• applications that use static invocation with
  client proxies and IDL skeletons do not require
  an interface repository.
• Not all ORBs provide an interface repository.

40
CORBA IDL

• IDL provides facilities for defining modules,
  interfaces, types, attributes and method
  signatures.
• examples of all of the above, except modules, in
  Figures 5.2 and 17.1.
• IDL has the same lexical rules as C but has
  additional keywords to support distribution,
• for example interface, any, attribute, in, out,
  inout, readonly, raises.
• It allows standard C pre-processing facilities.
  e.g. typedef for All in Figure 17.7.
• The grammar of IDL is a subset of ANSI C with
  additional constructs to support method
  signatures.

41
Summary

• CORBA addresses heterogeneity
• RMI between a client and a remote remote object
  in different languages.
• GIOP
• specifies an external data representation called
  CDR clients and servers can have different
  hardware.
• specifies OS independent operations for
  request-reply protocol
• specifies a standard form for remote object
  references.
• IIOP implements the request-reply protocol over
  TCP/IP.
• Object adapter
• relates request messages to implementations of
  CORBA objects
• Implementation repository
• enables CORBA objects to be activated on demand
• Interface repository
• allows dynamic invocation of CORBA objects
• IDL for defining interfaces

42
WebServices

• Joel Wein

43
Outline

• Webservices
• XML
• SOAP
• WSDL

44
Webservices from the SUN Java Webservices
Tutorial

• Web services, in the general meaning of the term,
  are services offered via the Web. In a typical
  Web services scenario, a business application
  sends a request to a service at a given URL using
  the SOAP protocol over HTTP. The service receives
  the request, processes it, and returns a
  response. An often-cited example of a Web service
  is that of a stock quote service, in which the
  request asks for the current price of a specified
  stock, and the response gives the stock price.
  This is one of the simplest forms of a Web
  service in that the request is filled almost
  immediately, with the request and response being
  parts of the same method call.
• Another example could be a service that maps out
  an efficient route for the delivery of goods. In
  this case, a business sends a request containing
  the delivery destinations, which the service
  processes to determine the most cost-effective
  delivery route. The time it takes to return the
  response depends on the complexity of the
  routing, so the response will probably be sent as
  an operation that is separate from the request.
• Web services and consumers of Web services are
  typically businesses, making Web services
  predominantly business-to-business (B-to-B)
  transactions. An enterprise can be the provider
  of Web services and also the consumer of other
  Web services. For example, a wholesale
  distributor of spices could be in the consumer
  role when it uses a Web service to check on the
  availability of vanilla beans and in the provider
  role when it supplies prospective customers with
  different vendors' prices for vanilla beans.

45

• Web services depend on the ability of parties to
  communicate with each other even if they are
  using different information systems. XML
  (Extensible Markup Language), a markup language
  that makes data portable, is a key technology in
  addressing this need. Enterprises have discovered
  the benefits of using XML for the integration of
  data both internally for sharing legacy data
  among departments and externally for sharing data
  with other enterprises. As a result, XML is
  increasingly being used for enterprise
  integration applications, both in tightly coupled
  and loosely coupled systems. Because of this data
  integration ability, XML has become the
  underpinning for Web-related computing.

46
What is XML (More from SUN)

• XML is an industry-standard, system-independent
  way of representing data. Like HTML (HyperText
  Markup Language), XML encloses data in tags, but
  there are significant differences between the two
  markup languages. First, XML tags relate to the
  meaning of the enclosed text, whereas HTML tags
  specify how to display the enclosed text.

47
XML Example

• ltpriceListgt   
• ltcoffeegt     
• ltnamegtMocha Javalt/namegt
•      ltpricegt11.95 lt/pricegt  
•   lt/coffeegt
•   
• ltcoffeegt
•      ltnamegtSumatralt/namegt  
•     ltpricegt12.50lt/pricegt
•  lt/coffeegt
• lt/priceListgt
• The ltcoffeegt and lt/coffeegt tags tell a parser
  that the information between them is about a
  coffee. The two other tags inside the ltcoffeegt
  tags specify that the enclosed information is the
  coffee's name and its price per pound. Because
  XML tags indicate the content and structure of
  the data they enclose, they make it possible to
  do things like archiving and searching.

48
XML continued

• A second major difference between XML and HTML is
  that XML is extensible. With XML, you can write
  your own tags to describe the content in a
  particular type of document. With HTML, you are
  limited to using only those tags that have been
  predefined in the HTML specification. Another
  aspect of XML's extensibility is that you can
  create a file, called a schema, to describe the
  structure of a particular type of XML document.
  For example, you can write a schema for a price
  list that specifies which tags can be used and
  where they can occur. Any XML document that
  follows the constraints established in a schema
  is said to conform to that schema.

49

• Probably the most-widely used schema language is
  still the Document Type Definition (DTD) schema
  language because it is an integral part of the
  XML 1.0 specification. A schema written in this
  language is commonly referred to as a DTD. The
  DTD that follows defines the tags used in the
  price list XML document. It specifies four tags
  (elements) and further specifies which tags may
  occur (or are required to occur) in other tags.
  The DTD also defines the hierarchical structure
  of an XML document, including the order in which
  the tags must occur.
• lt!ELEMENT priceList (coffee)gt
• lt!ELEMENT coffee (name, price) gt
• lt!ELEMENT name (PCDATA) gt
• lt!ELEMENT price (PCDATA) gt

50
What Makes XML Portable?

• A schema gives XML data its portability. The
  priceList DTD, discussed previously, is a simple
  example of a schema. If an application is sent a
  priceList document in XML format and has the
  priceList DTD, it can process the document
  according to the rules specified in the DTD. For
  example, given the priceList DTD, a parser will
  know the structure and type of content for any
  XML document based on that DTD. If the parser is
  a validating parser, it will know that the
  document is not valid if it contains an element
  not included in the DTD, such as the element
  ltteagt, or if the elements are not in the
  prescribed order, such as having the price
  element precede the name element.

51
Webservices Elements

• SOAP
• The Simple Object Access Protocol (SOAP), an XML
  based communication protocol for interacting with
  Web services.
• The SOAP specification includes
• (1) a syntax to define messages (envelope, with
  optional header and body),
• (2) encoding/serialization rules for data
  exchange, and
• (3) conventions for representing RPCs.

52

• The SOAP message exchange model
• Upon receiving a message, the local application
  must
• identify the parts of the message intended for
  it,
• verify that the parts from step 1 are supported
  by the local application and process them
  accordingly (if not, the message is discarded),
• if the local application is not the final
  destination, the parts from step 1 have to be
  removed before the message is forwarded to its
  final destination.

53
WSDL

• The specifications (i.e., interface) of services
  can be described using WSDL (Web Services
  Description Language). WSDL is a general
  framework (based on XML) for describing network
  services as collections of communication
  endpoints capable of exchanging messages. It
  describes where a service is located, what
  operations are supported, and the format of the
  messages to be exchanged based on how the service
  is invoked. WSDL does not mandate a specific
  communication protocol used (it supports various
  bindings such as SOAP and HTTP).

54

• The Web service vision foresees a proliferation
  of services which in turn requires the
  availability of public directories that can used
  for the registration and lookup of services. UDDI
  (Universal Description, Discovery and
  Integration) provides a mechanism for service
  providers to advertise their services in a
  standard form and for service consumers to query
  services of interest, thereby paving the way for
  interoperability between services. A UDDI entry
  consists of white pages (e.g., address, contact
  information), yellow pages (e.g., industrial
  characterization based on standard ontologies),
  and green pages (e.g., references to
  specifications of services). UDDI is itself
  implemented as a Web service using SOAP as the
  message protocol.

55
(No Transcript)
56
(No Transcript)