LECTURE NOTES

ON
WEB SERVICES(2005PE11)
IV B.Tech II Semester
PREPARED BY

Dr. SUMAIYA SAMREEN

Associate Professor

Mrs.BABY RANI Mrs.HARITHA LAKSHMI

Asst. Professor Asst. Professor

DEPARTMENT OF INFORMATION TECHNOLOGY

MALLAREDDYENGINEERINGCOLLEGEFORWOMEN
(AutonomousInstitution-UGC,Govt.ofIndia)
Accredited by NBA & NAAC with ‘A’ Grade, UGC, Govt. of IndiaNIRF
Indian Ranking–2018, Accepted by MHRD, Govt. of India
Permanently Affiliated to JNTUH, Approved by AICTE, ISO 9001:2015 Certified Institution AAAA+
Rated by Digital Learning Magazine, AAA+ Rated by Careers 360 Magazine, 6th RankCSR Platinum
Rated by AICTE-CII Survey, Top 100 Rank band by ARIIA, MHRD, Govt. of IndiaNational Ranking-Top
100 Rank band by Outlook, National Ranking-Top 100 Rank band by Times News Magazine Maisammaguda,
Dhulapally, Secunderabad, Kompally-500100
2023– 2024
SYLLABUS

UNIT I: Evolution and Emergence of Web Services: Evolution of distributed computing, Core
distributed computing technologies, client/server, CORBA, JAVA RMI, Micro Soft DCOM, MOM,
Challenges in Distributed Computing, role of J2EE and XML in distributed computing, emergence ofWeb
Services and Service Oriented Architecture (SOA).
Introduction to Web Services: The definition of web services, basic operational model of web
services, tools and technologies enabling web services, benefits and challenges of using web services.
Web Services Architecture: Web services Architecture and its characteristics, core building blocks of
web services, standards and technologies available for implementing web services, web services
communication, basic steps of implementing web services.
UNIT II:
Fundamentals of SOAP: SOAP Message Structure, SOAP Encoding, Encoding of different data
types, SOAP message exchange models, SOAP communication and messaging, Java and Axis,
Limitations SOAP.
UNIT III:
Describing Web Services:WSDL, WSDL in the world of Web Services, Web Services life cycle,
anatomy of WSDL definition document, WSDL bindings, WSDL Tools, limitations of WSDL.
UNIT IV:
Discovering Web Services: Service discovery, role of service discovery in a SOA, service discovery
mechanisms, UDDI: UDDI Registries, uses of UDDI Registry, Programming with UDDI, UDDI data
structures, Publishing API, Publishing , searching information in a UDDI Registry, limitations of
UDDI.
UNIT V:
Web Services Interoperability:Means of ensuring Interoperability,Overview of.NET,Creating a
.NET Client for an Axis Web Services, Creating Java Client for a web service, Challenges in Web
Services Interoperability.
Services Security:XML security framework,Goals of cryptography,Digital Signature,Digital
Certificate, XML encryption.
TEXTBOOKS:

1. Developing Java Web Services,R.Nagappan,R.Skoczylas,R.P.Sriganesh,WileyIndia

REFERENCES:
1. Java Web Service Architecture, James McGovern, Sameer Tyagi etal., Elsevier
2. Building Web Services with Java, 2 Edition, S. Graham and others, Pearson Edn.
3. Java Web Services, D.A. Chappell & T. Jewell, O'Reilly,SPD.
4. Web Services, G. Alonso, F. Casati and others, Springer. Outcomes
5. Basic details of WSDL, UDDI. SOAP
6. Implement WS client and server with interoperable systems.
VISION AND MISSION OF THE INSTITUTION

VISION
 Visualizing a great future for the intelligentsia by imparting state-of the art
Technologies in the field of Engineering and Technology for the bright future and
prosperity of the students.
 To offer world class training to the promising Engineers.

.
MISSION
 To nurture high level of Decency, Dignity and Discipline in women to attain high intellectual
abilities.
 To produce employable students at National and International levels by effective training
programmes.
 To create pleasant academic environment for generating high level learning attitudes.
DEPARTMENT OF INFORMATION TECHNOLOGY
VISION
 To emerge as a center of excellence in the department of IT is to empower students with new
wave technologies to produce technically proficient and accomplished intellectual IT
professionals specifically to meet the modern challenges of the contemporary computing
industry and society
 Providing the students with most conducive academic environment and making them towards
serving the society with advanced technologies

MISSION
 M1: The mission of the department of Information Technology is to afford excellence
education for students, in the conventional and modern areas of information technology and
build up students with high-quality principled trainings, thus manifesting their global
personality development.
 M2: To impart holistic technical education using the best of infrastructure, outstanding
technical and teaching expertise
 M3: Training the students into competent and confident world class professionals with
excellent technical and communication skills.
 M4: To provide quality education through innovative teaching and learning process that yields
advancements in state-of-the-art information technology.
 M5:To inculcate the spirit of ethical values contributing to the welfare of the society by
offering courses in the curriculum design.

Program Educational Objectives (PEOs):

A graduate of the information technology Program should:
PEO 1: Apply current industry computing practices and emerging technologies to analyze, design,
implement, test, and verify IT based solutions to real world problems.
PEO 2: To promote employable graduates to be placed in various engineering positions in the
computational world in firms of international reputation.
PEO 3: To pursuit of advanced degrees in engineering at different levels of research and consultancy.
They get exposed to several other domains resulting in lifelong learning to broaden their professional
knowledge.
PEO 4: Theoretical and practical concepts of various domains to realize new ideas and
innovations for pursuing research, entrepreneurship, employment, and higher studies.
Program Specific Outcomes(PSOs):
PSO 1: An ability to analyze a problem, design algorithm, identify and define the computing requirements
within realistic constraints in multidisciplinary areas by understanding the core principles and concepts of
Information Technology.
PSO 2: Knowledge of data management system like data acquisition, big data so as to enable students in
solving problems using the techniques of data analytics like pattern recognition and knowledge discovery.
PSO 3: Effectively integrate IT based solutions into the user environment.

Program Outcomes (POs):

PO1 Engineering An ability to apply knowledge of Mathematics (including

knowledge Probability & Statistics and Mathematical Foundation of Computer
Science), Science, and Engineering.
PO2 Problem analysis An ability to design and conduct experiments, as well as to analyze
and interpret data including hardware and software components
PO3 Design / An ability to design a complex computing system or process to meet
development of desired specifications and needs.
solutions
PO4 Conduct Create, select, and apply appropriate techniques, resources, and
investigations of modern engineering and IT tools including prediction and modeling
complex problems to complex engineering activities with an understanding of the
limitations.
PO5 Modern tool usage An ability to use the techniques, skills, and modern engineering tools
necessary for engineering practice
PO6 The engineer and An ability to understanding of professional, health, safety, legal,
society cultural and social responsibilities.
PO7 Environment and The broad education necessary to understand the impact of
sustainability engineering solutions in a global, economic, environmental and
demonstrate the knowledge need for sustainable development.
PO8 Ethics Apply ethical principles, responsibility and norms of the engineering
practice.
PO9 Individual and team An ability to function on multi-disciplinary teams.
work
PO10 Communication An ability to communicate and present effectively
PO11 Project An ability to use the modern engineering tools, techniques, skills and
management and management principles to do work as a member and leader in a
finance team, to manage projects in multi-disciplinary environments
PO12 Life-long learning A recognition of the need for, and an ability to engage in, to resolve
contemporary issues and acquire lifelong learning
Course Objectives:
At the end of the course, the students will be able to:
 To understand the details of web services technologies like WSDL,UDDI, SOAP
 To learn how to implement and deploy web service client and server
 To explore interoperability between different frameworks

Course Outcomes:

After completing this course, the student must demonstrate the knowledge and ability to:
 Employ the publish, find, bind architecture for Web services and to use the corresponding standards, in
particular. WSDL, SOAP. UDDI
 Perform matchmaking on Web services using SOAP.
 Develop registration and discovery techniques for Web services
- Implement WS client and server with interoperable system
Index:

UNIT-1...................................................................................................................................................................................................................................... 8
Evolution and Emergence of Web Services .......................................................................................................................................... 8
Evolution of Distributed Computing:- ................................................................................................................................. 8
Importance of Distributed Computing: ...............................................................................................................................9
Client-Server Applications..................................................................................................................................................... 10
CORBA.............................................................................................................................................................................................11
Java RMI......................................................................................................................................................................................... 13
Microsoft DCOM..........................................................................................................................................................................15
Message-Oriented Middleware............................................................................................................................................16
The Emergence of Web Services And Service Oriented Architecture(SOA):...................................................18
Introduction to Web Services:................................................................................................................................................................. 21
Definition of Web Services:....................................................................................................................................................21
Motivation and Characteristics............................................................................................................................................23
Basic Operational Model of Web Services:..................................................................................................................... 25
Tools and Technologies enabling web services:.......................................................................................................... 26
Benefits and Challenges of using web services:........................................................................................................... 28
Key Benefits of Web Services : ............................................................................................................................................. 29
Web services Architecture........................................................................................................................................................................ 30
Web services Architecture and its Core building blocks:.........................................................................................30
Web Services Communication Models:............................................................................................................................ 32
Basic steps of implementing web services:.................................................................................................................... 34
UNIT-2....................................................................................................................................................................................................................................36
Fundamentals of SOAP................................................................................................................................................................................36
SOAP message structure:........................................................................................................................................................36
SOAP ENVELOPE............................................................................................................................................................................................37
SOAP Envelope............................................................................................................................................................................38
SOAP Header................................................................................................................................................................................ 38
SOAP Body.....................................................................................................................................................................................39
SOAP Attachments .....................................................................................................................................................................42
SOAP Encoding ............................................................................................................................................................................................... 43
Multiple References in Arrays ..............................................................................................................................................47
Partially Transmitted Arrays................................................................................................................................................47
Sparse Arrays...............................................................................................................................................................................48
Serialization and Deserialization........................................................................................................................................ 48
SOAP Message Exchange Model.............................................................................................................................................................. 48
SOAP Intermediaries....................................................................................................................................................................................49
SOAP Actor....................................................................................................................................................................................50
SOAP Communication And Messaging ................................................................................................................................................. 50
SOAP RPC .......................................................................................................................................................................................51
SOAP Messaging......................................................................................................................................................................... 52
Java and Axis....................................................................................................................................................................................................52
Installing Axis for Web Services ..............................................................................................................................................................53
Axis Web Services Programming Model..........................................................................................................................55
Creating the Service.................................................................................................................................................................. 55
Creating the Service Requestor........................................................................................................................................... 56
Creating a Normal Service Requestor Client..................................................................................................................56
Creating the Service Requestor Client from WSDL..................................................................................................... 57
Limitations of SOAP......................................................................................................................................................................................59
UNIT-3....................................................................................................................................................................................................................................60
DESCRIBING WEB SERVICES................................................................................................................................................................... 60
Web Services Description Language (WSDL)................................................................................................................60
WSDL in the World of Web Services..................................................................................................................................60
Web Service Life Cycle.............................................................................................................................................................61
Language and Platform Independency of WSDL..........................................................................................................62
Anatomy of a WSDL Definition Document......................................................................................................................................... 62
<definitions>Element...............................................................................................................................................................65
<message>Element................................................................................................................................................................... 66
<portType>Element..................................................................................................................................................................66
<binding>Element..................................................................................................................................................................... 67
<service>Element...................................................................................................................................................................... 67
WSDL Bindings ............................................................................................................................................................................................... 67
WSDL Binding Extensions......................................................................................................................................................67
WSDL Binding Support for Operations............................................................................................................................ 68
SOAP Binding ............................................................................................................................................................................... 68
WSDL Tools...................................................................................................................................................................................................... 71
Limitations of WSDL.................................................................................................................................................................................... 71
UNIT-4....................................................................................................................................................................................................................................72
Discovering Web Services..........................................................................................................................................................................72
Service Discovery.......................................................................................................................................................................72
Role of Service Discovery in SOA........................................................................................................................................ 72
Benefits of SOA Service Registry: ........................................................................................................................................73
SOA Service Discovery............................................................................................................................................................. 73
Benefits of SOA Service Discovery......................................................................................................................................74
Service Discovery Mechanisms............................................................................................................................................................... 74
Universal Description, Discovery and Integration (UDDI):.....................................................................................75
UDDI Registries ...........................................................................................................................................................................75
Public and Private UDDI Registries ....................................................................................................................................75
Uses of UDDI Registry.............................................................................................................................................................. 77
UDDI Specifications...................................................................................................................................................................77
UDDI Programming API.......................................................................................................................................................... 78
Publishing API............................................................................................................................................................................. 79
UDDI Data Structures ...............................................................................................................................................................80
Publishing API.................................................................................................................................................................................................83
Publishing Information to a UDDI Registry....................................................................................................................................... 85
Searching Information in a UDDI Registry ......................................................................................................................88
Programming Steps for Searching......................................................................................................................................88
Programming Steps for Deleting.........................................................................................................................................91
DeleteBusiness.java Source Code........................................................................................................................................92
Compiling and Executing SearchBusiness.java.............................................................................................................94
Limitations of UDDI...................................................................................................................................................................................... 94
UNIT-5....................................................................................................................................................................................................................................95
Web Services Interoperability................................................................................................................................................................. 95
Means of Ensuring Interoperability...................................................................................................................................95
Exposing WSDL...........................................................................................................................................................................95
Creating SOAP Proxies.............................................................................................................................................................96
Testing Interoperability..........................................................................................................................................................96
Overview of .NET ........................................................................................................................................................................96
.NET Framework Class Library............................................................................................................................................97
Creating a .NET Client for Axis Web Services ................................................................................................................ 98
Setting Up the Environment............................................................................................................................................... 100
Creating the Service Provider (Axis Environment)..................................................................................................101
Implementing the Service Provider (ACMEProductCatalog.jws)...................................................................... 102
Obtaining the WSDL of Acme Product Catalog Service...........................................................................................103
Generating a Proxy for the Web Service....................................................................................................................... 103
Compiling the SOAP Proxy as a DLL ................................................................................................................................104
Creating a .NET Client Application.................................................................................................................................. 105
Compiling the Client Application......................................................................................................................................105
Execute and Test the .NET Client from a Windows Environment..................................................................... 106
Challenges in Web Services Interoperability..................................................................................................................................106
Common SOAP/HTTP Transport Issues....................................................................................................................... 106
XML Schema- and XML-Related Issues ..........................................................................................................................107
Version and Compatibility...................................................................................................................................................107
Web Services Security...............................................................................................................................................................................107
XML Security FrameWork:..................................................................................................................................................107
Goals of Cryptography:......................................................................................................................................................... 108
Four Goals of Cryptography ................................................................................................................................................108
Digital Certificates ...................................................................................................................................................................................... 110
XML Encryption....................................................................................................................................................................... 111
What XML Encryption Is...................................................................................................................................................... 111
Implementations of XML Encryption............................................................................................................................. 113
XML Security Suite from IBM (www.alphaworks.ibm.com/tech/ xmlsecuritysuite)...............................113
XML Security Library, Aleksey Sanin (MIT License) (www.aleksey. com/xmlsec/).................................113
Trust Services Integration Kit (TSIK) from Verisign (www.
xmltrustcenter.org/developer/verisign/tsik/index.htm). ...................................................................................113
Phaos XML (www.phaos.com/e_security/prod_xml.html).................................................................................. 113

UNIT-1
Evolution and Emergence of Web Services

Evolution of Distributed Computing:-

In the early years of computing, mainframe-based
applications were considered to be the best-fit solution for executing large-scale data
processing applications. With the advent of personal computers(PCs), the concept of
software programs running on standalone machines became much more popular in terms
of the cost of ownership and the ease of application use. With the number of PC-based
application programs running on independent machines growing, the communications
between such application programs became extremely complex and added a growing
challenge in the aspect of application-to-application interaction. Lately, network
computing gained importance, and enabling remote procedure calls(RPCs) over a network
protocol called Transmission Control Protocol/Internet Protocol(TCP/IP) turned out to be
a widely accepted way for application software communication.
Since then, software application running on a variety of
hardware platforms, operating systems, and different networks faced some challenges
when required to communicate with each other and share data. This demanding
requirement leads to the concept of distributed computing applications. As a definition,
“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”.
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.

Importance of Distributed Computing:

The distributed computing environment provides many

Significant advantages 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 standard 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 distributed components on powerful
servers.

Extensibility:
This can be achieved through dynamic configuration 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 enveloped by
smaller development teams in isolation.

components. Reduced cost. Because this World model provide safe use once developed
components that are accessible over the network, significant cost educations can be
achieved.

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

