1.What is binding? Explain dynamic binding in RPC with a neat figure.

Ans. Binding is the process whereby the client creates a local association for a given server in order to
invoke a remote procedure.

Dynamic binding allows a server to register the procedures it implements (steps 0 and 1). A
client can then ask for the address of the server implementing a given procedure (steps 2 and 3), obtain
the address from the binder (step 4), and make the call to the procedure (steps 5, 6, and 7), which then
proceeds as in the static case.
Dynamic binding creates many opportunities for improving RPC interaction. The directory
server could, for instance, keep track of which servers have been invoked and perform load balancing
so as to use resources as efficiently as possible. If the server changes location, it is enough to change
the entry in the directory server for requests to be rerouted to the new location. The result is the
decoupling of the client and the server, which adds a great deal of flexibility when deploying and
operating the system. The cost of this flexibility is additional infrastructure such as a directory server,
a protocol for interacting with the directory server, and primitives for registering procedures with the
server. These operations are, in principle, hidden from the programmer since they are performed by the
stubs. The server stub, for instance, registers the server procedures when the server is started. Similarly,
the client stub deals with the directory server when calls are made.

2. Explain the architecture and services provided by DCE platform.

Ans.
DCE provides not only a complete specification of how RPC should work but also a standardized
implementation. The goal of DCE was to give vendors a standard implementation that they could then
use and extend as needed for their own products. By using the same basic implementation of RPC, the
hope was that the resulting products would be compatible.
DCE platform provides RPC and a number of additional services that are very useful when
developing distributed information systems. These services include:
Cell directory service: The Cell directory is a sophisticated name and directory server used to
create and manage RPC domains that can coexist over the same network without interfering
with each other.
Time service: The Time service provides mechanisms for clock synchronization across all
nodes.
Thread service: DCE supports threads and multiple processors with the Thread service.
Distributed file service: The file service allows programs to share data files across a DCE
environment.
Security service: In a shared environment, such as the ones addressed by DCE, it is not
feasible to accept procedure calls from arbitrary clients. The Security service solves this
problem by providing authenticated and secure communication.

3. Explain the functionality and architecture of TP Monitor with a neat figure.

Ans.
 Interface. A client interface component provides a programmatic API as well as support for direct
access via terminal and authentication.
Program flow. The program flow component stores, loads, and executes procedures, possibly written
in a language provided by the TP monitor itself. Stored programs typically involve the invocation of
operations on logical resources, identified by their name.
Router. The router maps each operation to an invocation. The invocation can involve an underlying
resource manager (such as a database) or a local service provided by the TP monitor itself. The router
includes a special-purpose database that stores the definition of the mappings between logical resource
names and physical devices. In case of changes to the system configuration, the system administrator
needs only update this mapping; client applications do not need to be modified, because they access
resources based on logical names.
Communication manager. Communication with the resources, such as databases, occurs through a
communication manager module. This component can be a messaging system, possibly endowed
with transactional semantics to enable rollbacks and guaranteed delivery.
Wrappers. Wrappers hide the heterogeneity of the different resources linked by the TP monitor. This
simplifies the development of the communication module, as it does not depend upon the characteristics
of the individual resources.
 Transaction manager. Executions of distributed transactions go through a transaction manager that
executes the 2PC protocol, thereby guaranteeing the ACIDity of the procedures executed through the
TP monitor.
Services. Finally, a wide range of services is available to provide performance, high availability,
robustness to failures, replication, and so forth. In particular, performance management is one of the
most distinguishing features of a TP monitor.

