UNIT-1

Distributing Computing:
Distributing Computing is a type of computing in which different
components and objects comprising an application can be located on
different computers connected to a network. Figure 1.1 shows a distributed
computing model that provides an infrastructure enabling invocations of
object functions located anywhere on the network. The objects are
transparent to the application and provide processing power as if they were
local to the application calling them.

Object

TCP/IP
User

TCP/IP
Applicati Internet Object
on

TCP/IP

Object

Figure 1.1 Internet-based distributed computing model.

 The Importance of Distributed Computing

The distributed computing environment provides many

significant advan- tages compared to a traditional standalone application.
The following are some of those key advantages:

Higher performance. Applications can execute in parallel and distribute

the load across multiple servers.

Collaboration. Multiple applications can be connected through stan-

dard distributed computing mechanisms.

Higher reliability and availability. Applications or servers can be

clustered in multiple machines.

Scalability. This can be achieved by deploying these reusable distrib-

uted components on powerful servers.

Extensibility. This can be achieved through dynamic (re)configura-

tion of applications that are distributed across the network.

Higher productivity and lower development cycle time. By

breaking up large problems into smaller ones, these individual
components can be developed by smaller development teams in
isolation.

Reuse. The distributed components may perform various services that

can potentially be used by multiple client applications. It saves
repetitive development effort and improves interoperability between
components.

Reduced cost. Because this model provides a lot of reuse of once

developed components that are accessible over the network, signifi-
cant cost reductions can be achieved.

The core distributed computing technologies such as Client/Server

applications, OMG CORBA, Java RMI, Microsoft COM/DCOM, and
MOM.

Core distributed computing technologies:

Client-Server Applications

The early years of distributed application architecture were dominated by

two-tier business applications. In a two-tier architecture model, the first
(upper) tier handles the presentation and business logic of the user applica-
tion (client), and the second/lower tier handles the application organization
and its data storage (server). This approach is commonly called client-server
applications architecture. Generally, the server in a client/server application
model is a database server that is mainly responsible for the organization
and retrieval of data. The application client in this model handles most of
the business processing and provides the graphical user interface of the
application. It is a very popular design in business applications where the
user interface and business logic are tightly coupled with a database server
for handling data retrieval and processing. For example, the client-server
model has been widely used in enterprise resource planning (ERP), billing,
and Inventory application systems where a number of client business
applica- tions residing in multiple desktop systems interact with a central
database server.
Figure 1.2 shows an architectural model of a typical client server system
in which multiple desktop-based business client applications access a cen-
tral database server.
 Some of the common limitations of the client-server application model
are as follows:

■■ Complex business processing at the client side demands robust

client systems.

■■ Security is more difficult to implement because the algorithms and

logic reside on the client side making it more vulnerable to hacking.

■■ Increased network bandwidth is needed to accommodate many calls

to the server, which can impose scalability restrictions.

■■ Maintenance and upgrades of client applications are extremely diffi-

cult because each client has to be maintained separately.

■■ Client-server architecture suits mostly database-oriented standalone

applications and does not target robust reusable component- oriented
applications.
CORBA
The Common Object Request Broker Architecture (CORBA) is an
industry wide, open standard initiative, developed by the Object
Management Group (OMG) for enabling distributed computing that
supports a wide range of application environments. OMG is a nonprofit
consortium responsible for the production and maintenance of framework
specifications for distributed and interoperable object-oriented systems.
In a CORBA-based solution, the Object Request Broker (ORB) is
an object bus that provides a transparent mechanism for sending requests
and receiving responses to and from objects, regardless of the environment
and its location. The ORB intercepts the client’s call and is responsible for
find- ing its server object that implements the request, passes its
parameters, invokes its method, and returns its results to the client. The
ORB, as part of its implementation, provides interfaces to the CORBA
services, which allows it to build custom-distributed application
environments.
Figure 1.3 illustrates the architectural model of CORBA with an
example representation of applications written in C, C++, and Java
providing IDL bindings.
The CORBA architecture is composed of the following components:

IDL. CORBA uses IDL contracts to specify the application

boundaries and to establish interfaces with its clients. The IDL
provides a mecha- nism by which the distributed application
component’s interfaces, inherited classes, events, attributes, and
exceptions can be specified in a standard definition language
supported by the CORBA ORB.
 C C++ Java C C++ Java

IDL IDL IDL

Client Stubs Server Skeletons

CORBA - ORB (Object Bus)

Figure 1.3 An example of the CORBA architectural model.

ORB. It acts as the object bus or the bridge, providing the

communication infrastructure to send and receive request/responses
from the client and server. It establishes the foundation for the
distributed application objects, achieving interoperability in a
heterogeneous environment.

Some of the distinct advantages of CORBA over a traditional

client/server application model are as follows:

OS and programming-language independence. Interfaces between

clients and servers are defined in OMG IDL, thus providing the fol-
lowing advantages to Internet programming: Multi-language and
multi-platform application environments, which provide a logical
separation between interfaces and implementation.

Legacy and custom application integration. Using CORBA

IDL, developers can encapsulate existing and custom
applications as callable client applications and use them as
objects on the ORB.

Rich distributed object infrastructure. CORBA offers developers

a rich set of distributed object services, such as the Lifecycle,
Events, Naming, Transactions, and Security services.
 Location transparency. CORBA provides location transparency: An
object reference is independent of the physical location and applica-
tion level location. This allows developers to create CORBA-based
systems where objects can be moved without modifying the underly-
ing applications.

Network transparency. By using the IIOP protocol, an ORB can inter-

connect with any ORB located elsewhere on the network.

Remote call back support. CORBA allows objects to receive

asynchronous event notification from other objects.

Dynamic invocation interface. CORBA clients can both use static and
dynamic methods invocations. They either statically define their
method invocations through stubs at compile time, or have the
opportunity to discover objects’ methods at runtime.

Limitations:

some key factors, which affected the success of CORBA evident while
implementing CORBA-based distributed applications, are as follows:

High initial investment. CORBA-based applications require huge

investments in regard to new training and the deployment of
architecture, even for small-scale applications.

Availability of CORBA services. The Object services specified

by the OMG are still lacking as implementation products.

Scalability. Due to the tightly coupled nature of the connection-

oriented CORBA architecture, very high scalability expected in
enterprise applications may not be achieved.
Java RMI
Java RMI was developed by Sun Microsystems as the standard
mechanism to enable distributed Java objects-based application
development using the Java environment. RMI provides a distributed Java
application environment by calling remote Java objects and passing them
as arguments or return values.

Java RMI uses Java Remote Method Protocol (JRMP) as the inter-
process communication protocol, enabling Java objects living in different
Java Virtual Machines (VMs) to transparently invoke one another’s
methods. Because these VMs can be running on different computers
anywhere on the network, RMI enables object-oriented distributed
computing. RMI also uses a reference-counting garbage collection
mechanism that keeps track of external live object references to remote
objects (live connections) using the virtual machine.
Figure 1.4 depicts the architectural model of a Java RMI-based applica-
tion solution.

Java R RMI Java

Client MI RMI
Skeleton
Stu Serve
bs r

Remote Ref. Layer Remote Ref. Layer

JRMP

Figure 1.4 A Java RMI architectural model.

The Java RMI architecture is composed of the following components:

RMI client. The RMI client, which can be a Java applet or a stand-
alone application, performs the remote method invocations on a
server object. It can pass arguments that are primitive data types or
serializable objects.

RMI stub. The RMI stub is the client proxy generated by the rmi
compiler (rmic provided along with Java developer kit—JDK) that
encapsulates the network information of the server and performs
the delegation of the method invocation to the server. The stub also
marshals the method arguments and un marshals the return values
from the method execution.

RMI infrastructure. The RMI infrastructure consists of two layers: the