Distributed computing also has changed the way traditional network programming is
done by providing a shareable object like semantics across networks using programming
languages like Java, C, and C++ . The following sections briefly discuss core distributed
computing technologies such as Client/Server applications, OMG CORBA, Java RMI,
Microsoft COM/DCOM, and MOM.
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 application (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 applications 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 central 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, whichcan impose

scalability restrictions.
■ Maintenance and upgrades of client applications are

extremely difficult because each client has to be

maintainedseparately.

■ 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.
CORBA differs from the traditional client/server model because it provides an object-
oriented solution that does not enforce any proprietary protocols or any particular
programming language, operating system, or hardware platform. By adopting CORBA, the
applications can reside and run on any hardware platform located anywhere on the
network, and can be written in any language that has mappings to a neutral interface
definition called the Interface Definition Language (IDL). An IDL is a specific interface
language designed to expose the services (methods/functions) of a CORBA remote object.
CORBA also defines a collection of system-level services for handling low-level application
services like life-cycle, persistence, transaction, naming, security, and so forth. Initially,
CORBA 1.1 was focused on creating component level, portable object applications without
interoperability. The introduction of CORBA 2.0 added interoperability between different
ORB vendors by implementing an Internet Inter-ORB Protocol (IIOP). The IIOP defines the
ORB backbone, through which other ORBs can bridge and provide interoperation with its
associated services. 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 finding 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.

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 mechanism by which the distributed
application component’s interfaces, inherited classes, events, attributes, and exceptions
canbe specified.

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 following 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
asobjects 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 application level location. This allows developers
to create CORBA-based systems where objects can be moved without modifying the
underlying applications.

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. It uses Java object serialization—a
lightweight object persistence technique that allows the conversion of objects into
streams. Before RMI, the only way to do inter-process communications in the Java
platform was to use the standard Java network libraries. Though the java.net APIs
provided sophisticated support for network functionalities, they were not intended to
support or solve the distributed computing challenges.

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 f external live object references to remote objects (live connections) using the
virtual machine. When an object is found unreferenced, it is considered to be a weak
reference and it will be garbage collected.

In RMI-based application architectures, a registry (rmiregistry) - oriented mechanism

provides a simple non-persistent naming lookup service that is

used to store the remote object references and

to enable lookups from client applications. The
RMI infrastructure based on the JRMP acts as
the medium between the RMI clients and
remote objects. It intercepts client requests,
passes invocation arguments, delegates
invocation requests to the RMI skeleton, and
finally passes the return values of the method
execution to the client stub. It also enables
callbacks from server objects to client
applications so that the asynchronous
notifications can be achieved.
Figure 1.4 depicts the architectural model of a Java RMI-based applicationsolution.
The java RMI architecture is composed of the following components:

RMI client. The RMI client, which can be a Java applet or a standalone application,
performs the remote method invocations on a server object. It can pass arguments that
are primitive data types orserializable 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 unmarshals 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 entries, which are unicast/multicast of the invocation requests. The
transport layer actually provides the networking infrastructure, which facilitates the
actual datatransfer 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 incoming 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.

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. COM evolved from OLE (Object Linking
and Embedding), which employed a Windows registry-based object organization
mechanism. COM provides a distributed application model for ActiveX components. As a
next step, Microsoft developed the Distributed Common Object
Model (DCOM) as its answer to the
distributed computing problem in the
Microsoft Windows platform. DCOM
enables COM applications to communicate
with each other using an RPC mechanism,
which employs a DCOM protocol on the
wire.

Figure 1.5 shows an architectural model of DCOM. DCOM applies a skeleton and stub
approach whereby a defined interface 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
proxyon the client side. The servers can potentially host multiple COM objects, and when
they register themselves against a registry, they become available for all the clients, who
then discover 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 environments. The following are some
ofthe common limitations of DCOM:
■ Platform lock-in
■ State management
■ Scalability
■ Complex session management issues

Message-Oriented Middleware

Although CORBA, RMI, and DCOM differ in their basic architecture and approach, they
adopted a tightly coupled mechanism of a synchronous communication model
(request/response). All these technologies are based upon binary communication
protocols and adopt tight integration across their logical tiers, which is susceptible to
scalability issues. 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
applicationsto 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.

MS 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-
basedapplication 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 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
logicrather than plumbing. The power of Java and
its rich collection of APIs provided the perfect
solution for developing highly transactional,
highly available and scalable enterprise
applications. Based on many standardized
industry specifications, it provides the interfaces
to connect
with various back-end legacy and information systems. 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 quests/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 typically 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 communicating to back-
end Enterprise Information Systems (EIS), database applications and legacy applications,
or mainframe applications.

The Emergence of Web Services And Service Oriented Architecture(SOA):

Today, the adoption of the Internet and enabling Internet-based applications has created
a world of discrete business applications, which co-exist in the same technology space but
without interacting with each other. The increasing demands of the industry for
enabling B2B, application-toapplication (A2A), and inter-process application
communication has led to a growing requirement for service-oriented architectures.

Enabling service- oriented applications facilitates the exposure of business applications as

service components enable business applications from other organizations to link with
these services for application interaction and data sharing without human intervention.
By leveraging this architecture, it also enables interoperability between business
applications and processes.

By adopting Web technologies, the service-oriented architecture model facilitates the

delivery of services over the Internet by leveraging standard technologies such as XML. It
uses platform-neutral standards by exposing the underlying application components and
making them available to any application, any platform, or any device, and at any location.
Today, this phenomenon is well adopted for implementation and is commonly referred to
as Web services.

Fig:Service Oriented Architecture(SOA)

A service-oriented architecture is essentially a collection of services. These services

communicate with each other. The communication can involve either simple data passing
or it could involve two or more services coordinating some activity. Some means of
connecting services to each other is needed.

Service-oriented architectures are not a new thing. The first service-oriented architecture
for many people in the past was with the use DCOM or Object Request Brokers (ORB s)
based on the CORBA specification. For more on DCOM and CORBA

Services

If a service-oriented architecture is to be effective, we need a clear understanding of the term

service. A service is a function that is well-defined, self-contained, and does not depend on the
context or state of other services.

Connections
The technology of Web Services is the most likely connection technology of service- oriented
architectures. The following figure illustrates a basic service-oriented architecture. It shows a
service consumer at the right sending a service request message to a service provider at the left.
The service provider returns a response message to the service consumer. The request and
subsequent response connections are defined in some way that is understandable to both the
service consumer and service provider. How those connections are defined is explained in Web
Services Explained. A service provider can also be a service consumer.

Metadata:-
Metadata can be defined as a set of assertions about things in our domain of discourse.
Metadata is a component of data, which describes the data. It is "data about data". Often there
is more than that, involving information about data as they is stored or managed, and revealing
partial semantics such as intended use (i.e., application) of data. This information can be of
broad variety, meeting if not surpassing the variety in the data themselves. They may describe,
or be a summary of the information content of the individual databases in an intentional
manner. Some metadata may also capture content independent information like location and
time of creation.

Metadata descriptions present two advantages:

• They enable the abstraction of representational details such as the format and
organization of data, and capture the information content of the underlying data independent of
representational details. This represents the first step in reduction of information overload, as
intentional metadata descriptions are in general an order of magnitude smaller than the
underlying data.They enable representation of domain knowledge describing the information
domain to which the underlying data belong. This knowledge may then be used to make
inferences about the underlying data. This helps in reducing information overload as the
inferences may be used to determine the relevance of the underlying data without accessing the
data.
Fig Types of Metadata in SOA

Metadata can be classified based on different criteria. Based on the level of abstraction in
which a metadata describes content, the metadata can be classified as follows :
• Syntactic Metadata focuses on details of the data source (document) providing little
insight into the data. This kind of metadata is useful mainly for categorizing or cataloguing the
data source. Examples if syntactic metadata include language of the data source, creation date,
title, size, format etc.

• Structural Metadata focuses on the structure of the document data, which facilitates data
storage, processing and presentation such as navigation, eases
• Semantic Metadata describes contextually relevant information focusing on domain-
specific elements based on ontology, which a user familiar with the domain is likely to know or
understand easily. Using semantic metadata, meaningful interpretation of data is possible and
interoperability will then be supported at high-level (hence easier to use), providing meaning to
the underlying syntax and structure.

Introduction to Web Services:

Definition of Web Services:

Web services are based on the concept of service- oriented architecture (SOA). SOA is the
latest evolution of distributed computing, which enables software components, including
application functions, objects, and processes from different systems, to be exposed as services.

According to Gartner research (June 15, 2001), “Web services are loosely coupled software
components delivered over Internet standard technologies.” In short, 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. Based on XML standards, Web
services can be developed as loosely coupled application components using any programming
language, any protocol, or any platform. This facilitates delivering business applications as a
service accessible to anyone, anytime, at any location, and using any platform.
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.

The previous example provides a simple scenario of how an organization’s business

functionalities can be exposed as Web services and invoked by its customers using a wide
range of application clients.
Motivation and Characteristics

Web-based B2B communication has been around f r

quite some time. These Web-based B2B solutions
are usually based on custom and proprietary
technologies and are meant for exchanging data and
doing transactions over the Web. However, B2B has
its own challenges. For example, in B2B
communication, connecting new or existing
applications and adding new business partners have
always been a challenge. Due to this fact, in some
cases the scalability of the underlying business
applications is affected. Ideally, the business
applications and information from a partner
organization should be able to interact with the
application of the potential partners seamlessly
without redefining the system or its resources. To meet these challenges, it is clearly
evident that there is a need for standard protocols and data formatting for enabling
seamless and scalable B2B applications and services. Web services provide the solution
to resolve these issues by adopting open standards. Figure 2.2 shows a typical B2B
infrastructure (e-marketplace) using XML for encoding data between applications across
the Internet.
Web services enable businesses to communicate, collaborate, conduct business
transactions using a lightweight infrastructure by adopting an XML-based data exchange
format and industry standard delivery protocols.

standards-based technologies. This ensures that the implementations of Web services

applications are compliant to standard
specifications, thus enabling interoperability with those compliant applications.
Some of the key design requirements of the Web services architecture are the following:

■ To provide a universal interface and a consistent solution model to define the

application as modular components, thus enabling them as exposable services

■ To define a framework with a standards-based infrastructure mo el and protocols to

support services-based applications over the Internet

■ To address a variety of service delivery scenarios ranging from e-business (B2C),

business-to-business (B2B), peer-to-peer (P2P), and enterprise application integration
(EAI)-based application communication

■ To enable distributable modular applications as a centralized and decentralized

application environment that supports boundary-less application communication for
inter- enterprise and intra-enterprise application connectivity

■ To enable the publishing of services to one or more public or private directories, thus
enabling potential users to locate the published services using standard-based
mechanisms that are defined by standards organizations

To enable the invocation of those services when it is required, subject to authentication,

authorization, and other security measures.

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?
Traditionally, 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 lightweight
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.

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 services 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 requester. The service requester is responsible
for the service invocation. The requester locates the Web service using the service broker,
invokes the required services, and executes it from the service provider.
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 format. 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 common wire format in allforms of communication. XML also is the basis for other
Web services standards.

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. Like XML, 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 format, 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 WSDLbased 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 standard 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 service the whole global business community of the Internet. The
UDDI working group includes leading technology vendors like Sun Micro systems, 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
modeling, business process collaborations, collaborative partnership profiles, and
agreements and messaging. ebXML is an initiative sponsored by the United Nations
Center for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization
for the Advancement of Structured Information Standards (OASIS). 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 the
Web services model, ebXML provides a comprehensive framework for the electronic
marketplace and B2B process communication by defining standards for business
processes, partner profile and agreements, registry and repository services, messaging
services, and core components. It complements and extends with other Web services
standards like SOAP, WSDL, and UDDI. In particular:

■■ ebXML Business Process Service Specifications (BPSS) enable business 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 registries 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 community. Examples of such components
are Procurement, Payment, Inventory, and so on.

Benefits and Challenges of using web services:

Known Challenges in Web Services Web services present some key challenges associated
with the mission-critical business requirements. These challenges need to be addressed
before the services are fully implemented. 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 availability. The exposed infrastructure must provide load balancing,
and failover and fault tolerance, to resolve these scenarios.

Security:Web services are exposed to the public using http-based protocols. As Web
services is publicly available, it must be implemented using authentication and
authorization mechanisms and using SSLenabling encryption of the messages for securing
the usage. Adopting 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. Quite clearly, Web services are the next major
technology for demonstrating a new way of communication and collaboration.
Web services Architecture

Web services Architecture and its Core building blocks:

The basic principles behind the Web services architecture are based on SOA and the
Internet protocols. It represents a composable application solution based on standards
and standards-based technologies. This ensures that the implementations of Web services
applications are compliant to standard specifications, thus enabling interoperability with
those compliant applications.
Some of the key design requirements of the Web services architecture are the following:
■■ To provide a universal interface and a consistent solution model to define the
application as modular components, thus enabling them as exposable services
■■ To define a framework with a standards-based infrastructure model and protocols to
support services-based applications over the Internet
■■ To address a variety of service delivery scenarios ranging from e-business (B2C),
business-to-business (B2B), peer-to-peer (P2P), and enterprise application integration
(EAI)-based application communication
■■ To enable distributable modular applications as a centralized and decentralized
application environment that supports boundary-less application communication for
inter-enterprise and intra-enterprise application connectivity
■■ To enable the publishing of services to one or more public or private directories, thus
enabling potential users to locate the published services using standard-based
mechanisms that are defined by standards organizations

■■ To enable the invocation of those services when it is required, subject to

authentication, authorization, and other security measures To handle these requirements,
a typical Web service architectural model consists of three key logical components as core
building blocks mapping the operational roles and relationships of a Web services
environment.
Figure 3.1 represents the core building blocks of a typical Web services architecture.

Services container/runtime environment:The services container acts as the Web

services runtime environment and hosts the service provider. Typical to a Web
application environment, it defines the Web services runtime environment meant for
client communication as a container of Web services interfaces by exposing the potential
components of the underlying applications. It facilitates the service deployment and
services administration. In addition, it also handles the registration of the service
description with the service registries. Usually, the Web services platform provider
implements the services container. In some circumstances, the Web application servers
provide system services and APIs that can be leveraged as the Web services container.

Services registry: The services registry hosts the published services and acts as a broker
providing a facility to publish and store the description of Web services registered by the
service providers. In addition, it defines a common access mechanism for the service
requestors for locating the registered services.

Services delivery.:It acts as the Web services client runtime environment by looking up
the services registries to find the required services and invoking them from the service
provider. It is represented as a presentation module for service requestors, by exposing
the appropriate interfaces or markups for generating content and delivery to a variety of
client applications, devices, platforms, and so forth.

To build the Web services architecture with these logical components, we need to use
standardized components and a communication model for describing and invoking the
services that are universally understood between the service providers and their
potential service requestors. It also requires a standard way to publish the services by the
service provider and store them in the service broker. In turn, service requestors can find
them.
WSDL. This resides in the services container and provides a standardized way to describe
the Web services as a service description. In ebXML-based architecture, ebXML CPP/A
provides services descriptions including business partner profiles and agreements.
UDDI. This provides a standard mechanism for publishing and discovering registered
Web services, and it also acts as the registry and repository to store WSDL-based service
descriptions. In ebXMLbased architecture, ebXML Registry & Repository provides a
facility to store CPP/CPA descriptions for business collaboration.

Web services are accessed using standard Internet protocols and XML—the Web services
architecture forms the standard infrastructure solution for building distributed
applications as services that can be published, discovered, and accessed over the Internet.

Web Services Communication Models:

In Web services architecture, depending upon the functional requirements, it is possible

to implement the models with RPC-based synchronous or messaging-based
synchronous/asynchronous communication models. These communication models need
to be understood before Web services are designed and implemented.
RPC-Based Communication Model :
The RPC-based communication model defines a request/response-based synchronous
communication. When the client sends a request, the client waits until a response is sent
back from the server before continuing any operation. Typical to implementing CORBA or
RMI communication, the RPC-based Web services are tightly coupled and are
implemented with remote objects to the client application. Figure 3.3 represents an RPC-
based communication model in Web services architecture.
The clients have the capability to provide parameters in method calls to the Web service
provider. Then, clients invoke the Web services by sending parameter values to the Web
service provider that executes the required methods, and then sends back the return
values. Additionally, using RPCbased communication, both the service provider and
requestor can register and discover services, respectively.
Messaging-Based Communication Model The messaging-based communication model
defines a loosely coupled and document-driven communication. The service requestor
invoking a messaging-based service provider does not wait for a response. Figure 3.4
represents a messaging-based communication model in Web services architecture. In
Figure 3.4, the client service requestor invokes a messaging-based Web service; it
typically sends an entire document rather than sending a set of parameters. The service
provider receives the document, processes it, and then may or may not return a message.

Depending upon the implementation, the client can either send or receive a document
asynchronously to and from a messaging-based Web service, but it cannot do both
functionalities at an instant. In addition, it also is possible to implement messaging with a
synchronous communication model where the client makes the service request to the
service provider, and then waits and receives the document from the service provider.
Adopting a communication model also depends upon the Web service provider
infrastructure and its compliant protocol for RPC and Messaging.

The current version of SOAP 1.2 and ebXML Messaging support these communication
models; it is quite important to ensure that the protocols are compliant and supported by
the Web services providers. It also is important to satisfy other quality of services (QoS)
and environmental requirements like security, reliability, and performance.
Basic steps of implementing web services:

The process of implementing Web services is quite similar to implementing any

distributed application using CORBA or RMI. However, in Web services, all the
components are bound dynamically only at its runtime using standard protocols. Figure
3.5 illustrates the process highlights of implementing Web services.
As illustrated in Figure 3.5, the basic steps of implementing Web services are as follows:

Figure 3.5 Process steps involved in implementing Web services.

1. The service provider creates the Web service typically as SOAPbased service interfaces
for exposed business applications. The provider then deploys them in a service container
or using a SOAP runtime environment, and then makes them available for invocation over
a network. The service provider also describes the Web service as a WSDL-based service
description, which defines the clients and the service container with a consistent way of
identifying the service location, operations, and its communication model.
2. The service provider then registers the WSDL-based service description with a service
broker, which is typically a UDDI registry.
3. The UDDI registry then stores the service description as binding templates and URLs to
WSDLs located in the service provider environment.
4. The service requestor then locates the required services by querying the UDDI registry.
The service requestor obtains the binding information and the URLs to identify the
service provider.
5. Using the binding information, the service requestor then invokes the service provider
and then retrieves the WSDL Service description for those registered services. Then, the
service requestor creates a client proxy application and establishes communication with
the service provider using SOAP.
6. Finally, the service requestor communicates with the service provider and exchanges
data or messages by invoking the available services in the service container.
In the case of an ebXML-based environment, the steps just shown are the same, except
ebXML registry and repository, ebXML Messaging, and ebXML CPP/CPA are used instead
of UDDI, SOAP, and WSDL, respectively. The basic steps just shown also do not include the
implementation of security and quality of service (QoS) tasks.
UNIT-2
Fundamentals of SOAP
SOAP message structure:
SOAP defines the structure of an XML document, rules, and mechanisms that can be used to enable
communication between applications. It does not mandate a single programming language or a
platform, nor does it define its own language or platform..

The example shown in Listing 4.1 is a SOAP request/response message for obtaining book price
information from a book catalog service provider.

The SOAP request accepts a string parameter as the name of the book and returns a float as the
price of the book as a SOAP Response.

POST /BookPrice HTTP/1.1

Host: catalog.acmeco.com
Content-Type: text/xml; charset=”utf-8”
Content-Length: 640
SOAPAction: “GetBookPrice”

<SOAP-ENV:Envelope
xmlns:SOAP ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=”http://www.w3c.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3c.org/2001/XMLSchema”
SOAP-ENV:encodingStyle
=”http://schemas.xmlsoap.org/soap/encoding/”>

<SOAP-ENV:Header>
<person:mail
xmlns:person=”http://acmeco.com/Header/”>[email protected]
</person:mail>
</SOAP-ENV:Header>

<SOAP-ENV:Body>
<m:GetBookPrice
xmlns:m=”http://www.wiley.com/jws.book.priceList”>
<bookname xsi:type=’xsd:string’>
Developing Java Web Services</bookname>
</m:GetBookPrice>
</SOAP-ENV:Body>
</SOAP-ENV: Envelope>

Listing 4.1 SOAP request message

In the scenario in Listing 4.1, the SOAP message is embedded in an HTTP request for getting the
book price information from www.wiley.comfor the book Developing Java Web Services.

Listing 4.2 shows the SOAP message embedded in an HTTP responsereturning the price
of the book.
HTTP/1.1 200 OK
Content-Type: text/xml; charset=”utf-8”
Content-Length: 640

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsi=”http://www.w3c.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3c.org/2001/XMLSchema”
SOAP-ENV:
encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/>
<SOAP-ENV:Header>
<wiley:Transaction
xmlns:wiley=”http://jws.wiley.com/2002/booktx”
SOAP-ENV:mustUnderstand=”1”> 5
</wiley:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetBookPriceResponse xmlns:m=”
http://www.wiley.com/jws.book.priceList”>
<Price>50.00</Price>
</m:GetBookPriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Listing 4.2 SOAP response message.

In Listing 4.2, you might have noticed that the SOAP message contains a SOAP Envelope SOAP-
ENV:Envelope as its primary root element, and it relies on defined “XML Namespaces”
commonly identified with a keyword xmlns and specific prefixes to identify the elements
and its encoding rules. All the elements in the message are associated with SOAP-ENV-defined
namespaces.Note that a SOAP application should incorporate and use the relevant SOAP
namespaces for defining its elements and attributes of its sending messages; likewise, it must be
able to process the receiving messages withthose specified namespaces. These namespaces must
be in a qualified W3CXML Schema, which facilitates the SOAP message with groupings of elements
using prefixes to avoid name collisions.
Usually a SOAP message requires defining two basic namespaces: SOAP Envelope and SOAP
Encoding. The following list their forms in both

versions 1.1 and 1.2 of SOAP.

SOAP ENVELOPE
■■ http://schemas.xmlsoap.org/soap/envelope/ (SOAP 1.1)
■■ http://www.w3.org/2001/06/soap-envelope (SOAP 1.2)

SOAP ENCODING
■■ http://schemas.xmlsoap.org/soap/encoding/ (SOAP 1.1)
■■ http://www.w3.org/2001/06/soap-encoding (SOAP 1.2)
Additionally, SOAP also can use attributes and values defined in W3C XML Schema instances or
XML Schemas and can use the elements based on custom XML conforming to W3C XML Schema
specifications. SOAP does not support or use DTD-based element or attribute declarations.

Typical to the previous example message, the structural format of a SOAP message (as per
SOAP version 1.1 with attachments) contains the following elements:
■■ Envelope
■■ Header (optional)
■■ Body
■■ Attachments (optional)
Figure 4.1 represents the structure of a SOAP message with attachments.Typically, a SOAP
message is represented by a SOAP envelope with zero or more attachments. The SOAP
message envelope contains the header and body of the message, and the SOAP message
attachments enable the mes-sage to contain data, which include XML and non-XML data
(like text/binary files). In fact, a SOAP message package is constructed using the MIME
Multipart/Related structure approaches to separate and identify thedifferent parts of the
message.

SOAP 1.1 Message SOAP Envelope

W/Attachments
SOAP Header
Header entry
SOAP Envelope
(Primary MIME part)
Header entry

SOAP Body
Attachment
Body entry
Attachment Body entry

Attachment

Attachment

Figure 4.1 Structure of a SOAP message with attachments.

SOAP Envelope
The SOAP envelope is the primary container of a SOAP message’s structure and is the
mandatory element of a SOAP message. It is represented as the root element of the
message as Envelope. As we discussed earlier, it is usually declared as an element using
the XML namespace http://schemas.xmlsoap.org/soap/envelope/.
As per SOAP 1.1 specifications, SOAP messages that do not follow this namespace
declaration are not processedand are considered to be invalid. Encoding styles also can be
defined usinga namespace under Envelope to represent the data types used in the
message. Listing 4.3 shows the SOAP envelope element in a SOAP message.

<!--SOAP Body element - -/>

</SOAP-ENV:Envelope>

Listing 4.3 SOAP Envelope element. (continued)

SOAP Header
The SOAP header is represented as the first immediate child element of a SOAP envelope,
and it has to be namespace qualified. In addition, it also may contain zero or more optional
child elements, which are referred to asSOAP header entries. The SOAP encodingStyle
attribute will be used to define the encoding of the data types used in header element
entries. The SOAP actor attribute and SOAP mustUnderstand attribute can be usedto

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsi=”http://www.w3c.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
SOAP-ENV:
encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/>

<!--SOAP Header elements - -/>

indicate the target SOAP application node (Sender/Receiver/Interme- diary) and to
process the Header entries. Listing 4.4 shows the sample rep- resentation of a SOAP
header element in a SOAP message.

<SOAP-ENV:Header>
<wiley:Transaction
xmlns:wiley=”http://jws.wiley.com/2002/booktx”
SOAP-ENV:mustUnderstand=”1”>
<keyValue> 5 </keyValue>
</wiley:Transaction>
</SOAP-ENV:Header>

Listing 4.4 SOAP Header element.

In Listing 4.4, the SOAP header represents a transaction semantics entry using the SOAP
mustUnderstand attribute. The mustUnderstand attribute is set to “1”, which
ensures that the receiver (URI) of this message must process it. We will look into the
mustUnderstand attributes in the next section. SOAP headers also provide
mechanisms to extend a SOAP message for adding features and defining high-level
functionalities such as security, transactions, priority, and auditing.

SOAP Body
A SOAP envelope contains a SOAP body as its child element, and it may contain one or
more optional SOAP body block entries. The Body repre- sents the mandatory
processing information or the payload intended for the receiver of the message. The SOAP
1.1 specification mandates that there must be one or more optional SOAP Body entries in
a message. A Body block of a SOAP message can contain any of the following:
■■ RPC method and its parameters
■■ Target application (receiver) specific data
■■ SOAP fault for reporting errors and status information
Listing 4.5 illustrates a SOAP body representing an RPC call for getting the book price
information from www.wiley.com for the book name Devel-oping Java Web Services.

<SOAP-ENV:Body>
<m:GetBookPrice
xmlns:m=”http://www.wiley.com/jws.book.priceList/”>
<bookname xsi:type=’xsd:string’>
Developing Java Web services</bookname>
</m:GetBookPrice>
</SOAP-ENV:Body>

Listing 4.5 SOAP Body element.

Like other elements, the Body element also must have a qualified name- space and be associated
with an encodingStyle attribute to provide the encoding conventions for the payload. In general,
the SOAP Body can con- tain information defining an RPC call, business documents in XML, and
any XML data required to be part of the message during communication.

SOAP Fault
In a SOAP message, the SOAP Fault element is used to handle errors and to find out status
information. This element provides the error and/or sta- tus information. It can be used within a
Body element or as a Body entry.

It provides the following elements to define the error and status of the SOAP message in a
readable description, showing the source of the infor- mation and its details:
Faultcode:The faultcode element defines the algorithmic mecha- nism for the SOAP application to
identify the fault. It contains stan- dard values for identifying the error or status of the SOAP
application. The namespace identifiers for these faultcode values are defined in
http://schemas.xmlsoap.org/soap/envelope/. The following fault- code element values are
defined in the SOAP 1.1 specification:
VersionMismatch:This value indicates that an invalid namespace is defined in the SOAP envelope
or an unsupported version of a SOAP message.
MustUnderstand:This value is returned if the SOAP receiver node cannot handle and recognize
the SOAP header block when the MustUnderstand attribute is set to 1. The MustUnderstand
values can be set to 0 for false and 1 for true.
Client: This faultcode is indicated when a problem originates from the receiving client. The
possible problems could vary from an incorrect SOAP message, a missing element, or incorrect
name- space definition.
Server: This faultcode indicates that a problem has been encoun- tered during processing on the
server side of the application, and that the application could not process further because the
issue is specific to the content of the SOAP message.
Faultstring: The faultstring element provides a readable descrip- tion of the SOAP fault exhibited
by the SOAP application.
Faultactor: The faultactor element provides the information about the ultimate SOAP actor
(Sender/Receiver/Intermediary) in the message who is responsible for the SOAP fault at the
particular destination of a message.
Detail: The detail element provides the application-specific error or status information related to
the defined Body block.
The common examples of SOAP fault scenarios:
How a SOAP Fault Is Represented in a SOAP Message
Listing 4.6 shows how a SOAP Fault is represented in a SOAP message.

<SOAP-ENV:Envelope xmlns:SOAP-ENV
=”http://schemas.xmlsoap.org/soap/envelope/”
SOAP-ENV:encodingStyle=

“http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:MustUnderstand</faultcode>
<faultstring>Header element missing</faultstring>
<faultactor>http://jws.wiley.com/GetBookPrice</faultactor>
<detail>
<wiley:error
xmlns:wiley=”http://jws.wiley.com/GetBookPrice”>
<problem>The Book name parameter missing.</problem>
</wiley:error>
</detail>
</SOAP-ENV:Fault>
</SOAP_ENV:Body>
</SOAP-ENV:Envelope>

Listing 4.6 SOAP Fault in a SOAP message.

SOAP Fault Is Caused Due to Server Failure
Listing 4.7 shows how a SOAP Fault is caused due to server failure.

<SOAP-ENV:Fault>
<faultcode> SOAP-ENV:Server</faultcode>
<faultstring> Server OS Internal failure - Reboot server</faultstring>
<faultactor>http://abzdnet.net/net/keysoap.asp</faultactor>
</SOAP-ENV:Fault>

Listing 4.7 SOAP Fault due to server failure.

Listing 4.8 shows how a SOAP Fault is caused due to client failure.

<SOAP-ENV:Fault>
<faultcode>Client</faultcode>
<faultstring>Invalid Request</faultstring>
<faultactor>http://jws.wiley.com/GetCatalog</faultactor>
</SOAP-ENV:Fault>

Listing 4.8 SOAP Fault due to client failure.

SOAP mustUnderstand
The SOAP mustUnderstand attribute indicates that the processing of a SOAP header block is
mandatory or optional at the target SOAP node. The following example is a SOAP request using
mustUnderstand and the response message from the server.
Listing 4.9 shows the request message where the SOAP message defines the header block with a
mustUnderstand attribute of 1.

<SOAP-ENV:Header>
<wiley:Catalog
xmlns:wiley=”http://jws.wiley.com/2002/bookList”
SOAP-ENV:mustUnderstand=”1”>
</wiley:Catalog>
</SOAP-ENV: Header>

Listing 4.9 SOAP mustUnderstand attribute.

Listing 4.10 is an example response message from the server when the server could not
understand the header block where the mustUnderstand is set to 1. Listing 4.10 is the server-
generated fault message detailing the issues with the header blocks using misUnderstood and
qname (faulting SOAP nodes) and providing a complete SOAP fault.
<SOAP-ENV:Envelope xmlns:SOAP-ENV
=”http://www.w3.org/2001/06/soap-envelope/”
SOAP-ENV:encodingStyle=
“http://www.w3.org/2001/06/soap-encoding/”
xmlns:fx=”http://www.w3.org/2001/06/soap-faults/”>
<SOAP-ENV:Header>
<fx:misUnderstood qname=”wiley:Catalog”
xmlns:wiley=”http://jws.wiley.com/2002/bookList/” />
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:mustUnderstand</faultcode>
<faultstring>Could not understand
Header element</faultstring>
</SOAP-ENV:Fault>
</SOAP_ENV:Body>
</SOAP-ENV:Envelope>

Listing 4.10 SOAP response using SOAP mustUnderstand.

SOAP Attachments
As per SOAP 1.1 with the attachment specification, a SOAP message con- tains the primary SOAP
envelope in an XML format and SOAP attachments in any data format that can be ASCII or binary
(such as XML or non-text). SOAP attachments are not part of the SOAP envelope but are related to
the message.
As the SOAP message is constructed using a MIME multipart/related structure, the SOAP
attachment part of the message is contained to a MIME boundary (defined in the Context-Type
header). Each MIME part in the structure of the SOAP message is referenced using either Content-
ID or Content-Location as labels for the part. Both the SOAP header and body of the SOAP
message also can refer to these labels in the message. Each attachment of the message is
identified with a Content-ID (typically an href attribute using a URL scheme) or Content-Location
(a URI reference associated to the attachment).

Listing 4.11 uses “WileyCoverPage.gif” as an attachment and illustrates the use of the Content-ID
(CID) reference in the body of the SOAP 1.1 mes- sage using absolute URI-referencing entities
labeled for using Content- Location headers.
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start=”<http://jws.wiley.com/coverpagedetails.xml>”
Content-Description: SOAP message description.

--MIME_boundary--
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <http://jws.wiley.com/coverpagedetails.xml>
Content-Location: http://jws.wiley.com/coverpagedetails.xml

<?xml version=’1.0’ ?>

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
<SOAP-ENV:Body>
<!-- SOAP BODY - ->
<theCoverPage href=”http://jws.wiley.com/DevelopingWebServices.gif”/>
<!-- SOAP BODY - ->
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary--
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-ID: <http://jws.wiley.com/DevelopingWebServices.gif>
Content-Location: http://jws.wiley.com/DevelopingWebServices.gif

<!--...binary GIF image... - ->

--MIME_boundary--

Listing 4.11 SOAP attachment in a MIME structure.

Although the SOAP 1.1 specification addressed the SOAP attachments based on MIME
Multipart/related, the W3C Working Group also is evaluating the support of MIME
Application/Multiplexed-based attachments that facilitate the attachment binary data of the
message can be interleaved from the XML contents of the message. To find out more information
on the latest specification of SOAP attachments, refer to www.w3.org/TR/SOAP-attachments.

SOAP Encoding
The SOAP encoding defines a set of rules for expressing its data types. It is a generalized set of
data types that are represented by the programming languages, databases, and semi-structured
data required for an application. SOAP encoding also defines serialization rules for its data model
using an encodingStyle attribute under the SOAP-ENV namespace that specifies the serialization
rules for a specific element or a group of elements.
2.3Encoding Different Data types:
SOAP encoding supports both simple- and compound-type values.
Simple Type Values
The definition of simple type values is based on the “W3C XML Schema, Part -2: Datatypes”
specification. Examples are primitive data types such as string, integer, decimal, and derived
simple data types including enumeration and arrays. The following examples are a SOAP
representation of primitive data types:
<int>98765</int>
<decimal> 98675.43</decimal>
<string> Java Rules </string>
The derived simple data types are built from simple data types and are expressed in the W3C
XML Schema.
Enumeration:Enumeration defines a set of names specific to a base type. Listing 4.12 is an
example of an enumeration data type expressed in a W3C XML Schema.

MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml;
start=”<http://jws.wiley.com/coverpagedetails.xml>”
Content-Description: SOAP message description.

--MIME_boundary--
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <http://jws.wiley.com/coverpagedetails.xml>
Content-Location: http://jws.wiley.com/coverpagedetails.xml

<?xml version=’1.0’ ?>

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”>
<SOAP-ENV:Body>
<!-- SOAP BODY - ->
<theCoverPage href=”http://jws.wiley.com/DevelopingWebServices.gif”/>
<!-- SOAP BODY - ->
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

--MIME_boundary--
Content-Type: image/gif
Content-Transfer-Encoding: binary
Content-ID: <http://jws.wiley.com/DevelopingWebServices.gif>
Content-Location: http://jws.wiley.com/DevelopingWebServices.gif

<!--...binary GIF image... - ->

--MIME_boundary--

Listing 4.12 Enumeration data type.

Array of Bytes
Listing 4.13 is an example of an array data type of an array of binary data that is represented as
text using base64 algorithms and expressed using a W3C XML Schema.

<myfigure xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xmlns:enc=” http://schemas.xmlsoap.org/soap/encoding”>
xsi:type=”enc:base64”>
sD334G5vDy9898r32323</myfigure>

Listing 4.13 An array.

Polymorphic Accessor
The polymorphic accessor enables programming languages to access data types during runtime.
SOAP provides a polymorphic accessor instance by defining an xsi: type attribute that represents
the type of the value.
The following is an example of a polymorphic accessor named price
with a value type of "xsd:float" represented as follows:

<price xsi:type=”xsd:float”>1000.99</price>
And, the XML instance of the price data type will be as follows:

<price>1000.99</price>
Compound Type Values
Compound value types are based on composite structural patterns that represent member values
as structure or array types. The following sec- tions list the main types of compound type values.
Structure Types
Listing 4.14 is an XML Schema of the Structure data type representing the “Shipping address”
with subelements like “Street,” “City,” and “State.”

<xs:element name=”ShippingAddress”
xmlns:xs=”http://www.w3.org/2001/XMLSchema” >
<xs:complexType>
<xs:sequence>
<xs:element ref=”Street”type=”xsd:string”/>
<xs:element ref=”City” type=”xsd:string”/>
<xs:element ref=”State” type=”xsd:string”/>
<xs:element ref=”Zip” type=”xsd:string”/>
<xs:element ref=”Country” type=”xsd:string”/>
</xs:sequence>
</xs:complexType>
</xs:element>

Listing 4.14 Structure data type.

And, the XML instance of the ShippingAddress data type is shown in Listing 4.15.

<e:ShippingAddress>
<Street>1 Network Drive</Street>
<City>Burlington</City>
<State>MA</State>
<Zip>01803</Zip>
<Country>USA</Country>
</e:ShippingAddress>

Listing 4.15 Resulting XML instance of a structure data type.

The structure also can contain both simple and complex data type values that can reference each
other (see Listing 4.16). The structure uses the “href” attribute to reference the value of the
matching element.
<e:Product>
<product>Sun Blade 1000</product>
<type>Hardware</type>
<address href=”#Shipping”/>
<address href=”#Payment”/>
<e:/Product>
<e:Address id=”Shipping”>
<Street>1 Network Drive</Street>
<City>Burlington</City>
<State>MA</State>
<Zip>01803</Zip>
<Country>USA</Country>
</e:Address>
<e:Address id=”Payment”>
<Street>5 Sunnyvale Drive</Street>
<City>Menlopark</City>
<State>CA</State>
<Zip>21803</Zip>
<Country>USA</Country>
</e:Address>

Listing 4.16 Structure data type using simple and complex types.
Array Types
Listing 4.17 is an XML Schema of an Array data type representing
MyPortfolio — a list of portfolio stock symbols.

<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema”
xmlns:enc=”http://schemas.xmlsoap.org/soap/encoding” >
<xs:import
namespace=”http://schemas.xmlsoap.org/soap/encoding” >
<xs:element name=”MyPortfolio” type=”enc:Array”/>
</xs:schema>

Listing 4.17 Compound array types.

The XML instance of the MyPortfolio data type is shown in Listing 4.18.

<MyPortfolio xmlns:xs=”http://www.w3.org/2001/XMLSchema”
xmlns:enc=” http://schemas.xmlsoap.org/soap/encoding”
enc:arrayType=”xs:string[5]”>
<symbol>SUNW</symbol>
<symbol>IBM</symbol>
<symbol>HP</symbol>
<symbol>RHAT</symbol>
<symbol>ORCL</symbol>
</MyPortfolio>

Listing 4.18 Resulting XML instance of a compound array type.

Multiple References in Arrays
SOAP encoding also enables arrays to have other arrays as member values. This is accomplished
by having the id and href attributes to reference the values. Listing 4.19 shows an example of an
XML instance that has arrays as member values.

<MyProducts xmlns:xs=”http://www.w3.org/2001/XMLSchema”
xmlns:enc=”
http://schemas.xmlsoap.org/soap/encoding”
enc:arrayType=”xs:string[][3]”>
<item href=”#product-hw”/>
<item href=”#product-sw”/>
<item href=”#product-sv”/>
<SOAP-ENC:Array id=”product-hw”
SOAP-ENC:arrayType=”xsd:string[3]”>
<item>SUN Blade 1000</item>
<item>SUN Ultra 100</item>
<item>SUN Enterprise 15000</item>
</SOAP-ENC:Array>
<SOAP-ENC:Array id=”product-sw”
SOAP-ENC:arrayType=”xsd:string[2]”>
<item>Sun Java VM</item>
<item>Sun Solaris OS</item>
</SOAP-ENC:Array>
<SOAP-ENC:Array id=”product-sv”

SOAP-ENC:arrayType=”xsd:string[2]”>
<item>Sun Java Center services</item>
<item>Sun Java Web Services</item>
</SOAP-ENC:Array>

Listing 4.19 Multiple references in arrays.

Partially Transmitted Arrays

Partially transmitted arrays are defined using a SOAP-ENC:offset, which enables the offset
position to be indicated from the first element (counted as zero-origin), which is used as an offset
of all the elements that will be transmitted. Listing 4.20 is an array of size [6]; using SOAP-
ENC:offset=”4” transmits the fifth and sixth elements of a given array of numbers (0,1,2,3,4,5).

<SOAP-ENC:Array SOAP-ENC:arrayType=”xsd:string[6]”
SOAP-ENC:offset=”[2]”>
<item> No: 2</item>
<item> No: 3</item>
<item> No: 4</item>
<item> No: 5</item>
</SOAP-ENC:Array>

Listing 4.20 Partially transmitted arrays.

Sparse Arrays
Sparse arrays are defined using a SOAP-ENC:position, which enables the position of an attribute
to be indicated with an array and returns its value instead of listing every entry in the array.
Listing 4.21 shows an example of using a sparse array in an array.

<SOAP-ENC:Array SOAP-ENC:arrayType=”xsd:int[10]”>
<SOAP-ENC:int SOAP-ENC:position=”[0]”>0</SOAP-ENC:int>
<SOAP-ENC:int SOAP-ENC:position=”[10]”>9</SOAP-ENC:int>
</SOAP-ENC:Array>

Listing 4.21 Sparse arrays.

Serialization and Deserialization

In SOAP messages, all data and application-specific data types are represented as XML, and it is
quite important to note that there is no generic mechanism to serialize application-specific data
types to XML. SOAP implementation provides application-specific encoding for application
programming languages (such as Java and C++). It also enables developers to define custom
application-specific encoding, especially to handle the data representation required and its data
types adopting data types defined by the “W3C XML Schema, Part -2” specification.This is usually
implemented as application or programming language-specific serialization and deserialization
mechanisms that represent application-specific data as XML and XML as application-specific
data.Most SOAP implementations provide their own serialization and deserialization
mechanisms and a predefined XML Schema supporting the SOAP encoding rules and mapping
application-specific data types. These serializers and deserializers supporting SOAP encoding
rules provide the encoding and decoding of data on runtime by mapping XML elements to target
application objects and vice versa. It leverages interoperability between disparate applications
using SOAP messages.

SOAP Message Exchange Model

SOAP is a stateless protocol by nature and provides a compos- able one-way messaging
framework for transferring XML between SOAP applications which are referred to as SOAP nodes.
These SOAP nodes rep- resent the logical entities of a SOAP message path to perform message
rout- ing or processing. In a SOAP message, SOAP nodes are usually represented with an endpoint
URI as the next destination in the message. In a SOAP message, a SOAP node can be any of the
following:
SOAP sender:The one who generates and sends the message.
SOAP receiver:The one who ultimately receives and processes the message with a SOAP
response, message, or fault.
SOAP intermediary:The one who can play the role of a SOAP sender or SOAP receiver. In a SOAP
message exchange model, there can be zero or more SOAP intermediaries between the SOAP
sender and receiver to provide a distributed processing mechanism for SOAP messages.Figure
4.2 represents a basic SOAP message exchange model with differ ent SOAP nodes.In a SOAP
message exchange model, the SOAP message passes from the initiator to the final destination by
passing through zero to many intermediaries. In a SOAP messaging path, the SOAP
intermediaries represent cer tain functionalities and provide routing to the next message
destination. It is important to note that SOAP does not define the actual SOAP senders,
intermediaries, and receivers of the SOAP message along its message path or its order of
destination. However, SOAP can indicate which part of the message is meant for processing at a
SOAP node. Thus, it defines a decen tralized message-exchanging model that enables a
distributed processing in the message route with a message chain.
Figure 4.3 represents an example of a complete message exchange model with a sender, receiver,
and its intermediaries. In the previous example, the message originates from Sender A to
Receiver D via Intermediaries B and C as a request chain, and then as a response chain the
message originates from Receiver D to Sender A via Intermediary E.

Figure 4.2 Basic SOAP message exchange model.

Figure 4.3 SOAP message exchange model with intermediaries.

SOAP Intermediaries
SOAP defines intermediaries as nodes for providing message processing and protocol routing
characteristics between sending and receiving appli- cations. Intermediary nodes reside in
between the sending and receiving nodes and process parts of the message defined in the SOAP
header. The two types of intermediaries are as follows:
Forwarding intermediaries:This type processes the message by describing and constructing the
semantics and rules in the SOAP header blocks of the forwarded message.
Active intermediaries:This type handles additional processing by modifying the outbound
message for the potential recipient SOAP nodes with a set of functionalities.In general, SOAP
intermediaries enable a distributed processing model to exist within the SOAP message exchange
model. By using SOAP intermediaries, features can be incorporated like store and forward,
intelligent routing, transactions, security, and logging, as well as other value additions to SOAP
applications.
SOAP Actor
In a SOAP message to represent a target SOAP node, the SOAP actor global attribute with a URI
value can be used in the Header element. SOAP defines an actor with a URI value, which identifies
the name of the SOAP receiver node as an ultimate destination. Listing 4.22 is an example of a
SOAP actor attribute.

Listing 4.22 SOAP actor attribute.

Additionally, SOAP defines the actor with a special URI http://
schemas.xmlsoap.org/soap/actor/next, which indicates a hop-by-hop communication using the
header element where the SOAP message is routed via one to many intermediaries before its final
destination. Listing

<SOAP-ENV:Envelope xmlns:SOAP-
ENV=”http://schemas.xml.org/soap/envelope/”
SOAP-ENV:encodingStyle=”http://schemas.xml.org/soap/encoding/”/>
<SOAP-ENV:Header>
<b:Name xmlns:t=”http://www.wiley.com/BookService/”
SOAP-ENV:actor=”http://www.wiley.com/jws/”
SOAP-ENV :mustUnderstand=”1”>
WebServices</b:Name >
</SOAP-ENV:Header>
<SOAP:Body> <m:NewBook xmlns:m=”http://www.wiley.com/Books”>
<BookName>Developing Java Web services</BookName>
</m:NewBook>
</SOAP:Body>
</SOAP:Envelope>
4.23 is an example of a SOAP message that is forwarded via two SOAP intermediaries before the
final receiving node.

Listing 4.23 SOAP message forwarded via SOAP intermediaries. (continued)

SOAP Communication And Messaging

SOAP is designed to communicate between applications independent of the underlying platforms
and programming languages. To enable communication between SOAP nodes, SOAP supports the
following two types of communication models:
SOAP RPC:It defines a remote procedural call-based synchronous communication where the
SOAP nodes send and receive messages using request and response methods and exchange
parameters and then return the values.
SOAP Messaging:It defines a document-driven communication where SOAP nodes send and
receive XML-based documents using synchronous and asynchronous messaging.
SOAP RPC
The SOAP RPC representation defines a tightly coupled communication model based on requests
and responses. Using RPC conventions, the SOAP message is represented by method names with
zero or more para- meters and return values. Each SOAP request message represents a call
method to a remote object in a SOAP server and each method call will have zero or more
parameters. Similarly, the SOAP response message will return the results as return values with
zero or more out parameters. In both SOAP RPC requests and responses, the method calls are
serialized into XML-based data types defined by the SOAP encoding rules.
Listing 4.24 is an example of a SOAP RPC request making a method call GetBookPrice for
obtaining a book price from a SOAP server namespace http://www.wiley.com/jws.book.priceList
using a ”book- name” parameter of ”Developing Java Web Services”.

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=”http://www.w3c.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3c.org/2001/XMLSchema”
SOAP-ENV:encodingStyle
=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetBookPrice
xmlns:m=”http://www.wiley.com/jws.book.priceList”>
<bookname xsi:type=’xsd:string’>
Developing Java Web services</bookname>
</m:GetBookPrice>
</SOAP-ENV:Body>
</SOAP-ENV: Envelope>

Listing 4.24 SOAP request using RPC-based communication.

The SOAP message in Listing 4.25 represents the SOAP RPC response after processing the SOAP
request, which returns the result of the Get- BookPrice method from the SOAP server namespace
http://www. wiley.com/jws.book.priceList using a “Price” parameter with “$50” as its value.

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=”http://www.w3c.org/2001/XMLSchema-instance”
xmlns:xsd=”http://www.w3c.org/2001/XMLSchema”
SOAP-ENV:encodingStyle
=”http://schemas.xmlsoap.org/soap/encoding/”>
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetBookPrice
xmlns:m=”http://www.wiley.com/jws.book.priceList”>
<bookname xsi:type=’xsd:string’>
Developing Java Web services</bookname>
</m:GetBookPrice>
</SOAP-ENV:Body>
</SOAP-ENV: Envelope>
</m:GetBookPriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Listing 4.25 SOAP response message using RPC-based communication.

The communication model in Listing 4.25 is similar to a traditional CORBA- or RMI-based
communication model, except the serialized data types are represented by XML and derived from
SOAP encoding rules.

SOAP Messaging
SOAP Messaging represents a loosely coupled communication model based on message
notification and the exchange of XML documents. The SOAP message body is represented by XML
documents or literals encoded according to a specific W3C XML schema, and it is produced and
con- sumed by sending or receiving SOAP node(s). The SOAP sender node sends a message with
an XML document as its body message and the SOAP receiver node processes it.
Listing 4.26 represents a SOAP message and a SOAP messaging-based communication. The
message contains a header block InventoryNotice and the body product, both of which are
application-defined and not defined by SOAP. The header contains information required by the
receiver node and the body contains the actual message to be delivered.

<env:Envelope xmlns:env=”http://www.w3.org/2001/12/soap-envelope”>
<env:Header>
<n:InventoryNotice xmlns:n=”http://jws.wiley.com/Inventory”>
<n:productcode>J6876896896</n:productcode>
</n: InventoryNotice>
</env:Header>
<env:Body>
<m:product xmlns:m=”http://jws.wiley.com/product”>
<m:name>Developing Java Web Services</m:name>
<m:quantity>25000</n:quantity>
<m:date>2002-07-01T14:00:00-05:00</n:date>
</m:product>
</env:Body>
</env:Envelope>

Listing 4.26 SOAP message using messaging-based communication.

Java and Axis

Apache Axis is an open-source implementation that provides a Java-based SOAP implementation
for developing Web services. To implement Web services, it facilitates a SOAP runtime
environment and Java-based API framework for implementing the core components of Web
services adopt- ing compliant standards and protocols.
As a packaged solution, the Apache Axis environment provides the following:
■■ A SOAP-compliant runtime environment that can be used as a standalone SOAP server or as
a plug-in component in a compliant Java servlet engine (such as Tomcat, iPlanet, and Weblogic)
■■ An API library and runtime environment for developing SOAP RPC and SOAP messaging-
based applications and services
■■ A transport-independent means for adopting a variety of transport protocols (such as HTTP,
SMTP, and FTP)
■■ Automatic serialization and deserialization for Java objects to and from XML in SOAP
messages
■■ Support for exposing EJBs as Web services, especially the methods of stateless session EJBs
■■ Tools for creating WSDL from Java classes and vice-versa
■■ Tools for deploying, monitoring, and testing the Web services
Axis also provides full-fledged implementation support for Sun JWSDP 1.0 APIs, especially JAX-
RPC and SAAJ. At the time of this book’s writing, Axis 1.0B3 provides limited implementation
support of JAX-RPC 1.0 and SAAJ 1.1 specifications. To find out the current status of the Axis
imple- mentation and its availability for download, go to Apache’s XML Web site at
http://xml.apache.org/axis/.

Installing Axis for Web Services

The process of installing Axis for building a Web services environment is quite simple. Axis can
be installed as part of a Java servlet engine or as a J2EE-compliant application server, or it also
can run as an independent server. Because our focus is creating Web services using Axis, we
require Axis installation using a Java servlet engine. For our illustration, we will be using the
Apache Tomcat 4.0.3 servlet engine available for download from
http://jakarta.apache.org/tomcat/index.html.
Now, let’s take a look at the steps involved in installing Axis within an Apache Tomcat server
environment:
 Download the Apache Axis tool kit (current release) from http://xml.apache.org/axis/.
Unzip (Windows) or untar (UNIX) the package to your local system directory (for example,
d:\xml- axis) and set an environment variable as AXIS_HOME.
 Download Apache Tomcat 4.0.3 (or current release) from
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/ and then install it to your
local system directory (that is, d:\tomcat4) and set an environment variable as
TOMCAT_HOME. After installation, start the Tomcat server and ensure that it is working by
locating http://localhost:8080/index.html with your browser. The browser will display the
screen shown in Figure 4.9
 Navigate to your Axis installation home directory and copy the axis folder from
AXIS_HOME\webapps\ to TOMCAT_HOME\webapps\ to deploy the Axis libraries as an Axis
servlet.
 To deploy the Axis libraries as a servlet in the Tomcat container, create a context in the
Tomcat server configuration by editing TOMCAT_HOME/conf/server.conf with the following
lines:
<Context path=”/axis” docBase=”axis” debug=”0” reloadable=”true” crossContext=”true”>
</Context>
Figure 4.9 Browser showing successful installation of the Apache Tomcat environment.
 Add axis-specific supporting class libraries(JARs) in the Tomcat environment. The required
supporting class libraries include the following:
■■ Apache Xerces parser for Java (Xerces2) with JAXP 1.1 support, which is available
for download a http://xml.apache.org/xerces2-j/index.html. Unzip the download and
copy the xerces.jar file to TOMCAT_HOME\webapps\axis\WEB-INF\lib.
■■ If your application requires database connectivity or other appli- cation access,
ensure that you copy all of the JDBC drivers and required class libraries to
TOMCAT_HOME\webapps\axis\WEB-INF\lib.
■■ As part of the kit, Axis provides class libraries for JAXRPC and JAXM as jaxrpc.jar
and saaj.jar. In the case of using JAX-RPC and JAXM/SAAJ libraries, ensure that these JAR
files are copied to TOMCAT_HOME\common\lib.
 To test the Axis Web services environment, start the Tomcat server. Then, use your Web
browser and open the followings URLs:
■■ To confirm installation: http:localhost:8080/axis/index.html
■■ To validate the Axis environment: http://localhost:8080/axis
/happyaxis.jsp
■■ To list the available Axis services: http://localhost:8080/axis
/servlet/AxisServlet
 To compile and test applications, create a run script (.bat or .sh) to ensure that the
CLASSPATH in the development environment includes the following:
AXIS_HOME/lib/axis.jar
AXIS_HOME/lib/jaxrpc.jar
AXIS_HOME/lib/saaj.jar
AXIS_HOME/lib/commons-logging.jar
AXIS_HOME/lib/log4j-1.2.4.jar
AXIS_HOME/lib/xmlsec.jar
AXIS_HOME/lib/tt-bytecode.jar
AXIS_HOME/lib/wsdl4j.jar
AXIS_HOME/xerces.jar
AXIS_HOME/<DATABASE/OTHER_LIBRARIES.jar> DEVELOPMENT_HOME/

Axis Web Services Programming Model

To create a Web service in an Axis environment, implementation of the following is required:
1.Create the service provider (server application)
2.Create the service requestor (client applications)
The key concepts involved in implementing the Web service provider and requestors using an
Axis environment.

Creating the Service

Axis allows a service to be created from an existing Java-based Web appli- cation just by
identifying the methods required to be exposed and deploy- ing them in the Axis server.
1.In an RPC-based communication model, a service client invokes the exposed method and a
response is returned. In this process, the Axis server engine transforms the Java objects to XML
and vice versa, using automatic serializer and deserializer mechanisms during communication.
The following example is a simple service example, which accepts a string parameter and invokes
a method justSayHello and returns a String parameter:
public class HelloAxis
{
public String justSayHello(String s)
{
return “Hello “ + s “, Welcome to Axis !!!”;
}
}

2.In a messaging-based communication model, the client sends an XML document and the server
application receives the XML as a W3C Document object for processing. It is not mandatory for
the service to send a response back to the client. In case of sending a response, the service
returns a W3C Document object as a body of the SOAP response message. The following snippet
is a method that receives a purchase order XML as a W3C document for processing. Upon
successful processing, it sends out a response message as a W3C document with the shipping
notice, otherwise it sends out a product availability status notice.
public Document sendPODocument (Document poXML)
throws Exception {
// process purchase order
boolean processPO = submitPurchaseOrder(poXML);

if (processPO) {
//TRUE: create Shipping notice Document doc = getShippingDoc(poXML);
}
else
// FALSE: create product availability status Document doc =
getAvailabilityStatus(poXML); return doc;
}
Creating the Service Requestor
Axis allows service clients to be created in two different ways:
1.Having the required values for locating and invoking the service provider, such as SOAP,
endpoint of the service, methods, parameters, and so on
2.Using a WSDL-based service description exposed by the service provider
The programming steps involved in creating the service client with all of the required
parameters and how to invoke the service exposed by the provider.

Creating a Normal Service Requestor Client

In case of an RPC-based communication model, the key programming steps involved for creating
a service client are as follows:
1.Import Axis packages, the most important ones of which are the following:
import org.apache.axis.AxisFault; import org.apache.axis.client.Call; import
org.apache.axis.client.Service;
import org.apache.axis.encoding.XMLType; import javax.xml.rpc.ParameterMode; import
javax.xml.namespace.QName;
2.Define the endpoint of the service:
String endpoint =
“http://localhost:8080/axis/services/HelloService”;
3.Create a service:
Service service = new Service();
4.Create a SOAP request call:
Call call = (Call) service.createCall();
5.Set the target endpoint of the provider location:
call.setTargetEndpointAddress( endpoint );
6.Set the service operation name and its methods:
call.setOperationName(
new QName(“HelloService”, “sayHello”) );
7.Set the parameters required for the operation. The parameters must provide the
equivalent mapping of a W3C XML Schema:
call.addParameter( “myName”,
MLType.XSD_STRING, ParameterMode.IN );
8.Set the return type parameters from the SOAP response. The para- meters must provide
the equivalent mapping of a W3C XML Schema:
call.setReturnType( XMLType.XSD_STRING );
9.Invoke the service by sending the request and retrieve the results. The invoke() method
returns a Java object with parameters of the method and it is required to cast the return
values as a Java object:
Object responseObj = call.invoke( new Object[]
{new Integer(myName)} );

In case of a messaging-based communication model, the key program- ming steps involved for
creating the service client are as follows:
1.Import the Axis packages, the most important ones of which are the following:
import org.apache.axis.client.Service; import org.apache.axis.client.Call; import
org.apache.axis.message.*; import org.apache.axis.*;
import java.net.URL;
import org.apache.axis.utils.XMLUtils; import org.w3c.dom.*;
2.Define the endpoint of the service:
String endpoint =
“http://localhost:8080/axis/services/HelloMSG”;
3.Read the XML document as an input stream or string:
InputStream is =
ClassLoader.getSystemResourceAsStream(“hello.xml”);
4.Create a new service:
Service service = new Service();
5.Create a SOAP request call using the service:
Call call = (Call) service.createCall();
6.Set the target endpoint of the provider location:
call.setTargetEndpointAddress( endpoint );
7.Create a SOAP envelope with an XML payload:
SOAPEnvelope env = new SOAPEnvelope(is);
8.Send the SOAP envelope with an XML payload to the destination:
call.invoke(env);
9.In case of obtaining a response message, the response message also will be a W3C
document as well:
SOAPEnvelope elems = (SOAPEnvelope)call.invoke(env);

Creating the Service Requestor Client from WSDL

Axis provides a WSDL2Java utility for building Java proxies and skeletons from WSDL obtained
from service providers. To create Java proxy classes from a WSDL, you would run the following
command:

java org.apache.axis.wsdl.WSDL2Java <Provider-WSDL-URL>

It also is possible to create service clients dynamically using dynamic invocation interfaces
provided by JAX-RPC. This is discussed further in Chapter 10, “Building RPC Web Services with
JAX-RPC.”
To understand how to create Axis service clients from WSDL, refer to the full-featured example in
Chapter 3, “Building the Web Services Architecture.”
Axis Deployment Model
Axis facilitates easy deployment and undeployment of services using XML- based Web services
deployment descriptors (WSDDs). It enables deploying and undeploying services and also Axis-
specific resources like handlers and chains using an administration utility ‘AdminClient’ provided
as part of the Axis toolkit.
To deploy a service, ensure that the AXIS CLASSPATH is set and run the following command:

java org.apache.axis.client.AdminClient deploy.wsdd

The deploy.wsdd refers to the deployment descriptor defining the ser- vice, classes, methods,
provider (RPC or Messaging), and its namespaces.
Listing 4.36 is a sample WSDD to deploy a service in an Axis environment.

<deployment name=”test”
xmlns=”http://xml.apache.org/axis/wsdd/”
xmlns:java=”http://xml.apache.org/axis/wsdd/providers/java”
xmlns:xsd=”http://www.w3.org/2000/10/XMLSchema”
xmlns:xsi=”http://www.w3.org/2000/10/XMLSchema-instance”>

<service name=”HelloService” provider=”java:RPC”>

<parameter name=”className”
value=”jws.ch4.helloservice.HelloService”/>
<parameter name=”allowedMethods” value=”justSayHello”/>
</service>
</deployment>

Listing 4.36 Web services deployment descriptor (WSDD) for deploying a service.
The previous WSDD defines HelloService using a provider with an RPC-based communication
model by exposing its class jws.ch4.helloservice.HelloService and its method justSayHello. The
deployment name test is an identifier and the namespaces define the W3C XML schemas
associated with the implementation.
Similarly, to undeploy a service, ensure that the AXIS CLASSPATH is set and then run the
following command:

java org.apache.axis.client.AdminClient undeploy.wsdd

The undeploy.wsdd defines the service required to undeploy from the Axis runtime environment.
Listing 4.37 is a sample WSDD defining the ser- vices to be undeployed:

<undeployment name=”test”
xmlns=”http://xml.apache.org/axis/wsdd/”
xmlns:java=”http://xml.apache.org/axis/wsdd/providers/java”
xmlns:xsd=”http://www.w3.org/2000/10/XMLSchema”
xmlns:xsi=”http://www.w3.org/2000/10/XMLSchema-instance”>
<service name=” HelloService “/>
</undeployment>

Listing 4.37 Web services deployment descriptor (WSDD) for undeploying a service.
Additionally, to find out the list of services deployed in the Axis envi- ronment, run the following
command:
java org.apache.axis.client.AdminClient list
This command will list all the services deployed in an Axis environment. It also is possible to
deploy and undeploy the services in an Axis environment by editing the server-config.xml file
located at AXIS_HOME directory.

Deploying Axis Services Using JWS Files (.jws)

Axis allows the deployment of Web services using Java classes with .jws extensions. It is quite
typical to the Java server pages (JSP) deployed in a servlet engine. By placing Java classes (source
files) with .jws extensions in the Web applications directory (that is,
TOMCAT_HOME/webapps/axis/) during runtime, Axis runtime automatically compiles and
deploys the classes with all of the methods as deployed services. In this case, it does not require
WSDD-deployment descriptors.

Limitations of SOAP
SOAP (Simple Object Access Protocol) is a protocol used for exchanging structured information in
the implementation of web services. Some of its limitations include:

1. *Complexity:* SOAP can be complex due to its XML-based structure, making it more
challenging for human readability and requiring additional bandwidth for transmission
compared to other lightweight protocols.
2. *Performance:* The XML format used in SOAP messages can sometimes lead to larger message
sizes, resulting in increased bandwidth usage and slower performance compared to more
compact protocols like REST.
3. *Overhead:* Due to its adherence to strict standards and formalities, SOAP can have higher
overhead in terms of processing, which can impact performance, especially in scenarios where
efficiency is critical.
4. *Tight Coupling:* SOAP tends to create tightly coupled systems due to its strict definition of
message formats, making it more challenging to evolve and modify services without affecting
clients.
5. *Less Support for Web Browsers:* SOAP was initially designed with remote procedure calls in
mind and is not as well-suited for browser-based applications as other protocols like REST,
which can use HTTP methods directly.
6. *Limited Compatibility:* While SOAP provides a well-defined standard for communication
between applications, ensuring compatibility across different platforms and languages can
sometimes be a challenge.
These limitations have led to the development and adoption of alternative web service protocols
like REST (Representational State Transfer) that offer more flexibility and simplicity in many
cases.
UNIT-3

DESCRIBING WEB SERVICES

Web Services Description Language (WSDL)

Web Services Description Language (WSDL) is a standard specification for describing
networked, XML-based services. It provides a simple way for service providers to describe
the basic format of requests to their systems regardless of the underlying run-time
implementation.
WSDL defines an XML format for describing network services as a set of endpoints that
operate on messages that contain either document-oriented or procedure-oriented
information. The operations and messages are first described abstractly and then bound
to a concrete network protocol and message format in order to define an endpoint.
Related concrete endpoints are combined into abstract endpoints (services). WSDL is
extensible to allow description of endpoints and their messages, regardless of which
message formats or network protocols are used to communicate. This means that
interfaces are defined abstractly using XML schema and then bound to concrete
representations that are appropriate for the protocol.
WSDL allows a service provider to specify the following characteristics of a Web service:
 The name of the Web service and addressing information
 The protocol and encoding style to be used when accessing the public operations of
the Web service
 The type information such as operations, parameters, and data types comprising the
interface of the Web service

WSDL in the World of Web Services

WSDL, as we know, is a description language for Web services. So what does this exactly
mean? This means that WSDL represents information about the interface and semantics of
how to invoke or call a Web service. A WSDL definition contains four important pieces of
information about the Web service
 Interface information describing all the publicly available functions
 Data type information for the incoming (request) and outgoing (response) messages
to these functions
 Binding information about the protocol to be used for invoking the specified Web
service
 Address information for locating the specified Web service
Once we develop a Web service, we create its WSDL definition. We can create this
definition either manually or by using a tool. Many tools are available for generating a
WSDL definition from existing Java classes, J2EE components (such as Servlets/EJBs), or
from scratch. Once the WSDL definition is created, a link to it is published in a Web
services registry (based on UDDI, for instance), so that the potential user(s) of this Web
service can follow this link and find out the location of the Web service, the function calls
that it supports, and how to invoke these calls. Finally, the user(s) would use this
information to formulate a SOAP request or any other type of request based on the
binding protocol supported, in order to invoke the function on a Web service.

Web Service Life Cycle

Figure 5.1 illustrates the steps of the Web service life cycle.

In Figure 5.1, all of the communication over the wire takes place on SOAP. The following
list explains the steps depicted in Figure 5.1:
 Step 1 illustrates a service provider publishing its Web service to a UDDI registry.
This is when the service provider would create a WSDL definition and publish a link
to this definition along with the rest of the Web service information to a UDDI registry.
 Step 2 illustrates an interested service user locating the Web service and finally
obtaining information about invoking the Web service from the published WSDL
definition. This step involves downloading a WSDL definition to the service user
system and deserializing WSDL to a Java class (or any other language). This Java
interface serves as a proxy to the actual Web service. It consists of the binding
information of the Web service.
 Step 3 shows the service user binding at runtime to the Web service. In this step, the
service user’s application would make use of the Java interface representing WSDL as
a proxy, in order to bind to the Web service.
 Step 4 finally shows the service user invoking the Web service based on the service
invocation information it extracted from the Web service WSDL definition. This is
when the service user’s application would make use of the Java interface representing
WSDL as a proxy, in order to invoke the methods/functions exposed by the Web
service.

Language and Platform Independency of WSDL

WSDL is capable of describing Web services that are implemented using any language
and deployed on any platform. Thus, WSDL contributes toward enabling interoperability
in the Web service architecture. In other words, as long as a WSDL definition can be
understood and consumed by the service user, the service user systems can obtain all of
the information necessary to invoke a Web service potentially developed and deployed
using a completely different set of platform tools and servers. Now, let’s see what a typical
WSDL document looks like and understand its structural elements.

Anatomy of a WSDL Definition Document

A WSDL definition document consists of the following seven key structural elements:
 <definitions>. A WSDL document is a set of definitions. These definitions are
defined inside the element, which is the root element in a WSDL document. It defines
the name of the Web service and also declares the namespaces that are used
throughout the rest of the WSDL document.
 <types>. This element defines all of the data types that would be used to describe
the messages that are exchanged between the Web service and the service user.
WSDL does not mandate the use of a specific typing system. However, as per the
WSDL specification, XML Schema is the default typing system. XML Schema was
discussed in Chapter 4, “Developing Web Services Using SOAP,” in the context of SOAP
encoding.
 <message>. This element represents a logical definition of the data being
transmitted between the Web service and the service user. This element describes a
one-way message, which may represent a request or response sent to or from the
Web service. It contains zero or more message elements, which basically refer to the
request parameters or response return values.
 <prototype>. This element defines the abstract definition of the operations
supported by a Web service, by combining various request and response messages
defined by elements. Each operation refers to an input message and an output
message.
 <binding>. This element specifies a concrete protocol and data format used for
representing the operations and messages defined by a particular , on the wire.
 <port> . This element specifies an address for binding to the Web service.
 <service>. This element aggregates a set of related elements, each which uniquely
specify the binding information of the Web service. A consisting of multiple elements
essentially represents the capability of the service to be invoked over multiple
bindings. More information on WSDL bindings is discussed in the next section.

We will further examine each of these elements later. First, let’s take a look at Listing 5.1,
which shows a WSDL document describing a weather information Web service,
WeatherInfoService. This WSDL definition is present in the WeatherInfo.wsdl file.
Now, let’s understand how exactly WeatherInfo.wsdl describes the WeatherInfoService
Web service.
<definitions>Element

The <definitions>element specifies the name of the document in which this WSDL
definition is stored, which is WeatherInfo in our case. This element specifies namespaces
that would be used in the rest of the WSDL document. The following are the two
important namespaces that the<definitions> element defines:

WSDL instance specific namespace. The targetNamespace attribute of the <definitions>

element lets the WSDL document make references to itself as an XML Schema namespace.
Note however that it is not required for the WSDL document to actually exist at the
address specified by the targetNamespace attribute. This attribute is just a mechanism to
refer to our WSDL definition in a unique way.
Default namespace for a WSDL document. The default namespace is specified by
xmlns=”http://schemas.xmlsoap.org/wsdl/”. The default namespace indicates that all of
the elements in this WSDL definition without a namespace prefix, such
as ,<types> ,<message> and ,<portType> are part of this namespace.
<message>Element
WeatherInfo.wsdl defines two<message> elements.
The first<message> definition named GetWeatherInfoInput will be used later to define the
input message of the GetWeatherInfo operation. The second <message>definition named
GetWeatherInfoOutput will be used later to define the output message of the
GetWeatherInfo operation. This binding of <message> definitions to an actual operation is
defined in the <portType>element.

<portType>Element
The <portType>element in WeatherInfo.wsdl defines a single operation named
GetWeatherInfo by combining the <input>message as defined by the
GetWeatherInfoInput <message>element and the<output> message as defined by the
GetWeatherInfoOutput<message> element. Note the use of WeatherInfo.wsdl as a target
namespace by the <input> and <output> elements.
Four types of operations are supported by WSDL:
One-way operation. One-way operation represents a service that just receives the
message, and thus a one-way operation is typically defined by a single <input> message
element.
Request-response operation. A request-response operation represents a service that
receives a request message and sends a response message. Typically, a request-response
operation is defined by one <input> message followed by one<output> message. An
optional <fault> element also can be included in the definition of a requestresponse
operation to specify the abstract message format for any error messages that may be
output as a result of the operation.
The GetWeatherInfo operation follows the request-response transmission pattern.
Solicit-response operation. A solicit-response operation represents a service that sends
a request message and that receives the response message. Such operations are therefore

defined by one message, followed by an <input> message. A solicit-

response operation also can include a <fault> element in order to specify the format of
any error messages resulting from the operation.
Notification operation. This operation represents a service that sends a message, hence
this kind of operation is represented by a single <output> element.
Figure 5.2 provides the pictorial representation of the previous four transmission types.
<binding>Element
A binding defines the message format and protocol details for operations and messages
defined by a particular <portType> . There may be any number of bindings for a given
<portType> . The type attribute of the <binding> element refers to the <portType> that it
binds to, which is WeatherInfoPortType in our case. Our WeatherInfoService specifies a
SOAP binding, as is defined in the WSDL 1.1 specification. The WSDL 1.1 SOAP binding is
discussed in detail in a later section titled SOAP Binding.

<service>Element
The <service>element specifies the location of the service. Because our
WeatherInfoService is bound to SOAP, we use the element and specify the service URL as
http://myweather.com /provideweatherinfo/.

WSDL Bindings
In WSDL, the term binding refers to the process of associating protocol or data format
information with an abstract entity such as <message>,<operation> , or <portType> . In
this section, we examine the support for bindings in the WSDL 1.1 specification. Let’s
begin with the WSDL binding extensions.

WSDL Binding Extensions

WSDL allows user-defined elements, also known as Extensibility Elements, under various
elements defined by a default WSDL namespace. These elements are commonly used to
specify some technology-specific binding, although they can be used for other purposes as
well. Extensibility elements, when used to specify a technology-specific binding, are
known as WSDL Binding Extensions.
Extensibility elements provide a powerful mechanism for extending WSDL because they
enable support for network and message protocols to be revised without having to revise
the WSDL specification.
The base specification of WSDL defines three WSDL binding extensions, which are as
follows:
 SOAP binding
 HTTP GET & POST binding
 MIME binding
We will take a look at the most commonly used WSDL binding extension, the SOAP
binding, in a later section titled SOAP Binding.

WSDL Binding Support for Operations

All four types of operations supported by WSDL—one-way, requestresponse, solicit-

response, and notification—represent an abstract notion only. Binding describes the
concrete correlation to these abstract notions. Binding determines how the messages are
actually sent, for instance, within a single communication (for example, an HTTP
request/response) or as two independent communications (for example, two HTTP
requests). Thus, binding for a specific operation type must be defined in order to
successfully carry out that type of operation. Note that although the WSDL structure
supports the bindings for these four operations, the WSDL specification defines bindings
for only one-way and request-response operations. Hence, in order to use WSDL to
describe services that support solicit-response and/or notification types of operations, the
communication protocol of the Web service must define the WSDL binding extensions,
thus enabling the use of these operations.

SOAP Binding
WSDL 1.1 defines a binding for SOAP 1.1 endpoints. This binding provides the following
SOAP protocol specific information:
An indication that the binding is bound to the SOAP 1.1 protocol
A way of specifying an address for a SOAP endpoint
The URI for the SOAP action HTTP header for the HTTP binding of SOAP
A list of definitions of headers that are transmitted as part of the SOAP envelope
Let’s examine the SOAP binding of the request-response RPC operation over HTTP as
defined in the WeatherInfo.wsdl file shown earlier (see the section titled Anatomy of a
WSDL Definition Document).
<soap:binding>

The <soap:binding>element is defined in WeatherInfo.wsdl as follows:

<soap:binding stule=”document”
Transport=http://schemas.xmlsoap.org/soap/http/>
The <soap:binding>element says that the binding is bound to the SOAP protocol format,
that is, envelope, header, and body. However, this element does not give any information
about the format or encoding of the message. This element must be present whenever
describing services that have a SOAP binding.
The style attribute indicates whether the operations supported by this binding are RPC-
oriented or document-oriented. In RPC-oriented communication, the messages contain
parameter and return values, whereas in document-oriented communication, the
messages contain document(s). This information about the style of communication can be
useful because it helps in selecting the programming model for communicating with the
212 Chapter 5 Web service. For example, if a Web service is described to support RPC, we
can choose a JAX-RPC programming model to communicate with it, or if a Web service is
described to support document-style communication, we can appropriately choose a
JAXM programming model.
The transport attribute specifies the transport binding for the SOAP protocol. The URI
value of http://schemas.xmlsoap.org/soap/http corresponds to the HTTP binding as
defined in the SOAP specification. Similarly, respective URIs can be used to indicate other
types of transports such as SMTP or FTP.

<soap:operation>
The <soap:operation>element is defined in WeatherInfo.wsdl as follows:

The <soap:operation>element defines the information with regard to communication

style and the SOAP action header at that specific operation level.
The semantics of the style attribute remains the same as that for a
<soap:operation>element.
The soapAction attribute specifies the value of a SOAP action header in the form of a URI.
The usage of the SOAP action header was discussed in Chapter 4, “Developing Web
Services Using SOAP.”
<soap:body>
The <soap:body>element is defined in WeatherInfo.wsdl as follows:

This element defines how the message elements appear inside the SOAP body element.
Based on the style of communication, RPCoriented or document-oriented, the element of
the SOAP message is constructed.
The use attribute indicates whether the message elements are encoded using some
encoding rules or whether the elements already define the concrete schema of the
message.
If the value of the use attribute is “encoded”, then each message refers to an abstract type
defined through the type attribute. These abstract types are then used to produce a
concrete definition of the message by applying the encoding specified by an encodingStyle
attribute.
WSDL Tools
WSDL tools typically provide functionality in terms of the following:
WSDL generation. Generating WSDL from an existing service component—for example, a
J2EE component or a Java Bean component or from scratch.
WSDL compilation. A typical WSDL compiler would generate the necessary data
structures and a skeleton for the implementation of the service. The generated
implementation skeleton contains all the methods (operations) that are described in the
given WSDL definition.
WSDL proxy generation. This functionality can read a WSDL and produce a specific
language binding (for example, Java or Perl) consisting of all the code required to bind the
Web service and to invoke the Web service functions at runtime. This functionality is
typically used at the client end.
Many WSDL tools provide support for these three functionalities. Table 5.1 lists some of
the famous ones in the Java Web Services space.

Limitations of WSDL
 WSDL does not support one-way messaging (Single-mode). It requires both output and
input.
 It does not permit overload operations.
 All operations need to be of one kind, i.e., either all doc/literal or RPC-encoded.
 It does not support SOAP-encoded structures and SOAP-encoded arrays.
 There is no support for output mapping (header in response).
 WSDL focuses solely on SOAP operations and disregards HTTP and MIME operations.
 WSDL cannot include more than one element of <wsdl:include> (cannot have more than one
file).
UNIT-4
Discovering Web Services
Service Discovery
Web services discovery provides access to software systems over the Internet using
standard protocols. In the most basic scenario there is a Web Service Provider that
publishes a service and a Web Service Consumer that uses this service.
Web Service Discovery is the process of finding suitable web services for a given
task.Universal Description, Discovery, and Integration (UDDI) is an XML-based registry for
business internet services.
Publishing a Web service involves creating a software artifact and making it accessible to
potential consumers. Web Service Providers augment a Web service endpoint with an
interface description using the Web Services Description Language (WSDL) so that a
consumer can use the service.
Optionally, a provider can explicitly register a service with a Web Services Registry such
as Universal Description Discovery and Integration (UDDI) or publish additional
documents intended to facilitate discovery such as Web Services Inspection Language
(WSIL) documents. The service users or consumers can search Web Services manually or
automatically. The implementation of UDDI servers and WSIL engines should provide
simple search APIs or web-based GUI to help find Web services.
Web services may also be discovered using multicast mechanisms like WS-Discovery, thus
reducing the need for centralized registries in smaller networks.

Role of Service Discovery in SOA

An SOA Service Registry is the core component of SOA Governance. The Service registry
allows service providers to discover and communicate with consumers efficiently,
creating a link between service providers and service customers. The primary focus of
Service Registry is to provide fast, easy access to communication, and to operate among
different applications with a limited human intervention.
An SOA registry supports the UDDI(Universal Description, Discovery and Integration)
specification, an XML- (Extensible Markup Language) based registry that was developed
for the purpose of making systems interoperable. Publication of a service requires proper
description of a Web service in terms of business, service, and technical information. Once,
the services are published the registry will create the dependencies, associations and
versions of these services and metadata.
Benefits of SOA Service Registry:

 Service Registry plays an important role in SOA implementation which helps in

managing services metadata.

 Service Registry is a constantly evolving catalog of information about the available

services in an SOA implementation

 Service Registry helps in managing service located in different places (internally,

externally) and in different life-cycle states (under development, in-plan, deployed or
retired)

 Service Repository is where metadata of services and related SOA artifacts, such as
policies can be stored.

 Service Registry and/or Repository Provides an integrated SOA Governance Solution

management.

 Provides access to search facilities, notification services, and optimizes servicereuse.

 Managing the Service life-cycle and visibility to all SOA assets with their related
artefacts.

SOA Service Discovery

Service discovery is the process of locating web service providers, and retrieving web
services descriptions that have been previously published. The primary mechanism
involved in performing of Service Discovery is a service registry, which contains relevant
metadata about available and upcoming services as well as pointers to the corresponding
service contract documents that can include SLAs.

In modern architectures nodes come and go and you need to decouple individual service
instances from the knowledge of the deployment topology of your architecture.

After the discovery process is complete, the service developer or client application should
know the exact location of a Web service (URI), its capabilities, and how to interface with
it.
Benefits of SOA Service Discovery

 Discovery of the service, its status, and its owner will be critical to achieve the
benefits of SOA re usability.
 Dynamic service registration and discovery becomes much more important in these
scenarios in order to avoid service interruption.
 Handling Fail over of service instances

 Load balancing across multiple instances of a Service

Service Discovery Mechanisms

Traditionally, the Web service discovery processes involved manual interference. A set of
Web service descriptions is discovered according to user requirements. These service
descriptions are manually scanned and those services which satisfy user requirements are
selected and composed. In distributed system integration environment, such manual
intervention is impractical, cumbersome and time consuming. The approaches to Web
services discovery can be classified as centralized and decentralized. UDDI falls under
fully centralized approach that supports replication where central registries are used to
store Web service descriptions. Having realized that replicating the UDDI data is not a
scalable approach several decentralized approaches have been proposed. Two major
operators, namely IBM and Microsoft provide public UDDI service. Web service discovery
mechanisms include a series of registries, indexes, catalogues, agent based and Peer to
Peer P2P solutions. The most dominating among them is the Universal Description
Discovery and Integration-UDDI standard that is currently in version 3.
Universal Description, Discovery and Integration (UDDI):
UDDI enables the businesses providing services (in electronic form or in any other
medium) to register information to enable the discovery of their services and business
profile by prospective customers and/or partners. Similarly, it enables businesses to
discover other businesses for expanding potential business partnerships. Thus, UDDI
presents businesses with an opportunity to step into new markets and services. It powers
all kinds of businesses, large, medium, or small, to accelerate their business presence in
this global market. UDDI initially started as a joint effort from IBM, Microsoft, and Ariba.
Since then, a number of companies joined the UDDI community. As of this book’s writing,
the UDDI project community is looking forward to releasing version 3.0 of the UDDI
specification.

UDDI Registries
An implementation of the UDDI specification is termed as a UDDI registry. UDDI registry
services are a set of software services that provide access to the UDDI registry. Meanwhile,
registry services can perform a plethora of other activities such as authenticating and
authorizing registry requests, logging registry requests, load-balancing requests, and so
on.
Public and Private UDDI Registries
A UDDI registry can be operated in two modes: public mode and private mode. A public
UDDI registry is available for everyone to publish/query the business and service
information on the Internet. Such public registries can be a logical single system built
upon multiple UDDI registry nodes that have their data synchronized through replication.
Thus, all the UDDI reg- istry node operators would each host a copy of the content and
accessing any node would provide the same information and quality of service as any
other operator node. Such global grouping of UDDI registry nodes is known as a UDDI
Business Registry, or UBR. Content can be added into a UBR from any node, however,
content can be modified or deleted only at a node at which it was inserted.
A private UDDI registry is operated by a single organization or a group of collaborating
organizations to share the information that would be avail- able only to the participating
bodies. Private UDDI registries can impose additional security controls to protect the
integrity of the registry data and to prevent access by unauthorized users. Note that a
private node also can participate in information replication.
A UDDI registry in itself is a Web service. A Web service consumer queries the UDDI
registry using the SOAP API defined by UDDI specifica- tion. Also, the UDDI specification
publishes a WSDL description of the UDDI registry service.
The UDDI project community members operate a UBR. This registry is available to
everyone for free publishing/querying of businesses and ser- vices information. To find
more information on this publicly operated UDDI registry, visit the UDDI Web site at
www.uddi.org.

Interacting with a UDDI Registry

Typically, vendors implementing a UDDI registry provide two ways of interacting with a
UDDI Registry Service.
■■ A graphical user interface (GUI), for interacting with a UDDI reg- istry. These GUIs
also can be browser-based. The following is a list of public UDDI registries, operated by
various companies such as Microsoft, IBM, Hewlett Packard, and so on, that provide a
browser- based interface to these registries:
■■ https://uddi.rte.microsoft.com/search/frames.aspx
■■ https://www-3.ibm.com/services/uddi/v2beta/protect/registry.html
■■ https://uddi.hp.com/uddi/index.jsp
■■ http://udditest.sap.com/
■■ http://www.systinet.com/uddi/web
Figure 5.3 shows a browser-based GUI provided by Systinet in order to interact with its
publicly hosted UDDI registry. This screenshot depicts the interface provided for
searching businesses registered with the Systinet registry.

Figure 5.3 Web-based GUI to UDDI registry.

■■ A programmatic interface for communicating with the UDDI registry. These
programmatic interfaces are based on SOAP, because the UDDI registry supports SOAP as
the communication protocol.
■■ Most of the vendors providing the UDDI registry implementations support both of
these types of access to the registry.
Uses of UDDI Registry
Businesses can use a UDDI registry at three levels:
White pages level: Businesses that intend to register just the very basic information
about their company, such as company name, address, contact information, unique
identifiers such as D-U-N-S numbers or Tax IDs, or Web services use UDDI as white pages.
Yellow pages level: Businesses that intend to classify their information based on
categorizations (also known as classification schemes or taxonomies) make use of the
UDDI registry as yellow pages.
Green pages level: Businesses that publish the technical information describing the
behavior and supported functions on their Web ser- vices make use of the UDDI registry
as green pages.
Note that the UDDI specification does not explicitly make references to these different
types of usage levels of the UDDI registry. The categoriza- tion of these levels is rather
implicit.
UDDI Specifications
All versions of the UDDI specifications can be obtained from the UDDI organization at
their Web site at http://uddi.org/specification.html. The UDDI 2.0 specification set
includes the following documents:
UDDI replication: The document describes the data replication process of the UDDI
registries. Also, it describes the programmatic interfaces supported by UDDI for achieving
replication between UDDI registries operated by different operators.
UDDI operators: This document provides information on the operational behavior that
should be followed by UDDI node operators. For example, the document defines
guidelines that node operators can follow in order to manage the data of the UDDI registry
node. Such guidelines include the following:
■■ Node operators’ responsibility for durable recording and backup of all data.

■■ Checking the validity of information provided by businesses during registration, such

as email addresses.
■■ Checking the integrity of data in the UDDI registry after it has been modified. For
example, if a business has been deleted from the registry, then the operator should ensure
that the services corresponding to this business also are deleted.
Note that private UDDI node operators are not required to follow the guidelines
mentioned in this document.
UDDI programmer’s API: This document describes the programming interfaces
supported by a UDDI registry in terms of SOAP messages. This document is targeted
towards programmers who want to write software that would interact with a UDDI
registry operated at a public or private level, using SOAP.
Programming with UDDI
This section introduces the APIs used for communicating with a UDDI reg- istry. Also,
important data structures and categorization support of UDDI are discussed.

UDDI Programming API

The UDDI specification defines two XML-based programming APIs for communicating
with the UDDI registry node: inquiry API and publishing API. The following sections
describe each of these.
Inquiry API
The inquiry API consists of XML messages defined using a UDDI Schema, which can be
used to locate information about a business, such as the ser- vices a business offers and
the technical specification of those services (such as a link to a WSDL document
describing the interface of the service, the binding of the service and the URL where the
service is running, and so on). A UDDI programmer would use these inquiry APIs to
retrieve information stored in the registry. To retrieve information, a registry user does
not need to be authenticated.
The following is a list of inquiry API functions that can be used for finding information in a
UDDI registry:

■■ <find_business>
■■ <find_relatedBusinesses>
■■ <find_service>
■■ <find_binding>
■■ <find_tModel>
To get further detailed information from the UDDI registry, the following inquiry API
functions are available:
■■ <get_businessDetail>
■■ <get_businessDetailExt>
■■ <get_serviceDetail>
■■ <get_bindingDetail>
■■ <get_tModelDetail>
Publishing API
The publishing API consists of functions represented by a UDDI Schema, which defines
XML messages that can be used to create, update, and delete the information present in a
UDDI registry. Note that in order to publish to a UDDI registry, the registry user needs to
be authenticated.
The following is a list of publishing API functions that can be used for adding/modifying
information to a UDDI registry:
■■ <save_business>
■■ <set_publisherAssertions>
■■ <add_publisherAssertions>
■■ <save_service>
■■ <save_binding>
■■ <save_tModel>
The following is a list of publishing API functions that can be used for deleting information
from a UDDI registry:
■■ <delete_business>
■■ <delete_publisherAssertions>
■■ <delete_service>
■■ <delete_binding>
■■ <delete_tModel>
Apart from the functions just mentioned, the publishing API also defines functions that
deal with the authentication of the registry users, which is required in order to
successfully execute the rest of the functions of this API:
■■ <get_authToken>
■■ <discard_authToken>
The XML messages constituting the UDDI programmer APIs are defined using a UDDI XML
Schema. These XML messages are wrapped in a SOAP message and then sent to the UDDI
registry. In other words, all of the XML messages are enveloped within a SOAP <body>
element and then sent as an HTTP POST request to the UDDI registry. The UDDI registry
then processes these SOAP messages and gets hold of the actual API function represented
by the XML message, which further instructs the registry ser- vices to provide either
publishing or querying services.
A UDDI registry node typically enables access to both inquiry and publishing
functionalities through different access point URLs. Table 5.3 lists the URLs for publicly
operated UDDI registry nodes.
As we can see from Table 5.3, all of the URLs corresponding to the pub- lishing access
points support HTTPS, because publishing operations need authenticated access.
Table 5.3 Access Point URLs

Note that all the UDDI invocations follow a synchronous request/response mechanism
and are stateless in nature. This statelessness has a significant impact on the
authentication of a registry user to the UDDI registry, which is required when performing
a publishing operation on the registry. Because of the stateless nature of the UDDI
programming API, each time a registry user uses a publishing programming API, the
security credentials of the identity associated with the registry user also are passed with
each UDDI invocation.

UDDI Data Structures

The information managed by a UDDI registry is represented as XML data structures also
known as UDDI data structures. The UDDI data structures specification document defines
the meaning of these data structures and the relationship between them. Ultimately, it is
these data structures with which a UDDI client needs to work. A UDDI client makes use of
these, in conjunction with the XML messages of programming APIs, to manipulate a
specific type of information in a registry. Similarly, response to a search operation
received from the UDDI registry also would consist of these data structures. Hence, the
UDDI data structures are more or less input and out- put parameters for the UDDI
programming API.
The following are the five primary UDDI data structures defined in the specification:
■■ <businessEntity>
■■ <publisherAssertion>
■■ <businessService>
■■ <bindingTemplate>
■■ <tModel>
Note that all of these data structures except <publisherAssertion> are identified and
referenced through a 128-bit globally unique identifier also known as UUID. These UUIDs
can later be used as keys to access the specific data within the registry.
Now, let’s take a look at each of these one by one.
<businessEntity>
The <businessEntity> data structure represents the primary information about a business,
such as contact information, categorization of the business according to a specific
taxonomy or classification scheme, identifiers, rela- tionships to other business entities,
and descriptions about that particular business. The categorizations are discussed in a
later section titled Support for Categorization in UDDI Registries.
<publisherAssertion>
A business registered in a UDDI registry can have active business relationships with other
businesses. This relationship can be of any form, for example, a relationship of business
partners or a business-to- customer relationship. Such relationships are represented
by a
<publisherAssertion> data structure in a UDDI Registry. The
<publisherAssertion> structure is used to establish a relationship between two
<businessEntity> structures.
A very interesting aspect about relationships in a UDDI registry is its ability to not make
the relationship visible to the public unless and until both of the parties establishing this
association assert for the same. This means that if a <businessEntity> structure
representing Company A asserts its relationship with a <businessEntity> structure
representing Company B through a <publisherAssertion> structure, a UDDI reg- istry
would not make this relationship public until Company B has created another similar
<publisherAssertion> structure. This provision is supported by the UDDI registries in
order to ensure that a company can claim a business relationship with another company,
only if the other part- ner also asserts for the same relationship.
<businessService>
The <businessService> data structure represents the service of a busi- ness. These
services can be Web services or any other type of service. For example, the
<businessService> data structure may represent a service that is offered over the
telephone, such as a telephone banking service. The <businessService> data structure is
merely a logical representation of services that a business has to offer.
A <businessEntity> structure contains one or more
<businessService> structures. The same <businessService> struc- ture also can be used by
multiple <businessEntity> structures. For example, if a business has two departments—
say, manufacturing and sales— that are each published to a UDDI registry as a
<businessEntity> structure, then both of them can use the same <businessService> struc-
ture representing another business service—say, legal counseling.
<bindingTemplate>
The <bindingTemplate> structure consists of pointers to technical descriptions and
access URLs of the service. Each <businessService>structure can contain one or more
<bindingTemplate> structures. So, for example, if the <businessService> structure
represents a Web ser- vice, then its <bindingTemplate> would refer to a PDF document
pro- viding the technical description of this Web service and the URL at which the Web
service can be accessed. Also, the <bindingTemplate> structure can provide an optional
description of the Web service.
Note that the <bindingTemplate> structure does not provide the details of the service
specification, such as the interface of a service. That information is provided by the
<tModel> structures, and <bindingTemplate> simply refers to one or more of such
<tModel> structures.

<tModel>
The <tModel> structure provides a description of a particular specification or behavior of
the service. The <tModel> structure does not contain the service specification directly;
instead, it contains a link to the service specification, which is managed elsewhere. The
<tModel> thus defines the interaction pattern in order to use the service. For example, a
business may provide a Web service whose WSDL interface may be referenced through a
link from within the <tModel> structure.
Thus, <tModel> defines the lowest-level and most concrete piece of information about the
services offered by a business. A UDDI client typi- cally gets hold of the service
specification pointed out by the <tModel> structure in order to use a publicly available
Web service registered by a particular business.
The linking between these five core data structures of UDDI is depicted in Figure 5.4.
Apart from these five primary data structures, two other structures exist that represent
the category and identification information of the primary data structures:
<identifierBag> and <categoryBag>.
<identifierBag>
The <identifierBag> structure enables <businessEntity> or
<tModel> structures to include information about the common forms of identification
such as D-U-N-S numbers and tax IDs. This data can be used to signify the identity of
<businessEntity>, or it can be used to signify the identity of the publishing party.
Including such identification informa- tion is optional. However, when a published
<businessEntity> or <tModel> carries such common forms of identification, it greatly
enhances the search behaviors exposed via inquiry API functions.
<categoryBag>
The<categoryBag>structure enables<businessEntity>,
<businessService>, and <tModel> structures to be categorized according to any categorization
system, such as an industry categorization system or a geography categorization system.
Categorizing the data structures mentioned previously is optional. However, when these data
structures are published along with their categorization information, it greatly enhances the
search behaviors exposed via inquiry API functions.

Publishing API
Publishing to a UDDI registry requires an authenticated access. UDDI specification does
not define authentication mechanisms, and hence, authentication is dependent upon the
implementations of UDDI. Also, a URL different from an inquiry URL usually handles
publishing-related API calls. Typically, HTTPS is used for carrying publishing call
request/response information.
Table 5.9 lists the publishing API functions as well as their semantics. The table also lists
the structure that is returned in response to each of these function calls.
Table 5.9 Publishing API Functions (continued)
Publishing Information to a UDDI Registry
SubmitBusiness.java shows us how to publish a business named ACME Computer Services
along with its description. In the coming sections, we will examine the source code of
SubmitBusiness.java, followed by its compilation and execution.
Programming Steps for Publishing
The entire publishing logic is provided by the doSubmit() method of the
jws.ch5.SubmitBusiness class, and hence, its implementation is of most interest to us. The
following are the steps of doSubmit():

1. Construct the UDDIApiPublishing object. This is the object that we will use to actually
publish to the registry.
2. Get hold of the authentication token from the registry with the help of the
get_authToken() API call on the UDDIApiPublishing object. Once we have the
authentication token, we should be able to publish to the registry.
3. Create the BusinessEntity structure and populate it with the name and description of
the business to submit. Note that we do not have to create the key for this business
because the registry, upon submitting the business information, would generate it.
4. Now, get hold of the SaveBusiness object. This object represents a collection of
businesses that we wish to submit at a time. Hence, we will need to add the
BusinessEntity object that we just created to the SaveBusiness object using the
addBusinessEntity() method.
5. Now, publish the business information through a save_busi- ness() call on
UDDIApiPublishing object. This method call takes the SaveBusiness object as an
argument and returns the BusinessDetail object upon completion.
6. After the publishing operation has been executed, discard the authen- tication token.
Finally, check whether the publishing operation was successful or not.
7.
SubmitBusiness.java Source Code
Listing 5.5 shows the complete code listing of SubmitBusiness.java.
package jws.ch5;

import org.idoox.uddi.client.api.v2.*;
import org.idoox.uddi.client.api.v2.request.publishing.*; import
org.idoox.uddi.client.structure.v2.business.*; import
org.idoox.uddi.client.structure.v2.base.*;
import org.idoox.uddi.client.api.v2.response.*; import org.idoox.uddi.*;

public class SubmitBusiness

{
public static void main(String args[]) throws Exception
{
// Call the method in order to submit new business to
// the public registry hosted by Systinet.

doSubmit();
}

public static void doSubmit() throws Exception

{
String sBusinessName = “ACME Computer Services”; String sBusinessDescription =
“Provides professional services in the areas of Computer Software”;

System.out.println(“Saving business with the following details:”);

System.out.println(“Name: “ + sBusinessName);

System.out.println(“Description: “ + sBusinessDescription);

// Get hold of the UDDI Publishing API

// Note our usage of Publishing URL for the Systinet
// UDDI Registry

UDDIApiPublishing objUDDIApiPublishing =
UDDILookup.getPublishing(“https://www.systinet.com:443
/wasp/uddi/publishing/”);

// First we get hold of Authentication token from the

// Registry so that we can publish to the UDDI
// Registry. Note that registered a user in Systinet
// Public Registry with registry_user ID and
// registry_user password.

AuthToken objAuthToken = objUDDIApiPublishing. get_authToken (new

GetAuthToken(new UserID(“registry_user”), new Cred(“registry_user”)));

// Create the BusinessEntity Structure BusinessEntity objBusinessEntity =

new BusinessEntity();

// Set the empty businessKey since we are creating a

// new business objBusinessEntity.setBusinessKey
(new BusinessKey(“”));

// Set the name of the business objBusinessEntity.addName(new

Name(sBusinessName));

// Set the description of the business objBusinessEntity.addDescription

(new Description(sBusinessDescription));

// Get hold of the SaveBusiness interface SaveBusiness objSaveBusiness = new

SaveBusiness();

// Set the Authentication Information on SaveBusiness

objSaveBusiness.setAuthInfo (objAuthToken.getAuthInfo());

// Now add the BusinessEntity to save to the

// SaveBusiness interface objSaveBusiness.addBusinessEntity(objBusinessEntity);

// Finally publish the SaveBusiness object to the

// registry
BusinessDetail objBusinessDetail =
objUDDIApiPublishing.save_business(objSaveBusiness);

// Discard the Authentication token now objUDDIApiPublishing.discard_authToken

(new DiscardAuthToken(objAuthToken.getAuthInfo()));

// See if the Business has been published

// successfully
if (objBusinessDetail==null)
{
System.err.println(“\nUnsuccessful in submitting the new business information to
registry.”);

}
else
{
System.err.println(“\nSuccessful in submitting the new business information to
registry.”);
}
return;
}
}