FUNCTIONALITIES:
All the functionality and machinery necessary to support RPC (IDLs, name and directory
servers, security and authentication, stub compilers, and so on).
Programming abstractions for dealing with TRPC. These include RPC, BOT, and EOT, and
may also include call back mechanisms and additional support for implementing complex
workflow structures (such as on commit, on abort, and so on).
A transaction manager for implementing TRPC. The transaction manager includes a wide range
of functionality: logging, recovery, locking, and so forth. In modern TP monitors, this
functionality is usually implemented in separate components so that there is no need to activate
them if they are not needed. Some systems also provide interfaces to developers to access the
functionality of these modules so that application can also take advantage of it (e.g., to log
additional information about the state of the application).
A monitor system in charge of scheduling threads, assigning priorities, load balancing,
replication, starting and stopping components, and so forth. The monitor system provides
performance and flexibility to the TP monitor.
A run-time environment that acts as the computational background for all the applications that
use the TP monitor. This run-time environment provides the resources and services applications
may need (transactional services, security services, transactional file system, and so on.)
Specialized components tailored for particular scenarios or systems. These components range
from proprietary protocols for interacting with mainframe based systems to persistent queuing
systems for asynchronous interaction.
A wide variety of tools for installing, managing, and monitoring the performance of all these
components.

4. Give the high level view of the CORBA system architecture and explain how server stubs are
created.
Ans.
CORBA's IDL supports many object-oriented concepts such as inheritance and polymorphism. As with
RPC, IDL specifications can be fed to an IDL compiler that generates a stub and a skeleton. The stub
is a proxy object that hides the distribution and makes method calls in the client look as if they were
local instead of remote. The stub code includes the declarations of the methods provided by the object
implementation and is linked with the client code to obtain the executable client application. The
skeleton, on the other hand, shields the server object from all issues concerning the distribution, so that
it can be developed as though function calls were coming from a local object. Technically, to develop
a client object that interacts with a given server, all a programmer needs to know is the server's IDL
interface. Of course, the developer must be aware of the semantics of the interface methods as well as
of other constraints (such as a specific ordering in which the methods should be invoked to achieve a
certain goal). These aspects are not formalized and are assumed to be described by other means, such
as through comments in the IDL specifications or by exchanging descriptive documents.

5. Explain different aspects addressed by WS description and discovery stack.

Ans.
Service Description
Since the Web services approach is centered on the notion of "service", one of the first issues to be
addressed by its technology is what exactly a service is and how it can be described. Service description
in conventional middleware is based on interfaces and interface definition languages. In that context,
IDL specifications are needed to automatically generate stubs and to constitute the basis for dynamic
binding. The semantics of the different operations, the order in which they should be invoked, and other
(possibly non-functional) properties of the services are assumed to be known in advance by the
programmer developing the clients. This is reasonable, since clients and services are often developed
by the same team. In addition, the middleware platform defines and constrains many aspects of the
service description and binding process that are therefore implicit, and they do not need to be specified
as part of the service description. In Web services and B2B interactions, such implicit context is missing.
Therefore, service descriptions must be richer and more detailed, covering aspects beyond the mere
service interface.
 Common base language. The first problem to be addressed is the definition of a common
meta-language that can be used as the basis for specifying all the languages necessary to
describe the different aspects of a service. XML is used for this purpose, both because it is a
widely adopted and commonly accepted standard and because it has a syntax flexible enough
to enable the definition of service description languages and protocols.
Interfaces. Interface definition languages are at the base of any service oriented paradigm. In
Web services, interface definitions resemble CORBA like IDLs, although there are a few
differences between the two. The availability of different interaction modes in the interface
definition language and the XML schema-driven type system are two of them. In addition,
since (as mentioned above) Web services lack an implicit context (often there is no
centralized middleware), their description needs to be more complete. For example, it is
necessary to specify the address (URI) of the service and the transport protocol (e.g., HTTP)
to use when invoking the service. With this information, it is possible to construct a client that
invokes the operations offered by a Web service. The dominant proposal for IDLs in this area
is the Web Services Description Language (WSDL).
Business protocols. A Web service often offers a number of operations that clients must invoke
in a certain order to achieve their goals. In the procurement example, the customer will have to
first request a quote,then order the goods, and finally make a payment. Such exchanges between
clients and Web services are called conversations. Service providers typically want to impose
rules that govern the conversation, stating which conversations are valid and understood by the
service. This set of rules is specified as part of the so called business protocol supported by the
service (where the word "business" is used to differentiate it from a communication protocol).
Business protocols are examples of why simple interface description is not enough in Web
services. In fact, to completely describe a service, it is necessary to specify not only its interface
but also the business protocols that the service supports. In this regard, there are several
proposals to standardize the languages for defining business protocols (as opposed to
standardizing the protocols, discussed next). Examples are the Web Services Conversation
 Language (WSCL) and the Business Process Execution Language for Web Services (BPEL) .