remote reference layer and the transport layer. The remote reference
layer separates out the specific remote reference behavior from the
client stub. It handles certain reference semantics like connection
retries, which are unicast/multicast of the invocation requests. The
transport layer actually provides the networking infrastructure, which
facilitates the actual data transfer during method invocations, the
passing of formal arguments, and the return of back execution results.

RMI skeleton. The RMI skeleton, which also is generated using the RMI
compiler (rmic) receives the invocation requests from the stub and
processes the arguments (unmarshalling) and delegates them to the RMI
server. Upon successful method execution, it marshals the return values
and then passes them back to the RMI stub via the RMI infrastructure.
RMI server. The server is the Java remote object that implements the
exposed interfaces and executes the client requests. It receives incom-
ing remote method invocations from the respective skeleton, which
passes the parameters after unmarshalling. Upon successful method
execution, return values are sent back to the skeleton, which passes
them back to the client via the RMI infrastructure.

it also had some

limitations:

■■ RMI is limited only to the Java platform. It does not provide lan-
guage independence in its distributed model as targeted by CORBA.

■■ RMI-based application architectures are tightly coupled because of

the connection-oriented nature. Hence, achieving high scalability in
such an application model becomes a challenge.

■■ RMI does not provide any specific session management support. In

a typical client/server implementation, the server has to maintain the
session and state information of the multiple clients who access it.
Maintaining such information within the server application with-
out a standard support is a complex task.

Microsoft DCOM

The Microsoft Component Object Model (COM) provides a way for

Windows-based software components to communicate with each other by
defining a binary and network standard in a Windows operating
environment.
DCOM enables COM applications to communicate with each other
using an RPC mechanism, which employs a DCOM protocol on the wire.
 DCOM applies a skeleton and stub approach whereby a defined inter-
face that exposes the methods of a COM object can be invoked remotely
over a network. The client application will invoke methods on such a
remote COM object in the same fashion that it would with a local COM
object. The stub encapsulates the network location information of the
COM server object and acts as a proxy on the client side. The servers can
poten- tially host multiple COM objects, and when they register
themselves against a registry, they become available for all the clients,
who then dis- cover them using a lookup mechanism.

DCOM is quite successful in providing distributed computing support

on the Windows platform. But, it is limited to Microsoft application envi-
ronments.
The following are some of the common limitations of DCOM:
■■ Platform lock-in
■■ State management
■■ Scalability

■■ Complex session management issues

Message-Oriented Middleware

Message-Oriented Middleware (MOM) is based upon a loosely coupled

asynchronous communication model where the application client does not
need to know its application recipients or its method arguments. MOM
enables applications to communicate indirectly using a messaging
provider queue. The application client sends messages to the message
queue (a message holding area), and the receiving application picks up the
message from the queue. In this operation model, the application sending
messages to another application continues to operate without waiting for
the response from that application.

Figure 1.6 illustrates a high-level MOM architecture showing

application-to-application connectivity.

MOM
Application A Infrastructure Application B
Adapter API Adapter API

Persistence

Figure 1.6 A typical MOM-based architectural model.

In MOM-based architecture, applications interacting with its

messaging infrastructure use custom adapters. Client applications
communicate with the underlying messaging infrastructure using these
 adapters for sending and receiving messages. For reliable message
delivery, messages can be persisted in a database/file system as well.
Some of the widely known MOM-based technologies are SunONE Mes-
sage Queue, IBM MQSeries, TIBCO, SonicMQ, and Microsoft Messaging
Queue (MSMQ).
JMS provides Point-to-Point and Publish/Subscribe messaging models
with the following features:

■■ Complete transactional capabilities

■■ Reliable message delivery

■■ Security

Some of the common challenges while implementing a MOM-based

application environment have been the following:

■■ Most of the standard MOM implementations have provided native

APIs for communication with their core infrastructure. This has
affected the portability of applications across such implementations
and has led to a specific vendor lock-in.

■■ The MOM messages used for integrating applications are usually