Compiling and Executing SubmitBusiness.java

The following command line instruction compiles SubmitBusiness
.java:
>javac jws/ch5/SubmitBusiness.java
The following command line instruction executes SubmitBusiness
.java:
>java -classpath %CLASSPATH%;. jws.ch5.SubmitBusiness
Figure 5.7 shows the output of this execution.
You can verify the creation of this new business by visiting the Systinet public registry or
by executing SearchBusiness.

Searching Information in a UDDI Registry

SearchBusiness.java shows us how to search for businesses based on the name pattern
provided by the user. In the coming sections, we will examine the source code of
SearchBusiness.java, followed by its com- pilation and execution.

Figure 5.7 Executing SubmitBusiness.java.

Programming Steps for Searching
The entire querying logic is provided by the doSearch() method of the
jws.ch5.SearchBusiness class, and hence, its implementation is of most interest to us. The
following are the steps to implementing a doSearch():
 Construct the FindBusiness object. This object represents the criteria for the search
operation. Hence, we will need to add our criteria, that is, the name pattern that the
user supplied, using the addName() method on this object.
 Construct the UDDIApiInquiry object that we would use for placing the inquiry call.
 Finally, invoke the business inquiry operation through the find
 _business() method on the UDDIApiInquiry object. This method returns a
BusinessList object containing the BusinessInfo structures.
 Now, check whether the businesses are found matching the given criteria. If there are