This is nevertheless a rather immature area in terms of standardization at the time of writing.
Properties and semantics. Most conventional middleware platforms do not include anything
but functional interfaces in the description of a service. Again, this is because the system context
allows designers to infer other information needed to bind to a service, and because services
are tightly coupled. Web services provide additional layers of information to facilitate binding
in autonomous and loosely-coupled settings, where the service description is all that clients
have at their disposal to decide whether to use a service or not. For instance, this may include
non-functional properties such as the cost or quality of a service, or a textual description of the
service such as the return policy when making a purchase. This is information that is crucial for
using the service but is not part of what we traditionally understand as the interface of the
service. In Web services, such information can be attached to the description of a service by
using the Universal Description, Discovery, and Integration (UDDI) specification. This
specification describes how to organize the information about a Web service and how to build
repositories where such information canbe registered and queried.
Verticals. All the layers explained so far are generic. They standardize neither the contents of
the services nor their semantics (e.g., the meaning of a certain parameter or the effect of a
certain operation). Vertical standards define specific interfaces, protocols, properties, and
semantics that services offered in certain application domains should support. For example,
RosettaNet describes commercial exchanges in the IT world, standardizing all the aspects
described above. These vertical standards complement the previous layers by tailoring them to
concrete applications, further facilitating the use of standard tools for driving the exchanges.
Specifically, they enable the development of client applications that can interact in a meaningful
manner with any Web service that is compliant with a certain vertical standard.
Service Discovery
Once services have been properly described, these descriptions must be made available to those
interested in using them. For this purpose, service descriptions are stored in a service directory. These
directories allow service designers to register new services and allow service users to search for and
locate services. Service discovery can be done both at design-time, by browsing the directory and
identifying the most relevant services, and at run-time, using dynamic binding techniques.
These directories can be hosted and managed by a trusted entity (centralized approach) or otherwise
each company can host and manage a directory service (peer-to-peer approach). In both cases, APIs
and protocols are needed for clients to interact with the directory service or for the local directory
services to exchange information among themselves in a peer-to-peer fashion. The above-mentioned
UDDI specification defines standard APIs for publishing and discovering information into service
directories. It also describes how such directories should work.
6. Illustrate Two facets of WS Architecture.
Ans. The first aspect is related to the fact that Web services are a way to expose internal operations so
that they can be invoked through the Web. Such an implementation requires the system to be able to
receive requests through the Web and to pass them to the underlying IT system. In doing this, the
problems are analogous to those encountered in conventional middleware. We refer to such an
infrastructure as internal middleware for Web services. Correspondingly, we will use the term internal
architecture to refer to the organization and structure of the internal middleware. The other facet of
Web services architectures is represented by the middleware infrastructure whose purpose is to integrate
different Web services. We will refer to such an infrastructure as external middleware for Web services.
Correspondingly, we will use the term external architecture to refer to the organization and structure
of the external middleware. The external architecture has three main components:
Centralized brokers. These are analogous to the centralized components in conventional middleware
that route messages and provide properties to the interactions (such as logging, transactional guarantees,
name and directory services, and reliability). However, as we will see, in practice the name and directory
server is often the only centralized component present in Web services architectures.
Protocol infrastructure. This refers to the set of components that coordinate the interactions among
Web services and, in particular, implement the peer-to-peer protocols (such as the horizontal protocols
and the metaprotocols) whose aim is to provide middleware properties in those B2B settings where a
centralized middleware platform cannot be put in place due to trust and privacy issues.
Service composition infrastructure. This refers to the set of tools that
support the definition and execution of composite services.