based upon a proprietary message format without any standard
compliance.

The Role of J2EE and

XML in Distributed
Computing

J2EE provides a programming model based upon Web and business

components that are managed by the J2EE application server. The
application server consists of many APIs and low-level services available
to the components. These low-level services provide security, transactions,
 connections and instance pooling, and concurrency services, which
enable a J2EE developer to focus primarily on business logic rather than
plumbing. J2EE also provides excellent client connectivity capabilities,
ranging from PDA to Web browsers to Rich Clients (Applets, CORBA
applications, and Standard Java Applications).
Figure 1.7 shows various components of the J2EE architecture.

A typical J2EE architecture is physically divided in to three logical

tiers, which enables clear separation of the various application components
with defined roles and responsibilities.
The following is a breakdown of functionalities of those logical tiers:

Presentation tier. The Presentation tier is composed of Web

components, which handle HTTP requests/responses, Session
management, Device independent content delivery, and the invocation
of business tier components.
 Application tier. The Application tier (also known as the Business
tier) deals with the core business logic processing, which may typi-
cally deal with workflow and automation. The business components
retrieve data from the information systems with well-defined APIs
provided by the application server.

Integration tier. The Integration tier deals with connecting and com-
municating to back-end Enterprise Information Systems (EIS), data-
base applications and legacy applications, or mainframe applications.

With its key functionalities and provisions for partitioning applications

into logical tiers, J2EE has been highly adopted as the standard solution
for developing and deploying mission critical Web-based applications. The
power of J2EE-based applications would be tremendous, if it is enabled to
interoperate with other potential J2EE-deployed applications. This enables
business components across networks to negotiate among them and
interact without human interaction. It also enables the realization of
syndication and collaboration of business processes across the Internet by
enabling them to share data and component-level processes in real time.
This phenomenon is commonly referred to as business-to-business (B2B)
communication.

Common Challenges in Distributed Computing

The common challenges noticed in the CORBA-, RMI-, and DCOM-
based distributed computing solutions:

■■ Maintenance of various versions of stubs/skeletons in the client

and server environments is extremely complex in a heterogeneous
net- work environment.

■■ Quality of Service (QoS) goals like Scalability, Performance, and

 Availability in a distributed environment consume a major portion
of the application’s development time.

■■ Interoperability of applications implementing different protocols on

heterogeneous platforms almost becomes impossible. For example, a
DCOM client communicates to an RMI server or an RMI client
communicating to a DCOM server.

■■ Most of these protocols are designed to work well within local net-
works. They are not very firewall friendly or able to be accessed
over the Internet.

Service-Oriented Architecture:
Service-Oriented Architecture (SOA) is an architectural approach in which
applications make use of services available in the network. In this architecture, services are provided
to form applications, through a communication call over the internet.

 SOA allows users to combine a large number of facilities from existing services to form
applications.
 SOA encompasses a set of design principles that structure system development and provide
means for integrating components into a coherent and decentralized system.
 SOA based computing packages functionalities into a set of interoperable services, which can
be integrated into different software systems belonging to separate business domains.
There are two major roles within Service-oriented Architecture:
Service provider: The service provider is the maintainer of the service and the organization that
makes available one or more services for others to use. To advertise services, the provider can publish
them in a registry, together with a service contract that specifies the nature of the service, how to use
it, the requirements for the service, and the fees charged.
Service consumer: The service consumer can locate the service metadata in the registry and develop
the required client components to bind and use the service.
Services might aggregate information and data retrieved from other services or create workflows of
services to satisfy the request of a given service consumer. This practice is known as service
orchestration Another important interaction pattern is service choreography, which is the coordinated
interaction of services without a single point of control.

Components of SOA:
Guiding Principles of SOA:

Standardized service contract: Specified through one or more service description documents.
Loose coupling: Services are designed as self-contained components, maintain relationships that
minimize dependencies on other services.
Abstraction: A service is completely defined by service contracts and description documents. They
hide their logic, which is encapsulated within their implementation.
Reusability: Designed as components, services can be reused more effectively, thus reducing
development time and the associated costs.
Autonomy: Services have control over the logic they encapsulate and, from a service consumer point
of view, there is no need to know about their implementation.
Discoverability: Services are defined by description documents that constitute supplemental
metadata through which they can be effectively discovered. Service discovery provides an effective
means for utilizing third-party resources.
Composability: Using services as building blocks, sophisticated and complex operations can be
implemented. Service orchestration and choreography provide a solid support for composing services
and achieving business goals.
Advantages of SOA:

Service reusability: In SOA, applications are made from existing services.Thus, services can be
reused to make many applications.
Easy maintenance: As services are independent of each other they can be updated and modified
easily without affecting other services.
Platform independant: SOA allows making a complex application by combining services picked
from different sources, independent of the platform.
Availability: SOA facilities are easily available to anyone on request.
Reliability: SOA applications are more reliable because it is easy to debug small services rather than
huge codes
Scalability: Services can run on different servers within an environment, this increases scalability
 Disadvantages of SOA:

High overhead: A validation of input parameters of services is done whenever services interact this
decreases performance as it increases load and response time.
High investment: A huge initial investment is required for SOA.
Complex service management: When services interact they exchange messages to tasks. the number
of messages may go in millions. It becomes a cumbersome task to handle a large number of
messages.
Practical applications of SOA: SOA is used in many ways around us whether it is mentioned or not.

SOA infrastructure is used by many armies and air force to deploy situational awareness systems.
SOA is used to improve the healthcare delivery.
Nowadays many apps are games and they use inbuilt functions to run. For example, an app might
need GPS so it uses inbuilt GPS functions of the device. This is SOA in mobile solutions.
SOA helps maintain museums a virtualized storage pool for their information and content.

Web Services:
Web services are self-describing and modular business applications that
expose the business logic as services over the Internet through
programmable interfaces and using Internet protocols for the purpose of
providing ways to find, subscribe, and invoke those services.
 Airline Reservation System
Wireless Device

Find Services Register Services

Travel Services Registry Rental Car Reservation System

Desktop

Invoke Services
Hotel Reservation System
PDA Service Requestor
Travel Reservation Services Provider

Automobile Map and Weather Information System

Organizat
ion Credit Card
Payment
System
Figure 2.1 An example scenario of
Web services.
 The following is a typical scenario:

1. The Travel service provider deploys its Web services by exposing the
business applications obtained from different travel businesses like
airlines, car-rental, hotel accommodation, credit card payment, and
so forth.

2. The service provider registers its business services with descriptions

using a public or private registry. The registry stores the information
about the services exposed by the service provider.

3. The customer discovers the Web services using a search engine or by

locating it directly from the registry and then invokes the Web ser-
vices for performing travel reservations and other functions over the
Internet using any platform or device.

4. In the case of large-scale organizations, the business applications

consume these Web services for providing travel services to their
own employees through the corporate intranet.

5. Web services enable businesses to communicate, collaborate, and

con- duct business transactions using a lightweight infrastructure by
adopting an XML-based data exchange format and industry standard
delivery protocols.

The basic characteristics of a Web services application model are

as follows:

■■ Web services are based on XML messaging, which means that the
data exchanged between the Web service provider and the user are
defined in XML.

■■ Web services provide a cross-platform integration of business

applications over the Internet.
■■ To build Web services, developers can use any common
programming language, such as Java, C, C++, Perl, Python, C#,
and/or Visual Basic, and its existing application components.

■■ Web services are not meant for handling presentations like

HTML context—it is developed to generate XML for uniform
accessibility through any software application, any platform, or
device.

■■ Because Web services are based on loosely coupled

application components, each component is exposed as a service
with its unique functionality.

■■ Web services use industry-standard protocols like HTTP, and

they can be easily accessible through corporate firewalls.
■■ Web services can be used by many types of clients.