matching businesses, we need to traverse through their BusinessInfo structures and
get hold of the name and key UUID of the business.
SearchBusiness.java Source Code
Listing 5.6 is the complete code listing of SearchBusiness.java.

package jws.ch5;

import org.idoox.uddi.client.api.v2.request.inquiry.*;
import org.idoox.uddi.client.structure.v2.tmodel.*;
import org.idoox.uddi.client.structure.v2.base.*;

import org.idoox.uddi.client.api.v2.response.*;
import org.idoox.uddi.client.structure.v2.business.*;
import org.idoox.uddi.client.api.v2.*;

import org.idoox.uddi.*;

public class SearchBusiness

{
public static void main(String args[]) throws Exception
{
if (args.length != 1)
{
printUsage();
}
else
{
String sNameOfBusiness = args[0];

// Invoke the search operation doSearch(sNameOfBusiness);

}
}

private static void printUsage()

{
System.err.println(“\nUsage: java jws.ch5.SearchBusiness
<BusinessNamePattern>”);

System.err.println(“\nwhere <BusinessNamePattern> represents

name of the business you want to search.”);
}

public static void doSearch(String sNameOfBusiness) throws

Exception
{
// Create a FindBusiness object
FindBusiness objFindBusiness = new FindBusiness();

// Send the find criteria objFindBusiness.addName(new

Name(sNameOfBusiness));

// Set the maximum number of rows to return

objFindBusiness.setMaxRows(new MaxRows(“10”));

// Get hold of UDDILookup object to place the query

UDDIApiInquiry objUDDIApiInquiry =
UDDILookup.getInquiry(“http://www.systinet.com:80/
wasp/uddi/inquiry/”);

// Invoke the query on the UDDI Inquiry API BusinessList

objBusinessList=
objUDDIApiInquiry.find_business(objFindBusiness);

// Check whether anything was found matching the

Listing 5.6 SearchBusiness.java. (continued)

// criteria
if (objBusinessList==null)
{
System.err.println(“No businesses were found matching the
criteria.”);
}
else
{
// Get hold of the BusinessInfo objects,
// contained by BusinessList BusinessInfos objBusinessInfos =
objBusinessList.getBusinessInfos();

System.out.println(“\n” + objBusinessInfos.size() +
“ businesses found matching the criteria...\n”);

BusinessInfo objBusinessInfo = objBusinessInfos.getFirst();

BusinessKey objBusinessKey; if (objBusinessInfo != null)
{
objBusinessKey=objBusinessInfo. getBusinessKey();

// Traverse through the results. while (objBusinessInfo!=null)

{
System.out.println(“Business Name = “ +
objBusinessInfo.getNames(). getFirst().getValue());

System.out.println(“Business UUID = “ +
objBusinessInfo.getBusinessKey());

System.out.println(“----------------
---------------------------------”);

// Next BusinessInfo objBusinessInfo =

objBusinessInfos.getNext();
}
}
}
}
}