7. With neat figure explain the different parts of wsdl service specification.
Ans.
WSDL specifications are often characterized by an abstract part, conceptually analogous to
conventional IDL and a concrete part, that defines protocol binding and other information. The abstract
part is made of port type definitions, which are analogous to interfaces in traditional middleware IDLs.
Each port type is a logical collection of related operations. Each operation defines a simple exchange
of messages. As described in the previous section, a message is a unit of communication with a Web
service, representing the data exchanged in a single logical transmission. As in the case of other Web
services standards, these constructs are all defined in XML.
WSDL needs a type system so that the data being exchanged can be correctly interpreted at both ends
of the communication. By default, WSDL uses the same type system as XML Schemas, although the
WSDL document can specify a different type system if necessary. So, the first step in defining a WSDL
interface is to identify and define all the data structures that will be exchanged as parts of messages
between applications. The second step is to define messages that build on such data structures. In
WSDL, each message is a typed document divided into paris. Each part is characterized by a name and
by a type, referring to a type typically defined in XML schema. The third step in defining a WSDL
interface is to define operations, also called transmission primitives or interactions. There are four basic
operations: one-way, request-response, solicit-response, and notification. One-way and notification
operations involve a single message. In one-way interaction, the client invokes a service by sending a
message. In notifications, it is the service that sends the message. Request-response and solicit-response
involve the exchange of two messages. The final step in defining an abstract WSDL interface is to group
operations into port types.
InterfaceBindings. The binding specifies the message encoding and protocol bindings for all
operations and messages defined in a given port type. For instance, it could specify that an operation is
an RPC-style operation or a document-style operation. An InterfaceBinding could also specify that the
messages of an operation have to be communicated using the SOAP protocol and HTTP transport
bindings. WSDL allows communications protocols other than SOAP to be used as well, although this
is rarely the case in reality.
Ports. Also known as EndPoints, ports combine the InterfaceBinding information with a network
address (specified by a URI) at which the implementation of the port type can be accessed. Again, this
is not needed in conventional middleware due to the presence of a centralized infrastructure
that manages addresses in a transparent manner.
Services. Services are logical grouping of ports. Note that, at least in principle, this also means that a
specific WSDL service could be available at different Web addresses (for example, different URIs
corresponding to different server machines, maybe one in Europe and one in Australia). It
could also combine very different port types.

8.Explain data structures of UDDI.

Ans.

Business Entity. It describes an organization that provides Web services. It lists the company's
name, address, and other contact information.
Business Service. This element describes a group of related Web services offered by a business
Entity. Typically, a business Service will correspond actually to one kind of service (such as a
procurement or a travel reservation service), but provided at different addresses, in multiple
versions, and through different technologies (e.g., different protocol bindings). Business
services, like business entities, can also include classification information. A business Entity
entry can include multiple business Service elements, but a business Service belongs to one and
only one business Entity (Figure 6.13).
Binding Template. This element describes the technical information necessary to use a
particular Web service. Essentially, it defines the address at which the Web service is made
available along with a set of detailed information, such as references to documents (called t
Models) describing the Web service interface or other service properties. It also defines how
operation parameters should be set and the default values for such parameters .A business
 Service entry can include multiple binding Template elements(one for each interface or
address), but a binding Template belongs to one and only one business Service.
tModel. The cryptic name stands for "technical model" , and it is a generic container for any
kind of specification. For example, it could represent a WSDL service interface, a classification,
or an interaction protocol, or it could describe the semantics of an operation. Unlike the previous
entities, tModels are not subject to parent-child relationships, and can be referred to by other
entities to denote conformance to an interface, or to classify businesses or services.

9.List UDDI registry APIs.