■■ Web services vary in functionality from a simple request to a

complex business transaction involving multiple resources.

■■ All platforms including J2EE, CORBA, and Microsoft .NET

provide extensive support for creating and deploying Web
services.

■■ Web services are dynamically located and invoked from

public and private registries based on industry standards such as
UDDI and ebXML.
Why Use Web Services:

Web applications enable interaction between an end user and a Web site,
while Web services are service-oriented and enable application- to-
application communication over the Internet and easy accessibility to
heterogeneous applications and devices. The following are the major
technical reasons for choosing Web services over Web applications:

■■ Web services can be invoked through XML-based RPC

mechanisms across firewalls.

■■ Web services provide a cross-platform, cross-language solution

based on XML messaging.

■■ Web services facilitate ease of application integration using a

light- weight infrastructure without affecting scalability.

■■ Web services enable interoperability among heterogeneous

applications.

Basic Operational Model of Web Services

Web services operations can be conceptualized as a simple operational
model that has a lot in common with a standard communication model
(see Figure 2.3). Operations are conceived as involving three distinct roles
and relationships that define the Web services providers and users.
 Service Broker

Service Requestor Service Provider

Invoke Service

Figure 2.3 Web services operational model, showing roles and relationships.

These roles and relationships are defined as follows:

Service provider. The service provider is responsible for developing

and deploying the Web services. The provider also defines the ser-
vices and publishes them with the service broker.

Service broker. The service broker (also commonly referred to as a

service registry) is responsible for service registration and discovery
of the Web services. The broker lists the various service types,
descriptions, and locations of the services that help the service
requesters find and subscribe to the required services.

Service requestor. The service requestor is responsible for the service

invocation. The requestor locates the Web service using the service
broker, invokes the required services, and executes it from the service
provider.
 Core Web Services Standards/Tools and technologies enabling
web services
The five core Web services standards and technologies for building
and enabling Web services are XML, SOAP, WSDL, UDDI, and ebXML.

Extensible Markup Language (XML)

In February 1998, the Worldwide Web Consortium (W3C)
officially endorsed the Extensible Markup Language (XML) as a standard
data for- mat. XML uses Unicode, and it is structured self-describing
neutral data that can be stored as a simple text document for representing
complex data and to make it readable. Today, XML is the de facto standard
for structuring data, content, and data format for electronic documents. It
has already been widely accepted as the universal language lingua franca
for exchanging information between applications, systems, and devices
across the Internet. In the core of the Web services model, XML plays a
vital role as the com- mon wire format in all forms of communication.
XML also is the basis for other Web services standards. By learning XML,
you will be well prepared to understand and explore Web services.

Simple Object Access Protocol (SOAP)

Simple Object Access Protocol, or SOAP, is a standard for a

lightweight XML-based messaging protocol. It enables an exchange of
information between two or more peers and enables them to communicate
with each other in a decentralized, distributed application environment.
SOAP also is independent of the application object model, language, and
running platforms or devices.
In the core of the Web services model, SOAP is used as the messaging
protocol for transport with binding on top of various Internet protocols
such as HTTP, SMTP, FTP, and so on. SOAP uses XML as the message
for- mat, and it uses a set of encoding rules for representing data as
messages. Although SOAP is used as a messaging protocol in Web
services, it also can operate on a request/response model by exposing the
functionality using SOAP/RPC based on remote procedural calls. SOAP
also can be used with J2EE-based application frameworks.

Web Services Definition Language (WSDL)

The Web Services Definition Language (WSDL) standard is an XML

format for describing the network services and its access information. It
defines a binding mechanism used to attach a protocol, data format, an
abstract message, or set of endpoints defining the location of services.
In the core of the Web services model, WSDL is used as the metadata
language for defining Web services and describes how service providers
and requesters communicate with one another. WSDL describes the Web
services functionalities offered by the service provider, where the service
is located, and how to access the service. Usually the service provider
creates Web services by generating WSDL from its exposed business
applications. A public/private registry is utilized for storing and publishing
the WSDL- based information.