Compiling and Executing SearchBusiness.java

The following command line instruction compiles SearchBusiness
.java:

>javac jws/ch5/SearchBusiness.java

The following command line instruction executes SearchBusiness

.java in order to search for businesses with names starting with a ‘A’:

>java -classpath %CLASSPATH%;. jws.ch5.SearchBusiness A

Figure 5.8 shows the output of this execution.
As can be seen from the output in Figure 5.8, ACME Computer Services is one of the
businesses that matched our search criteria.

Deleting Information from a UDDI Registry

DeleteBusiness.java demonstrates how to delete a business from the UDDI registry based
on its key UUID, which is passed by the user as a com- mand line argument. You can get
hold of the business key either by brows- ing the Systinet registry on the Web or by
executing SearchBusiness. In the coming sections, we will examine the source code of
DeleteBusiness
.java, followed by its compilation and execution.

Figure 5.8 Executing SearchBusiness.java.

Programming Steps for Deleting

The deletion logic is provided by the doDelete() method of the jws.ch5.DeleteBusiness
class, and hence, its implementation is of most interest to us. The following are the steps
to implementing doDelete():
 1.Construct the UDDIApiPublishing object. This is the object that we would use to
actually delete information from the registry.
 2.Get hold of the authentication token from the registry with the help of the