Ans.
The UDDI Inquiry API includes operations to find registry entries that satisfy search criteria
and to get overview information about those entities (find_business, find_service, find_binding,
find_tMode0, and operations that provide details about a specific entity (get_businessDetail,
get_serviceDetail, get_bindingDetail, geUModeLDetai0. This API is meant to be used by
UDDI browser tools that help developers find information and by clients at run-time, for
dynamic binding.
The UDDI Publishers API is directed to service providers. It enables them to add, modify, and
delete entries in the registry. Examples of operations it supports are save_business,
save_service, save_binding and save_tModel for creating or modifying entries, and
delete_business, delete_service, delete_binding, and delete_tModel for removing entries. Upon
publication, the registry also assigns unique keys to the newly added entries.
The UDDI Security API allows UDDI users to get and discard authentication tokens to be
used in further communication with the registry (get_auth Token, discard_auth Token).
The UDDI Custody and Ownership Transfer API enable registries to transfer the
"custody" of information among themselves and to transfer ownership of these structures
from One publisher to another. Messages exchanged in this API include geL transfer Token,
transfer_entities, and transfer_custody.
The UDDI Subscription API enables the monitoring of changes in a registry by subscribing
to track new, modified, and deleted entries. The Subscription API includes the following
operations: delete_subscription, get_subscriptionResults, get_subscriptions, and
save_subscriptions.
The UDDI Replication API supports replication of information between registries, so that
different registries can be kept synchronized.

10. Explain the three forms of interaction between a coordinator and its participants in WS
Coordination with neat figure.
Ans. WS-Coordination defines three forms of interactions between a coordinator and its participants:
Activation. A participant requests a coordinator to create a new coordination context. New contexts
are created whenever a participant initiates an instance of coordination type (a conversation). This
happens, for example, when a Web service initiates an atomic transaction.
Registration. A participant registers as a coordination protocol participant with a coordinator. By
registering, a Web service declares that it is participating in the execution of the protocol and that it
should be notified when the corresponding steps of the coordination protocol are executed. For example,
a Web service can register as a participant in an atomic transaction, thereby providing information about
its role and its port.
Protocol-specific interactions. The coordinator and its participants exchange messages that are
specific to a coordination protocol. For example, the coordinator can send commit or abort messages to
the participants, and specifically to the ports they have indicated in the registration phase.

Activation or creation of a coordination context in WS-Coordination

Interactions for activation and registration are independent of the type of coordination, i.e., they are
horizontal. In other words, they do not change from one coordination type to another. Hence, the
interfaces that should be implemented by coordinators and participants for these two types of
interactions are part of the WS-Coordination specification. On the other hand, interfaces needed for
protocol-specific interactions vary from protocol to protocol. As a result, WS-Coordination does not
specify those interfaces. Two port types are defined for the activation: ActivationCoordinatorPortType,
to be implemented by the coordinator, and ActivationRequestorPortType, to be implemented by a
participant (Figure 7.15). A Web service that initiates a new coordination sends a
CreateCoordinationContextRequest message to the ActivationCoordinatorPortType of the coordinator.
As part of this request, the Web service specifies the type of coordination it wants to initiate (e.g., atomic
transaction) as well as a reference to (the address of) its own ActivationRequestorPortType. The latter
is needed so that the coordinator knows where to send its response. The coordinator creates a new
context and sends it back to the Web service in a CreateCoordinationContextResponse message.

Registration in WS-Coordination
Although protocol-specific interfaces are not defined in WS-Coordination since they vary from protocol
to protocol, it is assumed that these too will come in pairs. For each protocol (say X), there will be a
participant port type (usually named XParticipantPortType) as well as a coordinator port type
(XCoordinatorPortType), as shown in Figure 7.17. The exact references to these ports are exchanged
between the coordinator and the participant through the registration process described above. To
simplify the discussion, we use the notation XCoordinatorPortType to denote the coordinator's protocol
specific interfaces and XParticipantPortType to denote the participant's protocol specific interfaces.

11. Explain distributed coordination with relevant diagrams.

1. A initiates a coordination instance by asking Ca to create a new coordination context.
2. Ca returns a coordination context Xl to A. The coordination context contains a reference to Ca's
RegistrationCoordinatorPortType.
3. A registers itself as a participant of protocol X with Ca by passing a reference to its
XParticipantPortType.
4. Ca returns a reference to its XCoordinatorPortType to A.
5. A sends a message to B within the scope of the coordination. To indicate the scope, it includes the
coordination context Xl it obtained in step 2 as part of the SOAP header.
6. B notices a coordination context Xl in the SOAP message it receives. It asks Cb to create a new
coordination context. It also indicates that the new context should be a sub-context of Xl.
7. Cb returns a coordination context X2 to B. X2 contains a reference to Cb'S Registration Coordinator
Port Type.
8. B registers with Cb as a participant of protocol X. B also passes the coordination context and its own
XParticipantPortType to Cb as part of the registration.
9. Cb registers as a participant of protocol X with Ca. By doing so, Cb informs Ca about who its
counterpart is with respect to protocol Xl, and can receive and forward all protocol messages from Ca
to B.
10. Ca returns to Cb with a reference to its XCoordinatorPortType. Cb uses it to forward protocol
messages from B to Ca.
11. Cb returns to B with a reference to its XCoordinatorPortType.
 Coordinator chaining for distributed coordination
Activation, or creation of coordination context, has two purposes: for the participant to get a new
context and for the coordinator to know its role in the overall protocol. If an existing coordination
context is passed as part of the CreateCoordinationContextRequest message, then the coordinator
realizes that it is a proxy to some other coordinator. The reference to the
RegistrationCoordinatorPortType of the other coordinator is already included in the passed
coordination context. This is how a proxy coordinator knows the reference to its primary coordinator.
On the other hand, if the Create CoordinationContextRequest message does not include an existing
coordination context, then the coordinator acts as if it is the primary coordinator.

12. What is Atomic Transaction? Give the different protocols used in Atomic
Transaction.
The first coordination type defined by WS-Transaction is Atomic Transaction. This coordination type
is composed of several coordination protocols, executed in sequence or in alternative by the
participating Web services or by the coordinator, depending on what must be done during the different
phases of a distributed transaction. Five protocols make up this coordination type: Completion, 2PC,
Completion WithAck, PhaseZero, and OutcomeNotification.
When a Web service wishes to complete a transaction, it executes a Completion protocol with the
coordinator. Its purpose is to inform the coordinator that it should start a 2PC protocol to verify the
outcome of the transaction and ask the participants to either commit or abort. 2PC is the standard two-
phase commit protocol with a prepare phase and a commit or abort phase. Once 2PC is executed and
the transaction is completed, the outcome is returned to the Web service. In some cases, before actually
starting the 2PC protocol, the coordinator may execute a PhaseZero protocol with the other participants.
The intention is to let all participants know that a 2PC protocol is about to commence1 . At any point
during or after the execution of a 2PC protocol, a participant can query the coordinator about the
outcome of the transaction (whether it has been committed or not) using the OutcomeNotification
protocol. Finally, the Completion WithAck protocol can be initiated by a Web service as an alternative
to the Completion protocol. The difference is that in the Completion WithAck protocol the coordinator
has to remember the outcome of a transaction without discarding it, until the requesting Web service
sends an acknowledgment that it has received the outcome. Corresponding to these protocols, the
standard specifies the following port types to be implemented by the coordinator (in addition to those
specified in WS-Coordination):
CompletionParticipantPortType and CompletionCoordinatorPortType
Completion WithAckParticipantPortType and Completion WithAckCoordinator PortType
PhaseZeroParticipantPortType and PhaseZeroCoordinatorPortType
2PCParticipantPortType and 2PCCoordinatorPortType
OutcomeNotificationParticipantPortType and OutcomeNotificationCoordinator Port Type

13. Explain the Rosettanet PIP specification.

A RosettaNet PIP specification describes how to implement a collaborative coordination protocol. Each
PIP specification includes a Technical Dictionary (that describes the components that are exchanged as
part of the process) and a Message Guideline document that includes a PIP-specific version of the
Business Dictionary (specifying the business properties and the PIP protocols) for
communicating properties between networked applications. RosettaNet distinguishes between two
categories of messages involved in PIP business document exchanges: "business action" messages and
"business signal" messages. Business actions are messages that contain business documents, such as a
Purchase Order or a Billing Statement. Business signals are messages
that indicate a positive or negative response to acknowledge the receipt of a business action message.
RosettaNet follows a four-step methodology to develop PIP specifications:
1. Develop an "as-is" business model that describes how partner types (supply chain business entities)
do business today.
2. Re-engineer this model to specify how partner types will use Web-based interactions to do business.
3. Create a PIP Blueprint document from the re-engineered process that describes how the partner roles
(roles that business partners play in the supply chain) will achieve a business objective. The RosettaNet
members vote to approve this blueprint.
4. Create a PIP protocol that dictates to system architects and software engineers how networked
applications will interoperate.