Universal Description, Discovery, and Integration (UDDI)

Universal Description, Discovery, and Integration, or UDDI, defines
the standard interfaces and mechanisms for registries intended for
publishing and storing descriptions of network services in terms of XML
messages.
 It is similar to the yellow pages or a telephone directory where
businesses list their products and services. Web services brokers use UDDI
as a stan- dard for registering the Web service providers. By
communicating with the UDDI registries, the service requestors locate
services and then invoke them.
In the core Web services model, UDDI provides the registry for
Web services to function as a service broker enabling the service
providers to populate the registry with service descriptions and service
types and the service requestors to query the registry to find and locate the
services. It enables Web applications to interact with a UDDI-based
registry using SOAP messages. These registries can be either private
services within an enterprise or a specific community, or they can be
public registries to ser- vice the whole global business community of the
Internet. The UDDI working group includes leading technology vendors
like Sun Microsys- tems, IBM, HP, SAP, Oracle, and Microsoft.

ebXML

ebXML defines a global electronic marketplace where

enterprises find one another and conduct business process collaborations
and transactions. It also defines a set of specifications for enterprises to
conduct electronic business over the Internet by establishing a common
standard for business process specifications, business information
modelling, business process collaborations, collaborative partnership
profiles, and agreements and messaging. Popular standards organizations
like Open Travel Alliance (OTA), Open Application Group, Inc. (OAGI),
Global Commerce Initiative (GCI), Health Level 7 (HL7, a healthcare
standards organization), and RosettaNet (an XML standards committee)
also have endorsed it.
 In particular:

■■ ebXML Business Process Service Specifications (BPSS) enable

busi- ness processes to be defined.

■■ ebXML CPP/CPA enables business partner profiles and agreements

to be defined, and it provides business transaction choreography.

■■ ebXML Messaging Service Handler (MSH) deals with the

transport, routing, and packaging of messages, and it also provides
reliability and security, a value addition over SOAP.

■■ ebXML registry defines the registry services, interaction

protocols, and message definitions, and ebXML repository acts as
storage for shared information. The ebXML registries register with
other reg- istries as a federation, which can be discovered through
UDDI. This enables UDDI to search for a business listing point to
an ebXML Registry/Repository.

■■ ebXML Core components provide a catalogue of business process

components that provide common functionality to the business com-
munity. Examples of such components are Procurement, Payment,
Inventory, and so on.
Known Challenges in Web Services
Some of the key challenges are as follows:

Distributed transactions. If the environment requires distributed

transactions with heterogeneous resources, it should be studied and
tested with standard solutions based on BTP, WS-Transactions, and
WS-Coordination.

Quality of Service (QoS). In case of a mission-critical solution, the

service providers must examine the reliability and performance of the
service in peak load and uncertain conditions for high availabil- ity.
The exposed infrastructure must provide load balancing, and fail-
over and fault tolerance, to resolve these scenarios.

Security. Web services are exposed to the public using http-based pro-
tocols. As Web services is publicly available, it must be implemented
using authentication and authorization mechanisms and using SSL-
enabling encryption of the messages for securing the usage. Adopt-
ing open security standards like SAML, XML Encryption, XML
Signature, or XACML may be a solution.

Other challenges include the manageability and testing of the Web

services deployment, which is subjected to different operating system
environments and platforms and managing service descriptions in
public/private registries.
Key Benefits of Web Services
The key benefits of implementing Web services are as follows:

■■ Provides a simple mechanism for applications to become services

that are accessible by anyone, anywhere, and from any device.

■■ Defines service-based application connectivity facilitating EAI,

and intra-enterprise and inter-enterprise communication.

■■ Defines a solution for businesses, which require flexibility and

agility in application-to-application communication over the Internet.

■■ Enables dynamic location and invocation of services through service

brokers (registries).

■■ Enables collaboration with existing applications that are modeled as

services to provide aggregated Web services.