get_authToken() API call on the UDDIApiPublishing object. Once we have a valid
authentication token, we should be able to delete from the registry.
 3.Now, get hold of the DeleteBusiness object. This object represents a collection of
businesses that we wish to delete at a time. Hence, we will need to add businesses
referenced through BusinessKey to this object, using the addBusinessKey() method
on DeleteBusiness.
 4.Now, delete the business information through the delete_busi- ness() call on the
UDDIApiPublishing object. This method call takes the DeleteBusiness object as an
argument and returns the DispositonReport object upon completion.
 5.Check the DispositionReport object to see if this operation was a success or a failure.

DeleteBusiness.java Source Code

Listing 5.7 is the complete code listing of DeleteBusiness.java.

package jws.ch5;

import org.idoox.uddi.*;
import org.idoox.uddi.client.api.v2.*;
import org.idoox.uddi.client.api.v2.request.publishing.*;
import org.idoox.uddi.client.api.v2.response.*;
import org.idoox.uddi.client.structure.v2.business.*;

public class DeleteBusiness

{
public static void main(String args[]) throws Exception
{
if (args.length != 1)
{
printUsage();
}
else
{
BusinessKey objBusinessKey = new BusinessKey (args[0]);

doDelete(objBusinessKey);
}
}

private static void printUsage()

{
System.err.println(“\nUsage: java jws.ch5.DeleteBusiness
<BusinessKey>”);

System.err.println(“\nwhere <BusinessKey> is a string representation

of UUID corresponding to Business you want to delete.”);
}

public static void doDelete(BusinessKey objBusinessKey) throws

Exception
{
System.out.println(“\nDeleting Business with Key: “);
System.out.println(objBusinessKey.toString());

UDDIApiPublishing objUDDIApiPublishing =
UDDILookup.getPublishing(“ https://www.systinet.com:443/wasp/uddi/pu
blishing/”);

// First we get hold of Authentication token from the

// Registry so that we can delete
// business from the UDDI Registry. Note that
// registered a user in Systinet Publich Registry
// with registry_user ID and registry_user password.

AuthToken objAuthToken = objUDDIApiPublishing. get_authToken(new

GetAuthToken(
new UserID(“registry_user”), new Cred(“registry_user”)));

// Now get hold of the DeleteBusiness structure

org.idoox.uddi.client.api.v2.request. publishing.DeleteBusiness
objDeleteBusiness =

Listing 5.7 DeleteBusiness.java. (continues)

new org.idoox.uddi.client.api.v2.request.
publishing.DeleteBusiness();

// Set the login information on DeleteBusiness

objDeleteBusiness.setAuthInfo
(objAuthToken.getAuthInfo());

// Add business to delete to the DeleteBusiness

// Structure
objDeleteBusiness.addBusinessKey(objBusinessKey);

// Call Publishing API method delete_business

DispositionReport objDispositionReport =
objUDDIApiPublishing.delete_business
(objDeleteBusiness);

// Discard the Authentication token now

objUDDIApiPublishing.discard_authToken
(new DiscardAuthToken(objAuthToken.getAuthInfo()));

// Check to see if the delete operation was

// successful
if (objDispositionReport == null)
{
System.err.println(“Unsuccessful in deleting
the business information from the registry.”);
}
else
{
if (objDispositionReport.
resultIs(UDDIErrorCodes.E_SUCCESS))
{
System.out.println(“\nSuccessful in
deleting the business information from the
registry.”);
}
else
{
System.out.println(“\nUnsuccessful in
deleting the business information due to
following reason(s):”);

System.out.println(
objDispositionReport.toXML());
}
}
}
}
Compiling and Executing SearchBusiness.java
The following command line instruction compiles DeleteBusiness
.java:

>javac jws/ch5/DeleteBusiness.java

The following command line instruction executes DeleteBusiness

.java in order to delete the ACME Computer Services business corre- sponding to the key
‘fe4b2d70-9988-11d6-9917-b8a03c50a862’.

>java -classpath %CLASSPATH%;. jws.ch5.DeleteBusiness fe4b2d70-9988-11d6-9917-

b8a03c50a862

Figure 5.9 shows the output of this execution.

Deletion of ACME Computer Services can be verified either by visiting the Systinet public registry
or by executing SearchBusiness.

Figure 5.9 Executing DeleteBusiness.java.

Limitations of UDDI

UDDI is an evolving standard. Currently, the most deployed version of UDDI (2.0) is limiting in
terms of the information model that it supports, especially when compared to other registry
specifications such as ebXML Registry/Repository. UDDI provides support for storing only the
basic data structures, such as businesses, users, services, and service technical descriptions.
However, storing information about business Web services requires more than just the basic
support. For example, potential users of business Web services should be able to publish/query
extensive business- oriented information, such as the business process models that a particular
business Web service relies upon. This is possible only if the target registry provides a data
structure representing the business process model. Thus, an information model is an important
feature for any registry. Registry information model, are further discussed in Chapter 11, “Java
API for XML Registries.”
Also, UDDI is just a registry as opposed to ebXML Registry/Repository, which is, as the name
suggests, a registry as well as repository. The basic difference between a registry and repository is
that a registry holds just the metadata of the objects submitted, whereas a repository actually
stores the submitted objects.
UNIT-5
Web Services Interoperability

Means of Ensuring Interoperability

A Web services environment, the Simple Object Access Protocol, or SOAP, is the de facto standard
communication protocol. (For more on SOAP, see the section titled Simple Object Access Protocol
in Chapter 4, “Developing Web Services Using SOAP.”) This protocol provides conven- tions for
representing data and application interaction models like remote procedural calls (RPCs) and
messaging. This facilitates inter-application communication and seamless data sharing among
applications residing on a network, regardless of their native language implementation, operating
systems, hardware platforms, and the like. In turn, it also enables the development of compatible
Web services by leveraging interoperability among business applications running across a wide
range of systems and devices.
Interoperability in Web services becomes a real challenge when a service requestor finds
problems while invoking a method in the service provider environment or when it does not
understand a message sent by the service provider. This is usually caused by prerequisites and
factors exposed by the service provider or service requestor environments, and it is mostly
caused by the dependencies of the underlying SOAP runtime provider implementation. Thus, it
becomes essential for Web services offered by a service provider to ensure that the services are
usable by a variety of service requestor clients to the best possible accommodation of both con-
forming and non-conforming SOAP implementations. Different ways exist to ensure service
requestor interoperability with the service providers.
Declaring W3C XML Schemas
Defining W3C XML Schema Definitions (XSD) and target name spaces for all the application data
types and having a supporting SOAP implementation for both the service provider and service
requestor resolves almost all interoperability issues specific to the data types. This helps to create
com- pliant SOAP proxy-based clients for the service requestors with all the defined data types by
providing automatic encoding and mapping for the service provider-dispensed XSD data types.

Exposing WSDL
Most Web services platforms and SOAP implementations provide this as an automatic mechanism
by delivering WSDL for all its exposed services. The exposed WSDL defines the service provider
information and service specific parameters required by a service requestor for invoking the ser-
vices, which enables the building service clients to interact with the service provider, thus
ensuring interoperability based on the WSDL. The service clients also can be dynamically
generated from a service provider’s WSDL lookup. In such cases, the SOAP client runtime
implementation must pro- vide those dynamic invocation services.
Creating SOAP Proxies
For a Web service, the client SOAP proxies can be created manually or can be generated
dynamically based on the WSDL provided details of the service provider. In the automatic
generation of SOAP proxies, sometimes they may throw SOAP faults during service invocation and
may require some modifications in the SOAP headers or the encoded RPC calls. In most cases, this
problem occurs due to non-conforming WSDL and SOAP implementation in the infrastructure of
the service provider or requestor.

Testing Interoperability
To ensure that interoperability between the service provider and requestor exists, the underlying
SOAP implementations also can be tested. In that case, the SOAP implementations of the service
provider and the requestor must agree and conform to the following SOAP-specific dependencies:
■■ The defined SOAP transport protocol bindings (like http)
■■ The supported version of SOAP (like SOAP 1.1 or SOAP 1.2)
■■ The version of WSDL from the service provider and its ability to support by the service
requestor client
■■ The version of W3C XML Schema supported by the SOAP message, especially the SOAP
envelope and its body elements
Most Web services platforms and SOAP implementation providers test their products among
SOAP implementations using a standard test suite. This suite can be used to ensure
interoperability with other SOAP imple- mentations for conformance testing.
To explore the concepts, let’s experiment with an interoperability sce- nario using a Java-based
Web services implementation to interact with a Microsoft-based service client implementation. To
try out this scenario, we have chosen to use Apache Axis as the Java-based Web services provider
and the Microsoft .NET Framework as the client Web services requestor.The development and
deployment of a Web services requestor is done in a unique part of the Microsoft .NET platform.
Like any other Web services platform providers, the Microsoft .NET Framework typically supports
industry-standard protocols and technologies, including XML, SOAP, WSDL, and UDDI.

Overview of .NET
Microsoft .NET is part of the Microsoft .NET platform—Microsoft’s strategy for developing
distributed applications through XML Web services. The Microsoft .NET Framework provides a
full-fledged development environ- ment for developing XML Web services in a Microsoft
Windows–based environment. It facilitates a runtime infrastructure and APIs for developing Web
services applications using a variety of object-oriented programming languages such as C#, Visual
Basic, and so forth. The .NET Framework pro- vides the infrastructure for defining the
overall .NET platform. Microsoft provides .NET compilers that generate a new code referred to as
Microsoft Intermediate Language (MSIL). MSIL is a CPU-independent code instruc- tion, which is
able to run on any system supporting its native machine language. The .NET compilers provided
by Microsoft are as follows:
■■ VB.NET (Visual Basic for .NET)
■■ C++ .NET (Visual C++ for .NET)
■■ ASP.NET (Microsoft ASP for .NET)
■■ C# .NET (New language for .NET)
■■ JScript (Jscript for .NET)
The Microsoft .NET Framework consists of two core components
Common Language Runtime (CLR)
The Common Language Runtime, or CLR, provides a managed runtime environment (.NET Engine)
for the .NET Framework. CLR enables appli- cations to install and execute code, and it provides
services such as mem- ory management, including garbage collection, threading, exception
handling, deployment support, application runtime security, versioning, and so on.
CLR provides a set of JIT (just-in-time) compilers, which compile MSIL to produce native code
specific to the target system. CLR defines a set of rules as Common Type System (CTS) and
Common Language System (CLS) that specifies the .NET-supported languages required to use for
developing compilers supporting a .NET platform. This enables the com- piler vendors to
develop .NET-compliant compilers and to perform cross- language integration. Cross language
integration enables .NET-compliant languages to run and interact with one another in a .NET
environment.

.NET Framework Class Library

The .NET Framework class library acts as the base class library of the .NET Framework. It
provides a collection of classes and a type system as founda- tion classes for .NET to facilitate CLR.
It is included as part of the .NET Framework SDK. The class libraries are reusable object-oriented
classes that support .NET programming tasks like establishing database connectivity, data
collection, file access, and so on. The class libraries also support the rapid development of
software applications such as the following:
■■ Console applications
■■ Windows GUI applications
■■ Windows services
■■ ASP .NET applications
■■ .NET XML Web services
■■ .NET Scripting applications
■■ .NET Client applications
The .NET class libraries can work with any CLS-compliant language and can use CLR. At the time
of this book’s writing, the supported languages include Microsoft Visual Studio .NET, C#, and
ASP.NET.
Microsoft initially released their .NET Framework to support a Windows- based environment only,
although Microsoft will be making .NET available in other platforms. For more information on the
Microsoft .NET Frame- work, go to the Web site: http://msdn.microsoft.com/netframework/. To
download the Microsoft .NET Framework SDK, go to the Web site:
http://msdn .microsoft.com/net/.
To fully understand the interoperability scenario between Java-based Web services and the
Microsoft .NET client environment, you need to understand the process model of developing
Microsoft .NET clients.

Creating a .NET Client for Axis Web Services

For the service provider, we will be creating Apache Axis-based Web ser- vice components using
Java for the service provider and for the client ser- vice requestor we will implement .NET-based
client components using the
.NET Framework. To cater the Acme product catalog service scenario, we will be using an RPC-
based communication model between the Apache Axis-based Web services and the .NET-based
service requestor. We will be reusing the ACME business specific components as discussed in
Chapter 3, “Building the Web Services Architecture.” The ACME components to han- dle this
scenario are as follows:
■■ AcmeDAO. A DAO class that provides access to the data source and abstracts the
underlying data access implementation for the product catalog
■■ AcmeXMLHelper. A class that gathers the data and constructs an XML document as a
string for use by the business clients
To find out the programming steps and the source code implementation of the previous classes,
refer to Chapter 3, particularly the section titled Developing Web Services Using J2EE: An Example.
To try out the example, you may download the chapter-specific code and documentation made
available at www.wiley.com/compbooks/nagappan. Source code and README text for installing
and running this example are available as part of Chapter-6.zip.
Building the Infrastructure
To build and deploy ACME Web services in the Axis environment, we chose to use the following
infrastructure solutions:

ON THE SERVICE PROVIDER SIDE

■■ ACME Web services provider will use Apache Tomcat as its servlet engine/Web server,
including Axis-based SOAP runtime environment
■■ Will use PointBase as its database for querying product catalog information

ON THE SERVICE REQUESTOR SIDE

■■ Service requestor will use the .NET Framework as its SOAP client environment to invoke
the services of the ACME Web services provider
Microsoft.NET Apache TOMCAT w/Axis
Framework
Java
.NET Components
Common .NET SOAP Web Axis Web
Runtime Clients Services Services
Environment Environment
Resources

PointBase

Figure 6.1 Apache Axis and Microsoft .NET-based Web services infrastructure.
Figure 6.1 represents the Web services infrastructure involving Apache Axis and the Microsoft .NET
Framework.
To understand the problem and flow of events, the sequence diagram in Figure 6.2 illustrates the various
sequences of actions performed by a .NET client invoking the ACME Web services deployed in the Axis-
based Web services environment.
Based on the previous sequence of events, we have chosen to use an AcmeXMLHelper class to act as a proxy
by encapsulating the business functionalities, which include database interaction, XML construction, XML
parsing operations, and so forth. More specifically, the AcmeXML- Helper class will handle all of the XML
construction tasks and AcmeDAO will handle the database interaction.
Figure 6.3 depicts the class diagram of the server-side components to sup- port the ACME Web service
provider using the Apache Axis infrastructure. To try out this example, download the chapter-specific
source code and documentation available at www.wiley.com/compbooks/nagappan. The source code and
README text for installing and running this example are
available as part of chapter-6.zip.
Now, let’s take a look at how to set up the development environment and implementation of those service
components.
.NETServiceRequestor Axis Service provider environment

AcmeProductCatalogClient AcmeProductCatalog AcmeXMLHelper AcmeDAO ACME ACME

ValueObject Database

Send Request for Call business methods

ACME Product for product Catalog Call DAO to Query ACME product
Catalog deliver data tables

Return ACME
Product catalog data

Create ACME
Value object

Return Data Return ACME

as ACME Value object
Value objects
Return Data
as XML String
Send Response
ACME Product
Catalog
as XML string

Figure 6.2 Sequence diagram representing the scenario.

Figure 6.3 Class diagram illustrating the service provider components.

Setting Up the Environment

To set up the development environment for creating ACME Web services, perform the following
tasks:
 Create the service provider environment.
a. Refer to Chapter 4, ”Developing Web Services Using SOAP,” in the section titled Setting
Up the Axis Web Services Environment, and follow Steps 1 to 11.
 Create the service requestor environment.
a. Download the Microsoft .NET Framework SDK (current release) from
http://msdn.microsoft.com/net and install the application to your local directory. The
installation process will update your system path, and all of the .NET Framework utilities
will be ready to use.
b. Create a working directory (for example, d:\msdotnetclient) to create and test the .NET
client applications.
These steps conclude the configuration requirements for the service provider and requestor
environment. Now, let’s explore the implementa- tion of the ACME business scenarios by using
them.

Creating the Service Provider (Axis Environment)

As was mentioned earlier, to implement the service provider environment, we will be reusing the
components that we built in Chapter 3, “Building the Web Services Architecture,” and deploying
them in Axis environment. The components are as follows:
AcmeDAO. A
DAO class that provides access to the data source and abstracts the underlying data access
implementation for the product catalog.
AcmeXMLHelper. A
class that gathers the data and constructs an XML document as a string for use by the business
clients.
To find out the programming steps and the source code implementation of the previous classes
(AcmeDAO and AcmeXMLHelper), refer to Chap- ter 3, “Building the Web Services Architecture,”
particularly the section titled Developing Web Services Using J2EE: An Example.
As we discussed in Chapter 4, Axis enables Web services to be deployed using Java classes
with .jws extensions. It is quite typical to the Java Server Pages (JSP) deployed in a servlet engine.
By placing Java classes with .jws extensions in the Web applications directory (that is,
TOMCAT_HOME/webapps/axis/) during runtime, the runtime of Axis automatically com- piles
and deploys the classes with all of the methods as services.

We will be creating the Acme product catalog service as ACMEProduct Catalog.jws, which will be
acting as the service provider in the Axis environment.
The ACMEProductCatalog.jws class uses AcmeXMLHelper and AcmeDAO as helper classes for XML
processing and database interaction. The ACMEProductCatalog.jws then will be deployed in the
Axis envi- ronment as an Axis JWS service.
Now, let’s take a closer look at the implementation and walk through the code of
ACMEProductCatalog.jws .
Implementing the Service Provider (ACMEProductCatalog.jws)
The source code implementation for ACMEProductCatalog.jws is shown in Listing 6.1.

// AcmeProductCatalog.jws

import jws.ch4.xmlhelper.AcmeXMLHelper;

public class AcmeProductCatalog

{ String pc;

// Helper function: To obtain Product Catalog it calls

// AcmeXMLhelper method

public String getProductCatalog() throws Exception {

AcmeXMLHelper axh;

try {
// Instantiate the AcmeXMLhelper
axh = new AcmeXMLHelper();

// Call method
pc = axh.getProductCatalogXMLasString();
} catch (Exception e)
{ e.printStackTrace();
}
// Return the response string
return pc;
}
}

Listing 6.1 ACMEProductCatalog.jws.

Figure 6.4 WSDL output for ACMEProductCatalog.jws.

To deploy AcmeProductCatalog.jws, just copy the source file in your Apache Axis Web
applications directory (that is, TOMCAT_HOME
/webapps/axis/). If your Tomcat server is not running, then start your Tom- cat server.
The Apache Axis environment will automatically deploy them as a service and emit the
ACME product catalog service details as WSDL. To access the WSDL, use your Web
browser and then try out the following URL:
http://localhost:8080/axis/AcmeProductCatalog.jws?WSDL
If everything works successfully, you will get the output shown in Figure 6.4.
This summarizes the service provider environment using Apache Axis.
Creating the Service Requestor (.NET Environment)
The following steps are involved using the .NET Framework to access the ACME product
catalog service requestor.

Obtaining the WSDL of Acme Product Catalog Service

The first step is to locate the ACME service provider and obtain its WSDL. It will be
available to the service requestor as an URL. In our case, it will be as follows:
http://localhost:8080/axis/AcmeProductCatalog.jws?WSDL

Figure 6.5 Creation of the Proxy C# class.

Generating a Proxy for the Web Service

The next step is to use the WSDL.exe utility to generate proxy client classes from the
ACME service provider WSDL. To create the proxy client classes, run the following
command from your Windows command prompt (in a single line):

wsdl.exe /l:CS
/protocol:SOAP http://localhost:8080/axis/AcmeProductCatalog?WSDL
/out:AcmeServiceClient.cs

This command creates AcmeServiceClient.cs as a proxy class for the ACME product
catalog service, as shown in Figure 6.5.
Listing 6.2 shows the generated C# source code.
//
// This source code was auto-generated by wsdl, Version=1.0.3705.0.
//
using System.Diagnostics;
using System.Xml.Serialization;
using System;
using System.Web.Services.Protocols;
using System.ComponentModel;
using System.Web.Services;

[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute(“code”)]
[System.Web.Services.WebServiceBindingAttribute(
Name=”AcmeProductCatalogSoapBinding”,
Namespace=”http://localhost:8080/axis/AcmeProductCatalog.jws”)] public
class AcmeProductCatalogService :
System.Web.Services.Protocols.SoapHttpClientProtocol {

public AcmeProductCatalogService() { this.Url =

“http://localhost:8080/axis/AcmeProductCatalog.jws”;
}

[System.Web.Services.Protocols.SoapRpcMethodAttribute (“”,
RequestNamespace=”getProductCatalog”,
ResponseNamespace=
“http://localhost:8080/axis/AcmeProductCatalog.jws”)]
[return:
System.Xml.Serialization.SoapElementAttribute(“return”)] public string
getProductCatalog() {
object[] results = this.Invoke
(“getProductCatalog”, new object[0]); return ((string)(results[0]));
}

public System.IAsyncResult BegingetProductCatalog

(System.AsyncCallback callback, object asyncState) {
return this.BeginInvoke(“getProductCatalog”,
new object[0], callback, asyncState);
}

public string EndgetProductCatalog

(System.IAsyncResult asyncResult) { object[] results =
this.EndInvoke(asyncResult); return ((string)(results[0]));
}
}

Compiling the SOAP Proxy as a DLL

The next step is to use the .NET C# compiler csc.exe to build an assem- bly DLL from the
generated proxy source code. To compile the AcmeSer- viceClient.cs, run the following
command from your Windows command prompt (in a single line):

Figure 6.6 Creation of a DLL library for the proxy class.

csc.exe /t:library
/r:System.Web.Services.dll
/r:System.Xml.dll AcmeServiceClient.cs

This command creates a DLL library file which acts as a proxy stub class for the client, as shown in Figure
6.6.

Creating a .NET Client Application

Next, create a .NET client application using the instances of proxy classes and its methods. (The available
proxy instances and the service methods can be read from the proxy source code.) The .NET client
application source code AcmeServiceClientApp.cs using C# code is shown in Listing 6.3.
Listing 6.3 .NET client application source code, AcmeServiceClientApp.cs. (continued)
Compiling the Client Application
The next step is to create an executable client application and to compile the client source code
AcmeServiceClientApp.cs. To compile the client application, run the following command from your
Windows com- mand prompt (in a single line):

csc.exe /r:AcmeServiceClient.dll
/t:exe
/out:AcmeServiceClientApp.exe AcmeServiceClientApp.cs

This command creates AcmeServiceClientApp.exe, which is an executable .NET client application file that
invokes the ACME service provider, as shown in Figure 6.7.

using System;
namespace AcmeServiceClient {
public class AcmeServiceClientApp {

public AcmeServiceClientApp() {
}
public static void Main () {

// Create a proxy instance AcmeProductCatalogService server

= new AcmeProductCatalogService();

// Invoke getProductCatalog method and

// get the XML as String
string catalog = server.getProductCatalog ();

// Print the Acme Product Catalog

Console.WriteLine (“The ACME Product Catalog :”+catalog);
}
}
}

Listing 6.3 .NET client application source code, AcmeServiceClientApp.cs.

Compiling the Client Application
The next step is to create an executable client application and to compile the client source
code AcmeServiceClientApp.cs. To compile the client application, run the following
command from your Windows com- mand prompt (in a single line):
csc.exe /r:AcmeServiceClient.dll
/t:exe
/out:AcmeServiceClientApp.exe AcmeServiceClientApp.cs

This command creates AcmeServiceClientApp.exe, which is an executable .NET client

application file that invokes the ACME service provider, as shown in Figure 6.7.

Figure 6.7 The compilation of a client application.

Figure 6.8 Invocation of service from an ACME service provider.

Execute and Test the .NET Client from a Windows Environment

Finally, to invoke the ACME product catalog from the ACME service provider (Axis
environment), run the .NET client application AcmeSer- viceClientApp.exe from the
command prompt.
If everything works successfully, you will get the output shown in Figure 6.8.
This summarizes our Web service interoperability example scenario involving Apache
Axis-based Java Web services and the Microsoft .NET Framework.

Challenges in Web Services Interoperability

The challenges that affect interoperability in Web services will be exam- ined in the
following sections.
Common SOAP/HTTP Transport Issues
At the core of Web services, the transport protocols establish the communi- cation and
enable the services to send and receive messages. In case of using HTTP protocol, if the
service provider requires a SOAPAction with a null value, most HTTP clients may not be
able to provide a SOAPAction with a null value. The possible solutions are to fix the
service client APIs and to ensure that certain service provider implementations require
SOAP- Action with a null value. To solve these problems, test the client to see if they can
handle those scenarios.
XML Schema- and XML-Related Issues
XML schema validation handling causes a lot of interoperability issues among SOAP
implementations. So defining data types using XMS schema definitions must occur in both
the service client and provider implementations.
Some SOAP implementations specify the encoding of data as UTF-8 and UTF-16 in the
Content-Type header as

Content-Type: text/xml; charset=utf-8

And some implementations do not specify the charset in the Content- Type header, which
causes some SOAP implementations to be unable to process messages. To correct this
problem, ensure that the SOAP implemen- tation and its encoding standards are
compliant with the W3C specifications.
SOAP/XML Message Discontinuities
Message discontinuities cause a major problem between a SOAP imple- mentation in
fulfilling the request and response between the service client and service provider. To
overcome these issues, ensure that the application is aware of the message discontinuities
and throw SOAPFaults in the case of missing elements in the SOAPBody of the request
message.
Version and Compatibility
The version of the supported XMLSchema, and the SOAP and WSDL spec- ifications, and
its compatibility between SOAP implementations affect interoperability. To ensure that
these issues are handled, the Web services platform providers and its SOAP
implementations must be tested for the compatible versions of XML Schema definitions
and the SOAP and WSDL specifications.
The emergence of the WS-I initiative, which is examined in the next sec- tion, will address
these issues as part of its goals.

Web Services Security

XML Security FrameWork:

The following five most prominent technolo- gies in areas of XML security:
■■ XML Encryption
■■ XML Signature (XML DSIG)
■■ Security Assertions Markup Language (SAML, pronounced “sam-el”)
■■ XML Access Control Markup Language (XACML)
■■ XML Key Management Services (XKMS)
Goals of Cryptography:
Encryption and digital signatures are a part of a bigger science of cryptography.
Cryptography is the art of secret writing, the enciphering and deciphering of messages in
secret code or cipher, as many would put it.
Four Goals of Cryptography
So why do we need cryptography in software? The answer is to achieve four goals:
confidentiality, authentication, integrity, and non-repudiation. The following sections
discuss each of these goals.
Confidentiality
Confidentiality deals with ensuring that only authorized parties are able to understand
the data. Unauthorized parties may know that the data exists, but they should not be able
to understand what the data is. Thus, when the data is transmitted on the wire,
unauthorized parties can view the data by sniffing in between, but our data would still
remain confidential as long as the sniffers are unable to understand it.
Confidentiality is made possible through encryption. Encryption is the process of
converting a particular message into scrambled text, also known as ciphertext, by
applying some cryptographic algorithm and secret infor- mation. Cryptographic
algorithms are known as ciphers, and the pre- encrypted form of the message is known as
plaintext. Only people with secret information with which the ciphertext was generated
then would be able to unscramble or decrypt the message.
Authentication
Authentication ensures the identity of the party in a given security domain. Usually, this
involves having some sort of password or key through which the user would prove his or
her identity in a particular security domain. Authentication is extremely important for
services to be able to tell to whom all they are providing their services. Likewise, it is very
important for consumers of services, so that they know exactly with whom they are
interacting. Authentication forms the basis for authorization that deals with managing
access to protected resources by an authenticated user based on his or her policies.
Many approaches toward authentication are currently in use. Some of the widely used
ones are based on either keys, digital certificates, or passwords.
Integrity
Integrity is about protecting sensitive information from unauthorized modifications. In
the case of a message being transmitted on the wire, integrity ensures that the message
received by the recipient was the same message that was sent originally by the sender,
that the message has not been tampered with since it was sent.
Different hashing algorithms are used to generate a sort of a checksum to guarantee
integrity.
Non-repudiation
Repudiation is to refuse to accept something. Non-repudiation is a tech- nique in which
one party ensures that another party cannot repudiate, or cannot refuse to accept, a
certain act. Non-repudiation forms the basis of electronic commerce. For example, a
supplier of raw materials would want to ensure that the customer does not repudiate
later its placing of an order for materials!Digital signatures can be used to provide non-
repudiation in computer security systems.

Digital Signatures
A user can use a public/private key to sign a message. A digital signature is akin to its
physical counterpart, the handwritten signature, in that the sender digitally signs a
message so that the recipient can verify that the message really came from the sender.
Digital signatures also provide for an integrity check. That is, they ensure that the
message has not been tam- pered with after it was signed.
The process of digitally signing a message involves creating a hash for the message and
encrypting this hash using the sender’s private key. Finally, the message is sent with the
encrypted hash. On receiving the mes- sage and the encrypted hash, the recipient would
decrypt the hash using the sender’s public key. This confirms that the message arrived
from the sender and no one else (non-repudiation). Also, by re-computing the hash of the
arrived message and then comparing it with the decrypted hash, the recipient can verify
that the message has not been changed since it was signed (an integrity check).
Figure 13.3 depicts a scenario where Alice sends her digital signature along with the
message that she sends to Bob.
As can be seen from Figure 13.3, a digital signature does not involve encrypting the actual
message. The actual message is sent as is along with the encrypted hash that serves as the
digital signature. Thus, in order to protect the message from eavesdroppers while in
transit, anyone can either encrypt the message and then digitally sign it or they can
digitally sign the message first and then encrypt it. Either method should be usable. The
result is an encrypted message with an encrypted hash that only the intended recipient is
able to read. This scenario thus yields confidentiality, non-repudiation, as well as integrity
in communication.
Two popular algorithms for digital signatures are RSA and Digital Sig- nature Algorithm
(DSA). Support for both of these algorithms is provided in XML Encryption as well as XML
Signature specifications.

Figure 13.3 Digital signature example.

Digital Certificates
A key by itself does not contain any binding information, such as to whom the key
belongs to, who issued the key, and the period over which it is valid. Without this
supporting information, there is no way that one can link a particular key with its actual
owner. Digital certificates provide an exact means to describe this supporting information
that binds a user with a specific public key. Putting this into context in our Alice and Bob
exam- ple, if Alice wanted to get Bob’s public key to send him an encrypted mes- sage, she
would first get hold of Bob’s digital certificate that confirms Bob’s identity and contains
his public key.
Now this raises another issue: How can Alice be sure that she has retrieved Bob’s genuine
certificate and not that of his imposter? This is when Certificate Authority (CA) comes into
picture. The CA acts as a trusted third party for the certificates. A CA is supposed to verify
the iden- tity of an individual or business, before it issues a digital certificate. A CA
manages the process of certificate creation, issuance, and revocation. At the time of
certificate creation, a CA signs the digital certificate with its own private key. So now
when Alice receives Bob’s digital signature that has been digitally signed by a CA’s private
key, she takes for granted that the identity of Bob has been verified by that CA and that
she is interacting with the genuine Bob and not some imposter.
A few big names in the CA business are Verisign, Thawte, Entrust, and Valicert. Also, the
current industry standard for digital certificates is X.509 from CCITT (stands for Commite’
Consultatif International de Telecom- munications et Telegraphy in French).
XML Encryption
The XML Encryption standard is currently been developed at the W3C. W3C officially
undertook the XML Encryption activity in late January 2001. At present, XML Encryption
is a Candidate Recommendation—that is, it has yet to become a W3C standard. (A
specification becomes an official W3C standard once it attains the W3C recommendation
status.)
XML Encryption forms the basis of Web services security. This technol- ogy is aimed at
defining the process of encrypting and decrypting digital content. XML Encryption is so
called because it uses XML syntax for repre- senting the content that has been encrypted
as well as for representing the information that enables the recipient of the encrypted
content to decrypt it. XML Encryption does not talk about other security issues such as
authentication, authorization, integrity, or trust, although it may form the basis for them.
The standard is completely centered on providing confi- dentiality to the information that
has been encrypted.

What XML Encryption Is

The need for an XML Encryption standard was conceived quite some time after the XML
Signature Working Group was formed. XML Signature was entirely focused on expressing
digital signatures in XML, and hence, pre- cluded any work on Encryption. People soon
realized that XML was becoming the language of the Web and that the industry would
need mechanisms for not only digitally signing XML entities but also for encrypting them.
This realization eventually led to the formation of the W3C XML Encryption Working
Group.
Secure Sockets Layer (SSL), developed by Netscape Communications, and Transport
Layer Security (TLS), from Internet Engineering Task Force (IETF), are the two protocols
that are used typically for transmitting encrypted data apart from providing
authentication using digital certifi- cates over TCP/IP. Now XML Encryption is not a
replacement to SSL/TLS. Rather, it is focused on providing a feature set that is not
provided by SSL/TLS presently. XML Encryption enables the encryption of data at dif-
ferent granularity levels. This means that one can select to encrypt parts of data using
XML Encryption. For example, within a particular XML docu- ment, one can select to
encrypt only a specific XML document element while leaving the rest of the document as it
is. This is unlike SSL/TLS, wherein entire groups of data have to be encrypted in order to
transport the data through an SSL/TLS channel. This leads us to encrypt even the
information that is not security sensitive. Encryption, as it stands, is com- paratively an
expensive operation and thus should be used judiciously.
Another added value that XML Encryption provides is that it enables the establishment of
secure sessions with more than one party. Also, XML Encryption can be used to encrypt
both XML as well as non-XML data just like general encryption done using, say, SSL/TLS.
To understand XML Encryption better, let’s take a look at the following use case. Consider
a transaction that involves three parties: the buyer, the vendor, and the bank. The buyer,
Bob, makes a purchase of certain goods at the vendor, Sue Company’s Web site, and
agrees to pay Sue Company

"I (Bob) agree to pay Sue Co. $5000 for

100 covers through <EncryptedData>"
Sue Co.

Figure 13.4 Bob encrypts his American Bank account number.

$5,000 in return. In order to make the purchase, Bob supplies all the rele- vant
information to Sue Company. This information also consists of Bob’s American Bank
account number, which is obviously a sensitive piece of information. As a result, before
Bob puts this information on the wire, he needs to ensure that he has encrypted it. Now
based on what Bob wants to encrypt, he can either use SSL/TLS or XML Encryption. For
example, if Bob wants to encrypt the entire information, he can very well use SSL/TLS.
However, if he just wants to keep the account number confidential, then he would want to
use XML Encryption to encrypt just that particular piece of information. This use case
scenario is illustrated in Figure 13.4.
Once Sue Company had received the purchase order from Bob, it would need to debit the
amount for that particular sale from Bob’s American Bank account. As a result, Sue
Company would need to inform the American Bank to do so. Now, when Sue Company
passes this particular information to American Bank, it definitely needs to encrypt the
bank account number to keep it confidential from unintended recipients, such that only
the American Bank can decrypt it. However, Sue Company also may want to encrypt the
information about the specific purchase (that is, that Bob pur- chased 100 covers), such
that American Bank cannot decrypt it. The reason that the Sue Company might want to do
this is because of privacy con- cerns: American Bank does not need to know what specific
purchase Bob made. And that is where XML Encryption can play its role. Using XML
Encryption technology, the Sue Company can encrypt different pieces of data with
different keys so that the recipient can decrypt and thus read only the piece of data that it
is supposed to. This scenario is illustrated in Figure 13.5.
Bob purchased <EncryptedData> from us and
agrees to pay $5000 in turn using his American
Bank account <EncryptedData>
Sue Co. American
Bank

Figure 13.5 Sue Company encrypts purchase information, not to be decrypted by

American Bank.

Implementations of XML Encryption

At the time of this book’s writing, the following implementations of XML Encryption are
available:
XML Security Suite from IBM (www.alphaworks.ibm.com/tech/ xmlsecuritysuite).
This toolkit consists of implementations for XML Signature, XML Encryption, and XML
Access Control Language (now part of the XACML effort).
XML Security Library, Aleksey Sanin (MIT License) (www.aleksey. com/xmlsec/).
This is a C library, and hence, practically of no use to Java developers. However, some old
C gurus can definitely find this useful. The library has implemented XML Encryption
Candidate Rec- ommendation, XML Signature Recommendation, Canonical XML v1.0 W3C
Recommendation, and Exclusive XML Canonicalization standards.
Trust Services Integration Kit (TSIK) from Verisign (www.
xmltrustcenter.org/developer/verisign/tsik/index.htm).
This toolkit provides extensive support for the XKMS standard. However, the support for
XML Encryption as well as XML Signatures is quite limited, as of this writing.
Phaos XML (www.phaos.com/e_security/prod_xml.html).
This toolkit provides a fairly complete implementation for XML Signature and XML
Encryption.