0% found this document useful (0 votes)

12 views110 pages

Web Services

The document discusses the evolution and emergence of web services, highlighting the transition from traditional distributed computing to modern web services enabled by technologies like J2EE and XML. It outlines the advantages of distributed computing, including higher performance, collaboration, and reduced costs, while also detailing various core technologies such as CORBA, Java RMI, and DCOM. Additionally, it addresses the limitations of these technologies and the role of Message-Oriented Middleware in facilitating asynchronous communication between applications.

Uploaded by

jonnada koushik

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

12 views110 pages

Web Services

Uploaded by

jonnada koushik

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 110

UNIT I

Evolution and Emergence of Web Services - Evolution of distributed computing, Core

distributed computing technologies, Challenges in Distributed Computing. Role of J2EE and
XML in distributed computing, emergence of Web Services.

Introduction to Web Services - The definition of web services, basic operational model of web
services, Core web services Standards, benefits and challenges of using web services.

Evolution of distributed computing

The Internet has revolutionized our business by providing an information highway, which acts as
a new form of communication backbone. To achieve this goal of obtaining an Internet business
presence, organizations are exposing and distributing their business applications over the Internet
by going through a series of technological innovations. The

key phenomenon of enabling business applications over the Internet is based on a fundamental
technology called distributed computing.

Distributed computing has been popular within local area networks for many years, and it took a
major step forward by adopting the Internet as its base platform and by supporting its open
standard-based technologies.

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.

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”.

Figure below 1.1 shows a distributed computing model that provides an infrastructure enabling
invocations of object functions located anywhere on the network. The objects are transparent to
the application and provide processing power as if they were local to the application calling
them.

Today, Sun Java RMI (Remote Method Invocation), OMG CORBA (Common Object Request
Broker Architecture), Microsoft DCOM (Distributed Component Object Model), and Message-
Oriented Middleware(MOM) have emerged as the most common distributed computing
technologies. These technologies, although different in their basic architectural design and
implementation, address specific problems in their target environments

The 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 (re)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 developed by smaller development teams in
isolation.

Reuse.:The distributed components may perform various services that can potentially be used by
multiple client applications. It saves repetitive development effort and improves interoperability
between components.

Reduced cost: Because this model provides a lot of reuse of once developed components that
are accessible over the network, significant cost reductions can be achieved.

Core distributed computing technologies are as the following:

• Client/server

• CORBA

• Java RMI

• Microsoft DCOM

• Message-Oriented Middleware

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.

Server: the server in a client/server application model is a database server that is mainly
responsible for the organization and retrieval of data.
Client: 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

limitations of the client-server application model:

• Complex business processing at the client side demands robust client systems.
• Security is more difficult to implement because the
algorithms and logic reside on the client side making it more
vulnerable to hacking.
• Increased network bandwidth is needed to
accommodate many calls to the server, which can
impose scalability restrictions.
• Maintenance and upgrades of client applications are
extremely difficult because each client has to be maintained
separately.
• Client-server architecture suits mostly database-oriented
standalone applications and does not target robust reusable
component oriented applications.
CORBA:

The Common Object Request Broker Architecture (CORBA) is an

industry wide, open standard initiative, developed by the Object
Management Group (OMG) for enabling distributed computing that
supports a wide range of application environments. OMG is a
nonprofit consortium responsible for the production and maintenance
of framework specifications for distributed and interoperable object-
oriented systems.

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).

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.

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.

Figure 1.3 illustrates the architectural model of CORBA with an.

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 can be specified in a
standard definition language supported by the CORBA ORB.

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.

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 as objects on the
ORB.
Rich distributed object infrastructure. CORBA offers developers a rich set of distributed
object services, such as the Lifecycle, Events, Naming, Transactions, and Security services.

Location transparency. CORBA provides location transparency: An object reference is

independent of the physical location and application level location. This allows developers to
create CORBA-based systems where objects can be moved without modifying the underlying
applications.

Network transparency. By using the IIOP protocol, an ORB can interconnect with any ORB
located elsewhere on the network.

Remote callback support. CORBA allows objects to receive asynchronous event notification
from other objects.

Dynamic invocation interface. CORBA clients can both use static and dynamic methods
invocations. They either statically define their method invocations through stubs at compile time,
or have the opportunity to discover objects’ methods at runtime. With those advantages, some
key factors, which affected the success of CORBA evident while implementing CORBA-based
distributed applications, are as follows:

High initial investment. CORBA-based applications require huge investments in regard to

new training and the deployment of architecture, even for small-scale applications

Availability of CORBA services. The Object services specified by the OMG are still
lacking asimplementation products.

Scalability. Due to the tightly coupled nature of the connection oriented CORBAarchitecture,
very high scalability expected in enterprise applications may not be achieved

JAVA RMI
Java RMI was developed by Sun Microsystems as the standard mechanism to enable distributed
Java objects-based application development using the Java environment. RMI provides a
distributed Java application environment by calling remote Java objects and passing them as
arguments or return values. 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 Javaplatform 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 interprocess communication
protocol, enabling Java objects living in different Java Virtual Machines (VMs) to transparently
invoke one another’s methods. Because these VMs can be running on different computers
anywhere on the network, RMI enables object- oriented distributed computing. RMI also uses a
reference-counting garbage collection mechanism that keeps track of external live object
references to remote objects (live connections) using the virtual machine. 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 clientsand
remote objects. It intercepts client requests, passes invocation arguments, delegates invocation
requests to the RMI skeleton, and finally passes the return valuesof 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 application solution.

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
or serializable objects.

RMI stub. The RMI stub is the client proxy generated by the rmi compiler (rmic provided along
with Java developer kit—JDK) that encapsulates the network information of the server and
performs the delegation of the method invocation to the server. The stub also marshals the
method arguments and 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 retries,
which are unicast/multicast of the invocation requests. The transport layer actually provides the
networking infrastructure, which facilitates the actual data transfer during method invocations,
the passing of formal arguments, and the return of back execution results.

RMI skeleton. The RMI skeleton, which also is generated using the RMI compiler (rmic)
receives the invocation requests from the stub and processes the arguments (unmarshalling) and
delegates them to the RMI server. Upon successful method execution, it marshals the return
values and then passes them back to the RMI stub via the RMI infrastructure.

RMI server. The server is the Java remote object that implements the exposed interfaces and
executes the client requests. It receives 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.

Advantages of JAVA RMI:

Developing distributed applications in RMI is simpler than developing with Java sockets because
there is no need to design a protocol, which is a very complex task by itself. RMI is built over
TCP/IP sockets, but the added advantage is that it provides an object- oriented approach for
interprocess communications. Java RMI provides the Java programmers with an efficient,
transparent communication mechanism that frees them of all the application-level protocols
necessary to encode and decode messages for data exchange. RMI enables distributed resource
management, best processing power usage, and load balancing in a Java application model. RMI-
IIOP (RMI over IIOP) is a protocol that has been developed for enabling RMI applications to
interoperate with CORBA components.

Limitations of JAVA RMI:

• RMI is limited only to the Java platform. It does not provide language independence in
its distributed model as targeted by CORBA.

• RMI-based application architectures are tightly coupled because of the connection-

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

• RMI does not provide any specific session management support

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.

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 proxy on 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 of the common
limitations of DCOM:

■ Platform lock-in

■ State management

■ Scalability

■ Complex session management issues

Message Oriented Middleware (MOM):

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

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

In MOM-based architecture, applications interacting with its messaging infrastructure use

custom adapters. Client applications communicate with the underlying messaging infrastructure
using these adapters for sending and receiving messages. For reliable message delivery,
messages can be persisted in a database/file system as well.

Some of the widely known MOM-based technologies are SunONE Message Queue, IBM
MQSeries, TIBCO, SonicMQ, and Microsoft Messaging Queue (MSMQ). The Java Platform
provides a Java-based messaging API (JMS-Java Message Service), which is developed as part
of the Sun Java Community Process (JCP) and also is currently part of the J2EE 1.3
specifications. All the leading MOM vendors like SunONE, TIBCO, IBM, BEA, Talarian, Sonic,
Fiorano, and Spiritwave support the JMS specifications.

JMS provides Point-to-Point and Publish/Subscribe messaging models with the following
features:

■ Complete transactional capabilities

■ Reliable message delivery

■ Security

Some of the common challenges while implementing a MOM-based application environment

have been the following:
• Most of the standard MOM implementations have provided native APIs for
communication with their core infrastructure. This has affected the portability of applications
across such implementations and has led to a specific vendor lock-in.

• The MOM messages used for integrating applications are usually based upon a
proprietary message format without any standard compliance.

Challenges in Distributed Computing

some of the common challenges noticed in the CORBA-, RMI-,

and DCOM-baseddistributed computing solutions:

1. Maintenance of various versions of stubs/skeletons in the client and server environments

is extremely complex in a heterogeneous network environment.

2. Quality of Service (QoS) goals like Scalability, Performance, and Availability in a

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

3. Interoperability of applications implementing different protocols on heterogeneous

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

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

5. The biggest problem with application integration with this tightly coupled approach
spearheaded by CORBA, RMI, and DCOM was that it influenced separate sections of the
developer community who were already tied to specific platforms. Microsoft Windows
platform developers used DCOM, while UNIX developers used CORBA or RMI. There
was no big effort in the community to come up with common standards that focused
on the interoperability between these diverse protocols, thus ignoring the importance, and
hence, the real power of distributed computing.

Role of J2EE and XML in distributed computing

The first generation of Internet servers was based upon Web servers that hosted static Web pages
and provided content to the clients via HTTP (HyperText Transfer Protocol). HTTP is a stateless
protocol that connects Web browsers to Web servers, enabling the transportation of HTML
content to the user.With the high popularity and potential of this infrastructure, the push for a
more dynamic technology was inevitable. This was the beginning of server-side scripting using
technologies like CGI, NSAPI, and ISAPI.
With many organizations moving their businesses to the Internet, a whole new category of
business models like business-to-business (B2B) and business-to- consumer (B2C) came into
existence.This evolution lead to the specification of J2EE architecture, which promoted a much
more efficient platform for hosting Web-based applications. J2EE provides a programming
model based upon Web and business components that are managed by the J2EE application
server. The application server consists of many APIs and low-level services available to the
components. These low- level services provide security, transactions, connections and instance
pooling, and concurrency services, which enable a J2EE developer to focus primarily on
business logic rather than plumbing.

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
requests/responses, Session management, Device independent content delivery, and the
invocation of business tier components.

Application tier. The Application tier (also known as the Business tier) deals with the core
business logic processing, which may 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.
With its key functionalities and provisions for partitioning applications into logical tiers, J2EE
has been highly adopted as the standard solution for developing and deploying mission critical
Web-based applications. The power of J2EE-based applications would be tremendous, if it is
enabled to interoperate with other potential J2EE-deployed applications.

It also enables the realization of syndication and collaboration of business processes across the
Internet by enabling them to share data and component- level processes in real time. This
phenomenon is commonly referred to as business-to-business (B2B) communication.

The emergence of the Extensible Markup Language (XML) for defining portable data in a
structured and self-describing format is embraced by the industry as a communication medium
for electronic data exchange. Using XML as a data exchange mechanism between applications
promotes interoperability between applications and also enhances the scalability of the
underlying applications. Combining the potential of a J2EE platform and XML offers a standard
framework for B2B and inter-application communication across networks.

With J2EE enabling enterprise applications to the Internet and XML acting as a “glue” bridges
these discrete J2EE-based applications by facilitating them to interoperate with each other. XML,
with its incredible flexibility, also has been widely adopted and accepted as a standard by major
vendors in the IT industry, including Sun, IBM, Microsoft, Oracle, and HP. The combination of
these technologies offers more promising possibilities in the technology sector for providing a
new way of applicationto- application communication on the Internet. It also promotes a new
form of the distributed computing technology solution referred to as Web services.

The Emergence of Web Services:

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. This promising
new technology sets the strategic vision of the next generation of virtual business models and the
unlimited potential for organizations doing business collaboration and business process
management over the Internet. 1

Introduction to Web services:

Today, people use the Internet as an everyday service provider for reading headline news,
obtaining stock quotes, getting weather reports, shopping online, and paying bills, and also for
obtaining a variety of information from different sources. These Web-enabled applications are
built using different software applications to generate HTML, and their access is limited only
through an Internet browser or by using an application-specific client.

The emergence of Web services introduces a new paradigm for enabling the exchange of
information across the Internet based on open Internet standards and technologies. Using
industry standards, Web services encapsulate applications and publish them as services.

These services deliver XML-based data on the wire and expose it for use on the Internet, which
can be dynamically located, subscribed, and accessed using a wide range of computing
platforms, handheld devices, appliances, and so on. Due to the flexibility of using open standards
and protocols, it also facilitates Enterprise Application Integration (EAI), business- to-business
(B2B) integration, and application-to-application (A2A) communication across the Internet and
corporate intranet.

In organizations with heterogeneous applications and distributed application architectures, the

introduction of Web services standardizes the communication mechanism and enables
interoperability of applications based on different programming languages residing on different
platforms

Introduction to Web Services

The 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 “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.
Consider the simple example shown in Figure 2.1 where a travel reservation services provider
exposes its business applications as Web services supporting a variety of customers and
application clients. These business applications are provided by different travel organizations
residing at different networks and geographical locations.
The following is a typical scenario:

1. The Travel service provider deploys its Web services by exposing the business
applicationsobtained from different travel businesses like airlines, car-rental, hotel
accommodation, creditcard 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 services for performing travel reservations
and other functions over the Internet using any platform or device

4. In the case of large-scale organizations, the business applications consume these Web
services for providing travel services to their own employees through the corporate
intranet.

5. Web services are typically implemented based on open standards and technologies
specifically leveraging XML. The XML-based standards and technologies, such as
Simple Object Access Protocol (SOAP); Universal Description, Discovery, and
Integration (UDDI);Web Services Definition Language (WSDL); and Electronic
Business XML (ebXML), are commonly used as building blocks for Web services.

Motivation and Characteristics:

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.

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, and conduct business transactions
using a lightweight infrastructure by adopting an XML-based data exchange format and industry
standard delivery protocols.

The basic characteristics of a Web services application model are as follows:

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

2. Web services provide a cross-platform integration of business applications over the

Internet.

3. 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.

4. 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.
5. Because Web services are based on loosely coupled application components, each
component is exposed as a service with its unique functionality.

6. Web services use industry-standard protocols like HTTP, and they can be easily
accessiblethrough corporate firewalls.

7. Web services can be used by many types of clients.

8. Web services vary in functionality from a simple request to a complex business

transactioninvolving multiple resources.

9. All platforms including J2EE, CORBA, and Microsoft .NET provide extensive support
forcreating and deploying Web services.

10. Web services are dynamically located and invoked from public and private registries
basedon industry standards such as UDDI and ebXML.

Why to Use Web services:

Traditionally, Web applications enable interaction between an end user and a Web site, while
Web services are service-oriented and enable applicationto- 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 developin and deploying the Web
services. The provider also defines the service and publishes them with the service broker.

Service broker. The service broker (also commonly referred to as service registry) is
responsible for service registration and discover of the Web services. The broker lists the various
service types descriptions, and locations of the services that help the service requesters find and
subscribe to the required services.

Service requestor. The service requestor is responsible for the service invocation. The requestor
locates the Web service using the service broker, invokes the required services, and executes it
from the service provider.

Tools and Technologies enabling Web services: Core Web services standards

The five core Web services standards and technologies for building and enabling Webservices
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 all forms 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. SOAP is endorsed by W3C and key industry vendors like Sun Microsystems, IBM, HP,
SAP, Oracle, and Microsoft.

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 soon. 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 Defination 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 Microsystems, 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 ofspecifications for
enterprises to conduct electronic business over the Internet by establishing acommon standard
for business process specifications, business information modeling, business process
collaborations, collaborative partnership profiles, and agreements and messaging.

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 businessprocesses 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.

Other industry standards supporting web services:

Many industry initiatives and standards supporting Web services are currently available andmany
more will be available in the future
Web Services Choreography Interface (WSCI):

The Web Services Choreography Interface, or WSCI, is an initiative from Sun Microsystems,
BEA, Intalio, and SAP that defines the flow of messages exchanged in a particular process of
Web services communication. It describes the collective message flow model among Web
services by providing a global view of the processes involved during the interactions that
occur between Web services communication.Web Services Flow Language (WSFL):

The Web Services Flow Language, or WSFL, is an XML-based language initiative from IBMfor
describing Web services compositions. These compositions are categorized as flow models and
global models. Flow models can be used for modeling business processes or workflows based on
Web services, and global models can be used for modeling links between Web services
interfaces that enable the interaction of one Web service with an operation to another Web
service interface.

Using WSFL compositions support a wide range of interaction patterns between the partners
participating in a business process, especially hierarchical interactions and peer-to- peer
interaction between partners.

Directory Services Markup Language (DSML):

The Directory Services Markup Language, or DSML, defines an XML schema for representing
directory structural information as an XML document, and it allows the publishing and sharing
of directory information via Internet protocols like HTTP, SMTP, andso forth.

DSML does not define the attributes for the directory structure or for accessing the information.
A DSML document defines the directory entries or a directory schema or both, and it can be used
on top of any industry standard directory protocols like LDAP. DSML defines the standard for
exchanging information between different directory services and enables interoperability
between them.

XLANG:

Similar to WSFL, XLANG defines an XML-based standard specification for defining business
process flows in Web services. It also defines a notation for expressing actions and complex
operations in Web services.

Business Transaction Protocol (BTP):

The Business Transaction Protocol (BTP) specification provides a support for Web services-
based distributed transactions enabling the underlying transaction managers to provide the
flexibility of handling XA-compliant, two-phase commit transaction engines. BTP is an OASIS
initiative that facilitates large-scale business-to-business (B2B) deployments enablingdistributed
transactions in Web services.

XML Encdyption (XML ENC):

The XML Encryption, or XML ENC, is an XML-based standard for securing data by encryption
using XML representations. In Web services, it secures the exchange of data between the
communicating partners.

XML Key Management System (XKMS):

The XML Key Management System, or XKMS, is an XML-based standard for integrating public
key infrastructure (PKI) and digital certificates used for securing Internet transactions, especially
those used in Web services. XKMS consists of two parts: the XML Key Information Service
Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS). The X-
KISS specification defines a protocol for a trust service that resolves public key information
contained in XML-SIG elements. The X-KRSS describes how public key information is
registered.

XML Signature (XML DSIG):

The XML Encryption, or XML DSIG, is an XML-based standard for specifying XML syntax
and processing rules for creating and representing digital signatures. In Web services, an XML
digital signature helps XMLbased transactions by adding authentication, data integrity, and
support for non-repudiation to the data during data exchange among the communicating partners.

Extensible Access Control Markup Language (XACML)

The Extensible Access Control Markup Language, or XACML, is an XMLbased standard for
specifying policies and rules for accessing information over Web-based resources. In Web
services, XACML sets the rules and permissions on resources shared among the communicating
partners. XACML is one of the security initiatives made by the OASIS security services
technical committee.

Security Assertions Markup Language (SAML)

The Security Assertions Markup Language, or SAML, defines an XMLbased framework for
exchanging authentication and authorization information. SAML uses a generic protocol
consisting of XML-based request and response message formats, and it can be bound to many
communication models and transport protocols. One of the key objectives of SAML is to provide
and achieve single sign-on for applications participating in Web services. SAML isan initiative
from the security services technical committee of OASIS.
Web Services softwares and tools:

The following is a list of the most popular software solutions commercially available for
implementing Web services

BEA System Products:

BEAWebLogic Server 7.0 provides the infrastructure solution for Web services supporting the
standards and protocols of Web services. The BEA WebLogic Integration Server also enables
complex Web services to be deployed with transactional integrity, security, and reliability while
supporting the emerging ebXML and BTP standards.

Cape Clear Products:

Cape Clear provides Web services infrastructure and product solutions such as CapeConnect and
CapeStudio, which enable the development of Web services solutions based on industry
standards such as XML, SOAP, WSDL, and UDDI. Cape Clear also enables business
applications from diverse technologies such as Java, EJB, CORBA, and Microsoft .NET. These
components can be exposed as Web services over the Internet.

IBM Products:

IBM WebSphere Application Server 4.5 provides an infrastructure solution for deploying Web
services-based applications. IBM also provides a Web Services Tool Kit (WSTK) bundle (now
part of WebSphere Studio) for developers as a runtime environment that creates,publishes, and
tests Web services solutions based on open standards such as XML, SOAP, WSDL, and UDDI.
It also generates WSDL wrappers for existing applications without any reprogramming.

IOPSIS Products:

IOPSIS provides B2Beyond suite iNsight and W2Net, an Integrated Services Development
Framework (ISDF), that enables the creation, assembly, deployment, and publication of Web
services based on open standards such as XML, SOAP, WSDL, and UDDI. It also provides tools
for the deployment of Web Services to popular J2EE-based Web application servers.

Oracle Products:

Oracle’s Oracle9i Release 2 application server provides the J2EE-based infrastructure solution
for Web services supporting Web services standards including SOAP, UDDI, and WSDL. It also
has features that define and coordinate business processes using Web services integrating legacy
applications and back-end systems.
Sun Products:

As part of the Java community process, Sun has already released its Java and XML technology-
based APIs and its implementation referred to as JAX Pack for developing and testing Java and
open standards-based Web services solutions. In addition, Sun also has eleased a comprehensive
set of technologies specific to Web services that are referred to as the Java Web Services
Developer Pack (JWSDP).

The suite of products of Sun ONE Application Server 7.0, formerly called iPlanet Application
Server 6.0, provide a J2EE- and open standards-based infrastructure for implementing Web
services. The Sun ONE suite is a key component of Sun’s Open Net Environment (Sun ONE), a
comprehensive Web-services software environment for customers and developers interested in
migrating to the next generation of Web services.

Systinet Products:

Systinet provides Web services infrastructure and product solutions such asWASP Server,
WASP Developer, and WASP UDDI, which develops Web services solutions based on industry
standards such as XML, SOAP, WSDL, and UDDI. Systinet also enables business applications
from diverse technologies such as Java, EJB, CORBA, and Microsoft .NET to beexposed as
Web services over the Internet. It enables integration with J2EE-based applications and also
supports security frameworks based on GSS API and Kerberos. It also provides the
implementation of Java XML API technologies that were especially meant for Web services.

Key Benefits of Web services:

Te 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.

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 andmanaging service
descriptions in public/private registries.
UNIT II

Web Services Architecture - Web services Architecture and its core building blocks, Tools of
the Trade, Web Services Communication Models, Implementing Web Services, Developing Web
Services-Enabled Applications

Core fundamentals of SOAP - SOAP Message Structure, SOAP encoding, SOAP message
exchange model, SOAP communication and messaging, SOAP security.

Introduction to Web services:

In organizations with heterogeneous applications and distributed application architectures, the

introduction of Web services standardizes the communication mechanism and enables
interoperability of applications based on different programming languages residing on different
platforms.

What are 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.
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
facilitatesdelivering business applications as service accessible to anyone, anytime, at any
location, and using any platform.

Consider the simple example shown in Figure 2.1 where a travel reservation services provider
exposes its business applications as Web services supporting a variety of customers and
application clients. These business applications are provided by different travel organizations
residing at different networks and geographical locations
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 services 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.

Web services are typically implemented based on open standards and technologies specifically
leveraging XML. The XML-based standards and technologies, such as Simple Object Access
Protocol (SOAP); Universal Description, Discovery, and Integration (UDDI); Web Services
Definition Language (WSDL); and Electronic Business XML (ebXML), are commonly used as
building blocks for Web services.

Motivation and Characteristics:

Web-based B2B communication has been around for 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.

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, and conduct business transactions

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

The basic characteristics of a Web services application model are as follows:

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

■ Web services provide a cross-platform integration of business applications over the

Internet.

■ To build Web services, developers can use any common programming language, such
as Java, C, C++, Perl, Python, C#, and/or Visual Basic, and its existing application
components.
■ Web services are not meant for handling presentations like HTML context—it is
developed to generate XML for uniform accessibility through any software
application, any platform, or device.

■ Because Web services are based on loosely coupled application components, each
component is exposed as a service with its unique functionality.

■ Web services use industry-standard protocols like HTTP, and they can be easily
accessible through corporate firewalls.

■ Web services can be used by many types of clients.

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

transaction involving multiple resources.

■ All platforms including J2EE, CORBA, and Microsoft .NET provide extensive
support for creating and deploying Web services.

■ Web services are dynamically located and invoked from public and private registries
based on industry standards such as UDDI and ebXML.

Why Use Web services:

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:

These roles and relationships are defined as follows:

Service provider. The service provider is responsible for developin and deploying the Web
services. The provider also defines the service and publishes them with the service broker.

Service broker. The service broker (also commonly referred to as service registry) is responsible
for service registration and discover 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.

Web Services Architecture

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.

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-

Services container/runtime environment. The services container acts as the Web services runtime
environment and hosts the service provider.

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.

Services delivery. It acts as the Web services client runtime environment by lookingup the
services registries to find the required services and invoking them from the service provider.

WSDL. This resides in the services container and provides a standardized way to describe
theWeb services as a service description.

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.

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

SOAP Encoding. It defines a set of encoding rules for mapping the instances of the
application-specific data types to XML elements.

SOAP RPC conventions. It defines the representation of the RPC requests and responses.
TheseSOAP requests and responses are marshaled in a data type and passed in to a SOAP body

The following Listing represents a SOAP message using an HTTP post request for sending a
getBookPrice() method with <bookname> as an argument to obtain a price of a book.

Web Services Description Language (WSDL)

It is an XML schemabased specification for describing Web services as a collection of
operations and data input/output parameters as messages.

WSDL also defines the communication model with a binding mechanism to attach any transport
protocol, data format, or structure to an abstract message, operation, or endpoint.

The following Listing shows a WSDL example that describes a Web service meant for
obtaining a price of a book using a GetBookPrice operation.

Universal Description, Discovery, and Integration (UDDI): defines a mechanism to register

and categorize Web services in a general-purpose registry that users communicate to in order to
discover and locate registered services.

ebXML: provides a standard framework for building an electronic marketplace by enabling the
standardization of business processes, business

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.

The WSDL Document Structure

The main structure of a WSDL document looks like this:

<types>

definition of types........

</types>

definition of a message....

</message>
<portType>

definition of a operation.......

</operation>

</portType>

definition of a binding....

</binding>

definition of a service....

</service>

</definitions>

A WSDL document can also contain other elements, like extension elements and a service
element that makes it possible to group together the definitions of several web services in one
single WSDL document.

Proceed further to analyze an example of WSDL Document.

WSDL - Document Example

Given below is a WSDL file that is provided to demonstrate a simple WSDL program.

Let us assume the service provides a single publicly available function, called sayHello. This
function expects a single string parameter and returns a single string greeting. For example, if
you pass the parameter world then service function sayHello returns the greeting, "Hello,
world!".

RPC-Based Communication Model:

defines a request/response-based synchronous commn.

When the client sends a request, the client waits until a response is sent back from the server
beforecontinuing 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.

The clients have the capability to provide parameters in method calls to the Web service provider.

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.

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.
WS Communication

RPC-based communication model in Web services

WS Communication

Messaging-based communication
model

The 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
usingstandard protocols.

The basic steps of implementing Web services are as follows:

The service provider creates the Web service typically as SOAP-based service interfaces for
exposed business applications.

The service provider then registers the WSDL- based service description with a service
broker,which is typically a UDDI registry.

Implementing Web Services

The UDDI registry then stores the service description as binding templates and URLs to
WSDLs located in the service provider environment.
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.

Using the binding information, the service requestor then invokes the service provider and then
retrieves the WSDL Service description for those registered services.

Finally, the service requestor communicates with the service provider and exchanges data or
messages by invoking the available services in the service container.

Process steps involved in

implementing Web services
21

Web services architecture and its core building blocks

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 avital role as the
common wire format in all forms of communication. XML also is the basis for other Web services
standards.

Simple Object Access Protocol (SOAP)

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 Defination Language (WSDL)

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):

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.

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.

Other industry standards supporting web services or tools of trade

Many industry initiatives and standards supporting Web services are currently available and
many more will be available in the future

Web Services Choreography Interface (WSCI):

The Web Services Flow Language, or WSFL, is an XML-based language initiative from IBM for
describing Web services compositions. These compositions are categorized as flow models and
global models. Flow models can be used for modeling business processes or workflows based on
Web services, and global models can be used for modeling links between Web services
interfaces that enable the interaction of one Web service with an operation to another Web
service interface.

Directory Services Markup Language (DSML):

XLANG:

Business Transaction Protocol (BTP):

XML Encdyption (XML ENC):

XML Key Management System (XKMS):

XML Signature (XML DSIG):

Extensible Access Control Markup Language (XACML)

Security Assertions Markup Language (SAML)

The Security Assertions Markup Language, or SAML, defines an XMLbased framework for
exchanging authentication and authorization information. SAML uses a generic protocol

consisting of XML-based request and response message formats, and it can be bound to many
communication models and transport protocols. One of the key objectives of SAML is to provide
and achieve single sign-on for applications participating in Web services. SAML is an initiative
from the security services technical committee of OASIS.
Web Services softwares and tools or communication models
The following is a list of the most popular software solutions commercially available for
implementing Web services

BEA System Products:

Cape Clear Products:

IBM Products:

IBM WebSphere Application Server 4.5 provides an infrastructure solution for deploying Web
services-based applications. IBM also provides a Web Services Tool Kit (WSTK) bundle (now
part of WebSphere Studio) for developers as a runtime environment that creates, publishes, and
tests Web services solutions based on open standards such as XML, SOAP, WSDL, and UDDI.
It also generates WSDL wrappers for existing applications without any reprogramming.

IOPSIS Products:

IOPSIS provides B2Beyond suite iNsight and W2Net, an Integrated Services Development
Framework (ISDF), that enables the creation, assembly, deployment, and publication of Web services
based on open standards such as XML, SOAP, WSDL, and UDDI. It also provides tools for the deployment
of Web Services to popular J2EE-based Web application servers.

Oracle Products:

Systinet Products:

Systinet provides Web services infrastructure and product solutions such asWASP Server,
WASP Developer, and WASP UDDI, which develops Web services solutions based on industry
standards such as XML, SOAP, WSDL, and UDDI. Systinet also enables business applications
from diverse technologies such as Java, EJB, CORBA, and Microsoft .NET to be exposed as
Web services over the Internet. It enables integration with J2EE-based applications and also
supports security frameworks based on GSS API and Kerberos. It also provides the
implementation of Java XML API technologies that were especially meant for Web services.

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:

1.The service provider creates the Web service typically as SOAPbased service interfaces for
exposed business applications. he 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 requester then locates the required services by querying the UDDI registry.
The service requester obtains the binding information and the URLs to identify the
service provider.

5. Using the binding information, the service requester then invokes the service provider
and then retrieves the WSDL Service description for those registered services. Then,
the service requester creates

a client proxy application and establishes communication with the service provider using SOAP.

6. Finally, the service requester 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. Web Services Security.” So far we
have explored the Web services architecture and technologies. Let’s now move forward to learn
how to develop web services-enabled applications as services using the Web services
architecture.
Developing Web Services-Enabled Applications
The above diagram shows a very simplistic view of how a web service would actually work. The
client would invoke a series of web service calls via requests to a server which would host the
actual web service.

These requests are made through what is known as remote procedure calls. Remote Procedure
Calls(RPC) are calls made to methods which are hosted by the relevant web service

As an example, Amazon provides a web service that provides prices for products sold online via
amazon.com. The front end or presentation layer can be in .Net or Java but either programming
language would have the ability to communicate with the web service.

The main component of a web service design is the data which is transferred between the client
and the server, and that is XML. XML (Extensible markup language) is a counterpart to HTML
and easy to understand the intermediate language that is understood by many programming
languages.

So when applications talk to each other, they actually talk in XML. This provides a common
platform for application developed in various programming languages to talk to each other.
Web services use something known as SOAP (Simple Object Access Protocol) for sending the
XML data between applications. The data is sent over normal HTTP. The data which is sent
from the web service to the application is called a SOAP message. The SOAP message is
nothing but an XML document. Since the document is written in XML, the client application
calling the web service can be written in any programming language.

SOAP Message Structure

What is SOAP?

SOAP or Simple Objects Access Protocol is a web communication protocol designed for
Microsoft back in 1998. Today, it’s mostly used to expose web services and transmit data over
HTTP/HTTPS. But it’s not limited to them. SOAP, unlike the REST pattern, supports the XML
data format only and strongly follows preset standards such as messaging structure, a set of
encoding rules, and a convention for providing procedure requests and responses.

The built-in functionality to create web-based services allows SOAP to handle communications
and make responses language- and platform-independent.

While most web data exchange happens over REST exchange, SOAP isn’t disappearing anytime
soon, because it’s highly standardized, allows for automation in certain cases, and it’s more
secure. Let’s have a look at the main SOAP features.

SOAP works with XML only

Web-transmitted data is usually structured in some way. The two most popular data formats are
XML and JSON.

XML (or Extensible Markup Language) is a text format that establishes a set of rules to structure
messages as both human- and machine-readable records. But XML is verbose as it aims at
creating a web document with all its formality. JSON, on the other hand, has a loose structure
that focuses on the data itself. Have a look at the image below to get the idea.
As we’ve mentioned, when sending requests and response messages within web applications,
SOAP requires XML exchange between systems. And when the request is received, SOAP APIs
send messages back XML-coded only.

Besides the data format, SOAP has another level of standardization – its message structure.

SOAP message structure

XML isn’t the only reason SOAP is considered verbose and heavy compared to REST. It’s also
the way SOAP messages are composed. Standard SOAP API requests and responses appear as
an enveloped message that consists of four elements with specific functions for each one.
Envelope is the core and essential element of every message, which begins and concludes
messages with its tags, enveloping it, hence the name.

Header (optional) determines the specifics, extra requirements for the message, e.g.
authentication.

Body includes the request or response.

Fault (optional) shows all data about any errors that could emerge throughout the API request
and response.

Syntax Rules

Here are some important syntax rules:

A SOAP message MUST be encoded using XML

A SOAP message MUST use the SOAP Envelope namespace

A SOAP message must NOT contain a DTD reference

A SOAP message must NOT contain XML Processing Instructions

Skeleton SOAP Message

SOAP encoding

SOAP includes a built-in set of rules for encoding data types. It enables the SOAP message to
indicate specific data types, such as integers, floats, doubles, or arrays.

• SOAP data types are divided into two broad categories − scalar types and compound
types.

• Scalar types contain exactly one value such as a last name, price, or product description.

• Compound types contain multiple values such as a purchase order or a list of stock
quotes.

• Compound types are further subdivided into arrays and structs.

• The encoding style for a SOAP message is set via the SOAP-
ENV:encodingStyle attribute.

• To use SOAP 1.1 encoding, use the value http://schemas.xmlsoap.org/soap/encoding/

• To use SOAP 1.2 encoding, use the value http://www.w3.org/2001/12/soap-encoding

• Latest SOAP specification adopts all the built-in types defined by XML Schema. Still,
SOAP maintains its own convention for defining constructs not standardized by XML
Schema, such as arrays and references.

• SOAP encoding offers the following rules to convert any data value defined in SOAP
data model into XML format. Converting a data value into XML format is called
serialization or encoding.

• SOAP message exchange model

The SOAP specification mentions a concept called "message exchange patterns" (MEP).
There are two basic message exchange patterns described in the SOAP specification:

1. Request - Response

2. Response

These two message exchange patterns are described in the following sections.

Request - Response

In a request - response message exchange the SOAP client sends a SOAP request
message to the service. The service responds with a SOAP response message.

A request - response message exchange patterns is necessary when the SOAP client
needs to send data to the SOAP service, for the service to carry out its job. For instance,
if the client request that data be stored by the service, the client needs to send the data to
be stored to the service.

Here is an illustration of a request - response message exchange:

Response

In a response message exchange the SOAP client connects to the

service, but does not send a SOAP message through. It just sends e.g.
a simple HTTP request. The service responds with with a SOAP
message.

This message exchange pattern is similar to how a browser

communicates with a web server. The browser sends an HTTP request
telling what page it wants to access, but the HTTP request does not
carry any additional data. The web server responds with an HTTP
response carrying the requested page.

Here is an illustration of the response message exchange pattern:

SOAP communication and messaging

SOAP was developed as an intermediate language for applications that have

different programming languages, enabling these applications to communicate
with each other over the internet. SOAP is flexible and independent, which
enables developers to write SOAP application programming interfaces (APIs)
in different languages while also adding features and functionality.

SOAP is a lightweight protocol used to create web APIs, usually with

Extensible Markup Language (XML). It supports a wide range of
communication protocols across the internet, HTTP, Simple Mail Transfer
Protocol (SMTP) and Transmission Control Protocol. The SOAP approach
defines how a SOAP message is processed, the features and modules included,
the communication protocols supported and the construction of SOAP
messages. SOAP uses the XML Information Set as a message format and relies
on application layer protocols, like HTTP, for message transmission and
negotiation.

SOAP building blocks and message structure example

Simple Object Access Protocol, as a specification, defines SOAP messages that
are sent to web services and client applications. SOAP messages are XML
documents that are comprised of the following three basic building blocks:

1. The SOAP Envelope encapsulates all the data in a message and identifies the
XML document as a SOAP message.
2. The Header element contains additional information about the SOAP message.
This information could be authentication credentials, for example, which are
used by the calling application.
3. The Body element includes the details of the actual message that need to be
sent from the web service to the calling application. This data includes call and
response information.

The fault message is an optional fourth building block. If a SOAP fault is

generated, it is returned as an HTTP 500 error. Fault messages contain a fault
code, string, actor and detail.

SOAP security

SOAP is a messaging protocol, meaning that SOAP security is primarily

concerned with preventing unauthorized access to these messages and to users’
information. The main thing used to accomplish this is WS (Web Standards)
Security.

WS Security is a set of principles that regulate the confidentiality and

authentication procedures for SOAP messaging. WS Security-compliant
measures include passwords, X.509 certificates, digital signatures and XML
(Extensible Markup Language) encryption, among other things. XML
encryption causes the data to be unreadable to unauthorized users.

Why is SOAP Security Important?

Cyber security is on the list of top concerns of modern businesses. According

to one source, the average monetary loss due to malware attacks on companies
is $2.4 million. Up to 21% of files have no security measures or protections in
place at all. This not only makes the company’s data prone to attacks but also
makes the employee’s personal data and devices like their Mac prone to
malware attacks.

SOAP security protects oftentimes sensitive data that may otherwise fall into
the wrong hands. It is a means of integrating security into the APIs
infrastructure and protecting the interests of your clients.

DreamFactory brings additional safety to your data by building and monitoring

APIs for you. We offer an API-as-a-service platform with rock-solid security
measures.

Common SOAP Security Risks

There are many different kinds of cyber security vulnerabilities and attacks, and
some are uniquely aimed at APIs. A few of these are code injections, DoS
(Denial of Service), breached or leaked access/authorization, XSS (Cross-site
Scripting) and session hijacking.

Code Injections

Code injections, using SQL or, in the case of SOAP, XML, introduce malicious
code into the database or application itself. The only way to prevent these is
with careful access control.

Breached or Leaked Access/Authorization

The majority of attacks, including code injections, start with breached or leaked
access. Making sure SOAP messages get revealed only to the correct user is
one important part of SOAP security.

DoS

A Denial of Service, or Distributed Denial of Service (DDoS) attack

overwhelms and disrupts a web service with messages that are too many or too
long. SOAP security includes measures that can make DoS attacks impossible
by limiting the length and volume of messages.
XSS

Cross-site scripting is another form of code injection, but more specifically it

occurs when someone injects malicious browser-side script into the web site
through the web application.

Session Hijacking

Session hijacking is another failure of access control. It occurs when an

unauthorized user obtains a session ID. The user then has full access to the
application and/or another user’s account.
UNIT-III
Building SOAP Web Services

Before you begin to create a SOAP web service, perform these tasks:

1. Configure your CICS system to support web services; see Configuring your CICS system
for web services.

2. Create the necessary infrastructure to support the deployment of your web services;
see Creating the web services infrastructure.

3. Decide whether you want to use the web services assistant;

The CICS web services assistant is a supplied utility that helps you to create the necessary
artifacts for a new SOAP web service provider or a service requester application, or to enable an
existing application as a web service provider.

The CICS web services assistant can create a WSDL document from a simple language structure
or a language structure from an existing WSDL document; it supports COBOL, C/C++, and
PL/I. It also generates information that is used to enable automatic runtime conversion of the
SOAP messages to containers and COMMAREAs, and vice versa. This information is used by
the CICS web services support during pipeline processing.

Create your web service, as described in the following procedure, and validate that it works
correctly:

Procedure

1. Create a SOAP web service in one of four ways:

o Use the web services assistant to create the web service description or language
structures and deploy them into CICS. Use the PIPELINE SCAN command to
automatically create the required CICS resources.

o Use Rational® Developer for System z® or the Java™ API to create the web
service description or language structures and deploy them into CICS. Use
the PIPELINE SCAN command to automatically create the required CICS
resources.

o Create or change an application program to handle the XML in the inbound and
outbound messages, including the data conversion, and populate the correct
containers in the pipeline. You must create the required CICS resources manually.

o Deploy an Axis2 application as a web service.

2. Start the web service to test that it works as you intended.

If you are using the web services assistant to deploy your web service, you can use the SET
WEBSERVICE command to turn on validation. This validation checks that the data is
converted correctly.

Step 1: Create the Eclipse project

The first step is simply to create a dynamic web project in Eclipse named soap-ws-example. The
project should use web module version 3.1, employ a minimal configuration and be associated
with a runtime that supports the Java web profile. For this SOAP web services example in Java
using Eclipse, we will employ WildFly 10.x as the chosen runtime.

Step 2: Code the Score class

Step 3: Add XML annotations

The only minor complication to the Score class is that you have to decorate it with a couple of
annotations. Since the data the Score class encapsulates will be sent to SOAP web services
clients in XML format, the class requires an @XMLType annotation. Furthermore, since the
class has no getter methods, the XML engine will need to look directly at the properties of
the Score class. So, add an @XmlAccessorType annotation that indicates field-based access. The
complete class looks as follows:
Step 4: Code the ScoreService

The ScoreService class will mitigate access to the Score class through methods such
as getScore(), increaseWins() and getLosses(). Initialize the instance of the Score class
the ScoreService references through dependency injection, or read from a NoSQL database, as a
web service should never maintain any internal state. Cameron McKenzie, TechTarget

Use Tomcat, Eclipse to create a JAX-RS REST web service

Step-by-step RESTful web service example in Java using Eclipse and TomEE Plus

Create a distraction free JPA and Hibernate dev environment

SOAP web services example

a microservice that keeps track of the number of wins, losses and ties in an online game of rock-
paper-scissors. In this SOAP web services example in Java using Eclipse, I would like to
implement the exact same use case, only with JAX-WS instead of JAX-RS.
Create a project named soap-ws-example
in Eclipse.

Step 1: Create the Eclipse project

Step 2: Code the Score class

This SOAP web services example will use two classes: a simple POJO (Plain Old Java Object)
named Score and a class that mitigates remote access to the Score class named ScoreService. We
will keep the Score class incredibly simple. The class will declare only three public variables,
each of type int, named wins, losses and ties. To really keep things tight, we won't even add any
setters or getters.

Step 3: Add XML annotations

Decorate the class with these annotations.

Step 4: Code the ScoreService

Step 5: Add SOAP Web Service annotations

To turn the Score Service into a SOAP web service, it needs to be decorated with two
annotations: one to indicate the class complies with all of the semantics of a stateless Enterprise
JavaBeans (EJB) architecture and another to indicate that the public methods in the class can be
accessed through a SOAP-based service. The first iteration of the SOAP web services example
looks as follows:

Step 6: Enhance the SOAP web service

All of the methods in the first iteration of the SOAP web services example have empty method
signatures. To demonstrate how easy it is to pass data to a SOAP web service, we will add
an updateScore method that takes three int parameters, updates all of the instance variables of
the Score class and returns the updated Score instance:

step 7: Use the @WebMethod annotation

Next, we will add a reset method. This sets the number of wins, losses and ties to nil.

The method in the class will be named reset, but when SOAP web services clients invoke the
method, we want the remote API call to be resetScore. To override the default method to Web
Services Description Language (WSDL) mappings, JAX-WS provides a special annotation
called @WebMethod. By changing the operationName attribute of
the @WebMethod annotation, the method name used by the SOAP web services client can be
tweaked.

Step 8: Run and test the SOAP web service

With the Score and the ScoreService classes completed, simply right-click on the soap-ws-
example project, and select Run As > Run on Server
Limitations of SOAP

No transactions across the Web

• The SOAP protocol currently does not provide any transaction support. A
web-service method can begin a new transaction, and local resources will
enlist on that transaction, but a web service can’t enlist on an existing
transaction.

Exceptions are returned as SOAP faults

• When there is some error in processing a web-method call, the web service
responds with a SOAP fault. If the client of the web service is implemented on
the .NET platform, the client receives a SoapException exception (defined in
the System.Web.Services.Protocols namespace), even if both the client and
server are using .NET
WSDL - WSDL in the world of Web Services

Anatomy of WSDL definition document

WSDL stands for Web Services Description Language. It is the standard format
for describing a webservice. WSDL was developed jointly by Microsoft and
IBM.

Features of WSDL

• WSDL is an XML-based protocol for information exchange in

decentralized and distributedenvironments.
• WSDL definitions describe how to access a web service and what operations it
will perform.
• WSDL is a language for describing how to interface with XML-based services.
• WSDL is an integral part of Universal Description, Discovery, and
Integration (UDDI), anXML-based worldwide business registry.
• WSDL is the language that UDDI uses.
• WSDL is pronounced as 'wiz-dull' and spelled out as 'W-S-D-L'.

WSDL Usage

WSDL is often used in combination with SOAP and XML Schema to provide
web services over the Internet. A client program connecting to a web service can
read the WSDL to determine what functions are available on the server. Any
special datatypes used are embedded in the WSDL file in the form of XML
Schema. The client can then use SOAP to actually call one of the functions
listed inthe WSDL.

WSDL - Elements

WSDL breaks down web services into three specific, identifiable elements that
can be combined or reused once defined.

The three major elements of WSDL that can be defined separately are:

• Types
• Operations
• Binding

A WSDL document has various elements, but they are contained within these
three main elements, which can be developed as separate documents and then
they can be combined or reused to form complete WSDL files.

WSDL Elements
A WSDL document contains the following elements:

• Definition : It is the root element of all WSDL documents. It defines the

name of the web service, declares multiple namespaces used throughout
the remainder of the document, and contains all the service elements
described here.
• Data types : The data types to be used in the messages are in the form of XML
schemas.
• Message : It is an abstract definition of the data, in the form of a
message presented either as an entire document or as arguments to be
mapped to a method invocation.
• Operation : It is the abstract definition of the operation for a message,
such as naming a method, message queue, or business process, that will
accept and process the message.
• Port type : It is an abstract set of operations mapped to one or more end-
points, defining the collection of operations for a binding; the collection
of operations, as it is abstract, can be mapped to multiple transports
through various bindings.
• Binding : It is the concrete protocol and data formats for the operations
and messages definedfor a particular port type.
• Port : It is a combination of a binding and a network address, providing
the target address of the service communication.
• Service : It is a collection of related end-points encompassing the service
definitions in the file; the services map the binding to the port and
include any extensibility definitions.

In addition to these major elements, the WSDL specification also defines

the following utilityelements:

• Documentation: This element is used to provide human-readable

documentation and can be included inside any other WSDL element.
• Import : This element is used to import other WSDL documents or XML
Schemas.

The main structure of a WSDL document looks like this:

definition of types........

</types>

definition of a message....

</message>

definition of a operation.......

</operation>

</portType>

definition of a binding....

</binding>

definition of a service....

</service>
</definitions>

A WSDL document can also contain other elements, like extension elements
and a service element that makes it possible to group together the definitions of
several web services in one single WSDL document.

WSDL - Document Example

Given below is a WSDL file that is provided to demonstrate a simple WSDL program.

Let us assume the service provides a single publicly available function, called
sayHello. This function expects a single string parameter and returns a single
string greeting. For example, if you pass the parameter world then service
function sayHello returns the greeting, "Hello, world!".

Example

Contents of HelloService.wsdl file:

<part name="firstName" type="xsd:string"/>

</message>
<message name="SayHelloResponse">

<part name="greeting" type="xsd:string"/>

</message>

</operation>

</portType>

<binding name="Hello_Binding" type="tns:Hello_PortType">

<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/s
oap/http"/>

<soap:operation soapAction="sayHello"/>

<input>

<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/
encoding/"
namespace="urn:examples:helloservice"

use="encoded"/>
</input>
<output>

<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/
encoding/"
namespace="urn:examples:helloservice"

use="encoded"/>

</output>

</operation>

</binding>

<documentation>WSDL File for HelloService</documentation>

<port binding="tns:Hello_Binding" name="Hello_Port">

<soap:address
location="http://www.examples.co
m/SayHello/">

</
po
rt
>

</
se
rv
ic
e>

</definitions>

Example Analysis
• Definitions : HelloService
• Type : Using built-in data types and they are defined in XMLSchema.
• Message :
o sayHelloRequest : firstName parameter
o sayHelloresponse: greeting return value
• Port Type : sayHello operation that consists of a request and a response service.
• Binding : Direction to use the SOAP HTTP transport protocol.
• Service : Service available at http://www.examples.com/SayHello/
• Port : Associates the binding with the URI
http://www.examples.com/SayHello/ where therunning service can be
accessed.

Web services lifecycle

A web service implementation lifecycle refers to the phases for developing web services from
the requirement to development. An Implementation lifecycle includes the following phases:

o Requirements Phase
o Analysis Phase
o Design Phase
o Coding Phase
o Test Phase
o Deployment Phase
he objective
of the requirements phase is to understand the business requirement and translate them into
the web services requirement. The requirement analyst should do requirement elicitation (it is
the practice of researching and discovering the requirements of the system from the user,
customer, and other stakeholders). The analyst should interpret, consolidate, and communicate
these requirements to the development team. The requirements should be grouped in a
centralized repository where they can be viewed, prioritized, and mined for interactive features.

Analysis Phase

The purpose of the analysis phase is to refine and translate the web service into conceptual
models by which the technical development team can understand. It also defines the high-level
structure and identifies the web service interface contracts.

Design Phase

In this phase, the detailed design of web services is done. The designers define web service
interface contract that has been identified in the analysis phase. The defined web service
interface contract identifies the elements and the corresponding data types as well as mode of
interaction between web services and client.

Coding Phase
Coding and debugging phase is quite similar to other software component-based coding and
debugging phase. The main difference lies in the creation of additional web service interface
wrappers, generation of WSDL, and client stubs.

Test Phase

In this phase, the tester performs interoperability testing between the platform and the client's
program. Testing to be conducted is to ensure that web services can bear the maximum load
and stress. Other tasks like profiling of the web service application and inspection of the SOAP
message should also perform in the test phase.

Deployment Phase

The purpose of the deployment phase is to ensure that the web service is properly deployed in
the distributed system. It executes after the testing phase. The primary task of deployer is to
ensure that the web service has been properly configured and managed. Other optional tasks
like specifying and registering the web service with a UDDI registry also done in this phase.

WSDL bindings
The <binding> element provides specific details on how a portType operation will actually be
transmitted over the wire.
• The bindings can be made available via multiple transports including HTTP GET, HTTP
POST, or SOAP.
• The bindings provide concrete information on what protocol is being used to
transfer portType operations.
• The bindings provide information where the service is located.
• For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages
on top of HTTP protocol.
• You can specify multiple bindings for a single portType.
The binding element has two attributes : name and type attribute.
<binding name = "Hello_Binding" type = "tns:Hello_PortType">
The name attribute defines the name of the binding, and the type attribute points to the port for
the binding, in this case the "tns:Hello_PortType" port.

SOAP Binding
WSDL 1.1 includes built-in extensions for SOAP 1.1. It allows you to specify SOAP specific
details including SOAP headers, SOAP encoding styles, and the SOAPAction HTTP header. The
SOAP extension elements include the following −
• soap:binding
• soap:operation
• soap:body
soap:binding
This element indicates that the binding will be made available via SOAP. The style attribute
indicates the overall style of the SOAP message format. A style value of rpc specifies an RPC
format.
The transport attribute indicates the transport of the SOAP messages. The value
http://schemas.xmlsoap.org/soap/http indicates the SOAP HTTP transport, whereas
http://schemas.xmlsoap.org/soap/smtp indicates the SOAP SMTP transport.
soap:operation
This element indicates the binding of a specific operation to a specific SOAP implementation.
The soapAction attribute specifies that the SOAPAction HTTP header be used for identifying the
service.
soap:body
This element enables you to specify the details of the input and output messages. In the case of
HelloWorld, the body element specifies the SOAP encoding style and the namespace URN
associated with the specified service.
Here is the piece of code from the Example chapter −
<binding name = "Hello_Binding" type = "tns:Hello_PortType">
<soap:binding style = "rpc" transport = "http://schemas.xmlsoap.org/soap/http"/>
<operation name = "sayHello">
<soap:operation soapAction = "sayHello"/>

<output>
<soap:body
encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"
namespace = "urn:examples:helloservice" use = "encoded"/>
</output>
</operation>
</binding>
WSDL TOOLS

• 1. Web Service Call Composer (Web Service Tester) .:

Stylus Studio's Web Service Call Composer (SOAP Tester) lets you Search a UDDI
registry, generate a SOAP request, and easily invoke any Web service method. This
utility is ideal for Web service testing, and also enables you to set up Web services as
datasources to be used as inputs for XML data transformations!

2. Apache AXIS. ...

The well known Apache Axis, and the the second generation of it, the Apache
Axis2, are two Web Service containers that helps users to create, deploy, and
run Web Services.

Axis2 is avaialble in both Java as well as C, languages

3. WSDL Editor. ...

The WSDL Editor enables you to edit Web Services Description Language (WSDL)
files. WSDL is an XML-based language for describing web services. A WSDL file
contains the following types of information: Information about the functionality of the
web service
.
4. Use Web Service Data as Input for Data Mapping. ...

Setting up Data Inputs to and Outputs from the Web Service

Data fields (and/or formal parameters) must be used to define the inputs to and outputs from the
web service. The data fields must be mapped to the matching message input and output parts in
the WSDL document.

5. Open Web Service Framework Architecture. ...

The Web Services architecture describes how to instantiate the elements and
implement the operations in an interoperable manner. The architecture of web
service interacts among three roles: service provider, service requester, and service
registry. The interaction involves the three operations: publish, find, and bind.
6. WSDL Designer.

Web Services Description Language Designer, shown below, consists of a split-pane interface,
with a graphical view of the WSDL at the top including:
• messages,
• portTypes,
• bindings,
• parts,
• operations, and
• embedded schemas

Future of WSDL,

WSDL documents allow developers to expose their applications as network-accessible services

on the Internet. Through UDDI and WSIL, other applications can discover WSDL documents
and bind with them to execute transactions or perform other business processes.

This development platform supports and encourages the development and use of WS-I compliant
WSDL. Business service providers can deploy Java™ beans and enterprise beans as a Web
service and generate a WSDL document that describes the service. They can also generate Java
and enterprise bean skeletons from an existing WSDL file. A business service client can generate
a Java proxy from a WSDL document, thereby providing an easy-to-use Java interface to the
Web service. The Java interface hides the network communications details from the client
enabling the business service provider to focus on business and process portions of the
application.

In addition to providing tools to create Web services, the workbench provides a WSDL editor
that allows you to create WSDL files using a graphical interface, a WSDL validator that ensures
that your WSDL file is semantically correct and optionally checks for WS-I compliance, and the
Web Services Explorer which allows you to dynamically test Web services without requiring
you to generate a proxy.

Limitations of WSDL

• A WSDL file cannot have more than one <wsdl:include> element.

• All operations should be of one kind — that is, all RPC-encoded or all doc/literal.

• Only SOAP operations are considered. MIME and HTTP operations are ignored.

• Overloaded operations are not allowed.

• Both input and output should be present; one-way messaging is not allowed.
• A WSDL file cannot have both a <wsdl:include> and a <wsdl:types> element.
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, support for categorization in UDDI Registries, Publishing API,
Publishing information to a UDDI Registry, searching information in a UDDI Registry, deleting
information in a UDDI Registry, limitations of UDDI.

Service discovery

Roles of Registry and Discovering

SOA Service Registry and/or Repository

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 servicesmetadata.

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

services in an SOAimplementation
Service Registry helps in managing service located in different places (internally,
externally) and indifferent 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 service reuse.

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

Role of 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 reusability.

• 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

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.

Publishing a web service involves creating a software artifact and making it accessible to
potential consumers. Web service providers augment a service endpoint interface with an
interface description using the Web Services Description Language (WSDL) so that a consumer
can use the service.

Universal Description, Discovery, and Integration (UDDI) is an XML-based registry for

business internet services. A provider can explicitly register a service with a Web Services
Registry such as 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.

UDDI - UDDI Registries

Universal Description, Discovery and Integration (UDDI)

is a platform-independent, extensible world markup language(XML)-based registry by which

businesses worldwide can list themselves on the Internet, and a mechanism to register and locate
web service applications. UDDI is an open industry initiative, sponsored by the Organization for
the Advancement of Structured Information Standards (OASIS), for enabling businesses to
publish service listings and discover each other, and to define how the services or software
applications interact over the Internet.

UDDI was originally proposed as a core Web service standard .[1] It is designed to be
interrogated by SOAP messages and to provide access to Web Services Description Language
(WSDL) documents describing the protocol bindings and message formats required to interact
with the web services listed in its directory.
A UDDI business registration consists of three components:

White Pages — address, contact, and known identifiers;

Yellow Pages — industrial categorizations based on standard taxonomies;

Green Pages — technical information about services exposed by the business.

White Pages

White pages give information about the business supplying the service. This includesthe
name of the business and a description of the business - potentially in multiple languages. Using
this information, it is possible to find a service about which some information is already known
(for example, locating a service based on the provider'sname).

Contact information for the business is also provided - for example the businesses address and
phone number; and other information such as the Dun & BradstreetUniversal umbering System
number.

Yellow Pages

Yellow pages provide a classification of the service or business, based on standard taxonomies.
These include the Standard Industrial Classification (SIC), the North American Industry
[6]
Classification System (NAICS), or the United Nations Standard

Products and Services Code (UNSPSC) and geographic taxonomies

Because a single business may provide a number of services, there may be several Yellow Pages
(each describing a service) associated with one White Page (giving general information about the
business).

Green Pages

Green pages are used to describe how to access a Web Service, with information on the service
bindings. Some of the information is related to the Web Service - such as the address of the
service and the parameters, and references to specifications of interfaces.[6] Other information is
not related directly to the Web Service - this includes

e-mail, FTP,CORBA and telephone details for the service. Because a Web Service may have
multiple bindings (as defined in its WSDL description), a service may have multiple Green
Pages, as each binding will need to be accessed diferently.
UDDI Nodes & Registry

UDDI nodes are servers which support the UDDI specification and belong to a UDDI registry
while UDDI registries are collections of one or more nodes.

SOAP is an XML-based protocol to exchange messages between a requester and a provider of a

Web Service. The provider publishes the WSDL to UDDI and the requester can join to it using
SOAP.

UDDI data Structure

Data structure types (UDDI registry)

Once you have registered and logged in to the UDDI registry that you want to use, you
can register your Web service. Registration of a service involves four core data structure
types: business information, service information, binding information, and information
describing the specifications forservices. The relationship between these data types is
described in Figure 1.
Business information. Information that is contained in a businessEntity structure.

The businessEntity contains information about the business that has published the service, such
as business name, description, contacts and identifiers.

Service information. Information that describes a group of Web services. It is contained in

a businessService structure. The businessServicecontains information about families of technical

services. It groups a set of Web services related to either a business process or group of services.

Binding information. Information represented by the binding Template structure. The binding
Template holds technical information for determining the entry point and construction
specifications for invoking a Web service. The binding Template provides the Web service
descriptions relevant for application developers that want to find and invoke a Web service. The
binding Template points to a service implementation descriptions, for example via a URL.

Information describing the specifications for services. Metadata about the various
specifications implemented by a given Web service represented by the t Model. The t Model
provides a reference system to assist in the discovery of Web services.
Figure 1. Relationship between data types

Each child structure has a unique parent structure. This means that each businessService
structure is owned by a specific businesssEntity. In turn, eachbinding Template is owned by a
specific businessService.

Each bindingTemplate structure references to unique instances of tModel structures; however,

since references can be repeated within several parent structures, there can be many references to
tModels from different Entity-Service-Template parents, as seen in Figure 2.

Figure 2. References to tModel.

Publisher assertions

A publisher assertion is a way in UDDI to associate businessEntity structures. The publisher

assertion defines a group of businessEntity structures. Many businesses are not effectively
represented by a single businessEntity. A publisher assertion allows for the association between
businessEntity structures. For example, a large company may have several subsidiaries that have
different descriptions but are still closely coupled and want to make their relationships visible in
UDDI registries.

Service projections

A service projection enables a business entity to reference a service that was published by
another business entity. By using the businessService structure as a projection to an already
published businessService, businesses can share or reuse services. Service projections are
managed centrally as part of the referencing businessEntity. This means that any changes made
to the businessService by any of the referencing businessEntity structures are valid for all of the
referencing businessEntity structures.

UDDI Technical Architecture

The UDDI technical architecture consists of three parts:

UDDI data model:

An XML Schema for describing businesses and web services. The data model is
described in detail in the "UDDI Data Model" section.

UDDI API Specification:

A Specification of
API for searching
and publishing
UDDI data.

UDDI cloud services:

This is operator sites

that provide
implementations of
the UDDI
specification and
synchronize all data
on a scheduled basis.

uses of UDDI Registry

The UDDI registry can help to address these issues and provides the following benefits:

• It delivers visibility when identifying which services within the organization can be
reused to address a business need.

• It promotes reuse and prevents reinvention. It accelerates development time and

improves productivity. This ability of UDDI to categorize a growing portfolio of services
makes it easier to manage them. It helps you understand relationships between
components, supports versioning and manages dependencies.
• It supports service configurability and adaptability by using the service-oriented
architectural principle of location and transport independence. Users can dynamically
discover services stored in the UDDI registry.

• It allows you to understand and manage relationships between services, component

versions and dependencies.

• It makes it possible to manage the business service lifecycle. For example, the process of
moving services through each phase of development, from coding to public deployment.
For more information, see the Approval Process.

Programming with UDDI.

UDDI - Implementations
A number of UDDI implementations are currently available. These implementations make it
easier to search or publish UDDI data, without getting mired in the complexities of the UDDI
API. Here is a brief synopsis of the main UDDI implementations available.

Java Implementations
There are two UDDI implementations for Java.
• UDDI4J (UDDI for Java) − UDDI4J was originally created by IBM. In January 2001,
IBM turned over the code to its own open source site. UDDI4J is a Java class library that
provides an API to interact with a UDDI.
• jUDDI − jUDDI is an open source Java implementation of a UDDI registry and a toolkit
for accessing UDDI services.

Perl Implementation
• UDDI::Lite − It provides a basic UDDI client for inquiry and publishing.

Ruby Implementation
• UDDI4r − It provides a basic UDDI client for inquiry and publishing.

Python Implementation
• UDDI4Py − UDDI4Py is a Python package that allows the sending of requests to, and
processing of responses from the UDDI Version 2 APIs.

UDDI data structures

UDDI Data Model

UDDI includes an XML Schema that describes four five data structures:
• businessEntity
• businessService
• bindingTemplate
• tModel
• publisherAssertion

businessEntity data structure:

The business entity structure represents the provider of web services.
Within the UDDI registry, this structure contains information about
the company itself, including contact information, industry categories,
business identifiers, and a list of services provided.
Here is an example of a fictitious business's UDDI registry entry:

businessService data structure:

The business service structure represents an individual web service

provided by the business entity. Its description includes information on
how to bind to the web service, what type of web service it is, and what
taxonomical categories it belongs to:

Here is an example of a business service structure for the Hello World web service.

Notice the use of the Universally Unique Identifiers

(UUIDs) in
the businessKey and serviceKeyattributes. Every business entity and business
service is uniquely identified in all UDDI registries through the UUID assigned
by the registry when the information is first entered.
bindingTemplate data structure:

Binding templates are the technical descriptions of the web services

represented by the business service structure. A single business service may
have multiple binding templates. The binding template represents the actual
implementation of the web service.

Here is an example of a binding template for Hello World.

Because a business service may have multiple binding templates, the

service may specify different implementations of the same service, each
bound to a different set of protocols or a different network address.

tModel data structure:

The tModel is the last core data type, but potentially the most difficult to
grasp. tModel stands for technical model.
A tModel is a way of describing the various business, service, and
template structures stored within the DDI registry. Any abstract concept
can be registered within UDDI as a tModel. For instance, if you define a
new WSDL port type, you can define a tModel that represents that port
type within UDDI. Then, you can specify that a given business service
implements that port type by associating the tModel with one of that
business service's binding templates.

Here is an example of A tModel representing the HelloWorldInterface port type

publisherAssertion data structure:

This is a relationship structure putting into association two or

more businessEntity structures according to a specific type of
relationship, such as subsidiary or department The
publisherAssertion structure consists of the three elements
fromKey (the first businessKey), toKey (the second
businessKey) and keyedReference.

The keyedReference designates the asserted relationship type in terms of a keyName keyValue
pair within a tModel, uniquely referenced by a tModelKey
support for categorization in UDDI Registries
UDDI Categories
A UDDI repository contains entries about businesses, the services these businesses provide, and
information on how those services can be accessed. Modeled after a phone book, a UDDI
directory has three categories:

• White pages contain basic information about a service provider, including the provider's
name, a text description of the business (potentially in multiple languages), contact
information (phone number, address, etc.), and other unique identifiers such as the Dun &
Bradstreet (D&B) rating and the D&B D-U-N-S Number.

• Yellow pages include the classification of either the provided service or the registered
company using standard taxonomies. Examples include

• Standard Industrial Code (SIC)

• North American Industrial Classification System (NAICS): a classification

scheme specific to the United States, Canada, and Mexico

• Universal Standards Products and Services Classifications (UNSPSC): an open

global standard used extensively by catalog and procurement systems

• Geographic taxonomies: location-based classifications; for example, US-CA

indicates a business in California

• Green pages contain the technical entries for the Web Services—the address of the Web
Service, the parameters, etc.

The entries in a UDDI directory are not limited to Web Services; UDDI entries can be for
services based on email, FTP, CORBA, RMI, or even the telephone.

UDDI Data Model

The UDDI data model includes an XML schema that provides four major elements:

• The businessEntity element represents the owner of the services and includes the
business name, description, address, contact information categories, and identifiers. Upon
registration, each business receives a unique businessKey value that is used to correlate
with the business's published service. The categories and identifiers can be used to specify
details about a business, such as its NAICS, UNSPSC, and D-U-N-S codes—values that can
be useful when performing searches.

• The businessService element has information about a single Web Service or a group of
related ones, including the name, description, owner (cross-referenced with a
unique businessKey value of the associated businessEntity element), and a list of
optional bindingTemplate elements. Each service is uniquely identified by
a serviceKey value.

• The bindingTemplate element represents a single service and contains all the required
information about how and where to access the service (e.g., the URL if it is a Web
Service). Each binding template is uniquely identified by a bindingKey value. l The service
does not have to be a Web Service; it can be based on email (SMTP), FTP, or even the fax.

• The tModel element (shortened from "technical model" and also known as the service
type) is primarily used to point to the external specification of the service being provided.
For a Web Service, this element (more specifically, the overviewURL child element)
should ideally point to the WSDL document that provides all the information needed to
unambiguously describe the service and how to invoke it. If two services have the same
tModel key value, then the services can be considered equivalent (thus allowing the
requester potentially to switch from one serv-ice provider to another). Here is a useful
metaphor: a tModel that can be thought of as an interface for which there can be multiple
implementations, presumably from different companies since it does not make sense for a
firm to implement more than one service for a given tModel (just as it would not make
sense for a single class to implement the same interface in different ways).

UDDI Usage Scenarios

As mentioned earlier, a service-oriented architecture involves three roles: client, provider, and
service broker. To illustrate the flexibility of the UDDI model, we'll use the example of the
MegaBucks Consortium.

MegaBucks Consortium (a financial consortium) wants to create a standard way of valuing small
retail businesses and then publish this information so that its member firms can implement Web
Services to conform to that standard. In this example, the consortium operates a private registry
(see the next section on types of UDDI registries for more information on private versus public
registries). To allow its members to access this standard, the consortium needs to
• Produce a WSDL file to define the specifications to which a valuation service should
adhere. The provider of the valuation serv-ice would most likely be a member of the
financial consortium.

• Publish the WSDL file at a public location (for

example, www.megabucks.org/valuation.wsdl on its server, or any publicly accessible
location).

• Create a tModel to represent the valuation service specifications (these specifications are
described in the WSDL file mentioned in our first bullet point).

• Publish the tModel in its registry. As part of the publishing process, the registry issues a
unique key for the tModel (5000X, for example6) and stores the URL of the WSDL file in
the overviewURL child element of the tModel element.

Publishing API

Users discover web services by pointing a browser at the computer that is running Business
Central Server and requesting a list of available services. When you publish a web service, it's
immediately available over the network for authenticated users. All authorized users have access
to metadata for Business Central web services, but only users who have sufficient Business
Central permissions can access actual data.

Depending on the type of web service (API, OData, or SOAP), the web service might need to be
published to be available for users.

Publishing a API Web Service

If the API stack has been enabled for the Business Central environment, then no additional setup
is needed to make an API web service available.

The API stack is enabled by default in Business Central online. For more information on how to
enable APIs for on-premises environments, please visit Enabling the APIs for Dynamics 365
Business Central.

Creating and Publishing an OData or SOAP Web Service

You can set up a SOAP or OData based web service in the client. You must then publish the web
service so that it's available to service requests over the network.

The following steps explain how to create and publish a web service.

1. Open the client, such as a browser at https://businesscentral.dynamics.com/?.

2. Choose the icon, enter Web Services, and then choose the related link.
3. In the Web Services page, choose New.
4. In the Object Type column, select Codeunit, Page, or Query.

Publishing information to a UDDI Registry

The Publish to UDDI Settings dialog is used to publish information to a UDDI registry. You can
do the following:

• Publish a

API Gateway

WSDL to a UDDI registry

• Publish a

API Gateway

endpoint as a BindingTemplate in a Business Service in the UDDI Registry

• Overwrite an existing Business Service in the UDDI registry with corresponding WSDL
information from the

API Gateway

1)If any API Gateway endpoint information (for example, cluster hostname or port settings) is
changed after the API Gateway has published to UDDI, the API Gateway will automatically
update UDDI so that it contains the correct API Gateway endpoint URLs. You can control this
behaviour using the uddi.auto_republish cluster property. By default, this property is "true"
enables auto update. Set it to "false" to disable the automatic update

(2) If service entity ID resolution is disabled in the Service Resolution Settings dialog, then any
service URLs published to UDDI by the

API Gateway will not resolve if consumed.

searching information in a UDDI Registry

The Search UDDI dialog allows you to search a UDDI registry while performing the following
tasks:
• When publishing a SOAP web service, you can enter either the URL or file path to the
WSDL document. If a UDDI registry has been configured, you can also search the UDDI
to retrieve the appropriate URL.
• When publishing a business service, you can search a UDDI registry for a specific
business entity.

To search a UDDI registry:

1. Do one of the following:

• Click [UDDI] button in Step 1 of the Publish SOAP Web Service Wizard. If the
[UDDI] button is not visible, then no UDDI registries were configured.
•
• Click the [Select] button on the [UDDI] tab of the Service Properties dialog.

The Search UDDI dialog is displayed

deleting information in a UDDI Registry

You can use the UDDI registry user interface to edit or delete the businesses and technical
models that you own, for example, to add services to businesses.

Before you begin

Ensure that the UDDI registry application is started and the UDDI registry user console is
displayed.

About this task

To use the UDDI registry user interface (also referred to as the UDDI registry user console) to
edit or delete the businesses and technical models that you own, or add services to businesses,
use the following steps.

Procedure

1. In the UDDI registry console, activate the Publish pane. Either click the Publish tab, or
click the Publish link at the beginning of the page or on the Welcome page.
2. In the Registered Information section on the Publish tab, click Show owned entities to
show the businesses and technical models that you registered in the UDDI registry.
3. Optional: To delete a business or a technical model, click Delete in the Actions column
for that entity.

When you delete a technical model, it is hidden, rather than physically deleted, as
specified by the UDDI Version 3.0 specification. If you click Shown owned entities, the
technical model is still displayed, but if you use the Find function, the technical model is
not displayed. All other entities are deleted from the UDDI registry in the usual way.
4. Optional: To edit a business or technical model, click Edit in the Actions column for that
entity, enter the required details, then click Update entity to save the changes in the
UDDI registry.
5. Optional: To add a service to a business, click Add service in the Actions column for
that business. Enter the details, then click Add Service to publish the service to the
UDDI registry.

The service details are displayed.

limitations of UDDI

Limitations of UDDI
• No "official" organization is controlling its development.
• The specification may change significantly in future versions.
• Data reliability.
UNIT V

REST: Representational State Transfer: Messages, HTTP Request and format, HTTP Response
and format, Query Parameters, Protocol Semantics of HTTP(GET, PUT, POST, DELETE,
HEAD, OPTIONS, TRACE) , REST vs SOAP..

REST (REpresentational State Transfer) is an architectural style for developing web services.
REST is popular due to its simplicity and the fact that it builds upon existing systems and
features of the internet's Hypertext Transfer Protocol (HTTP) in order to achieve its objectives,
as opposed to creating new standards, frameworks and technologies.

Advantages and disadvantages of REST

There are several advantages to using REST. They are as follows:

• Resource-based. A primary benefit of using REST, from both a client and server
perspective, is that REST interactions are based on constructs which are familiar to anyone
accustomed to using HTTP. Employing a resource-based approach, REST defines how
developers interact with web services.

• Communication. REST-based interactions communicate their status through numerical

HTTP status codes. REST APIs use these HTTP status codes to detect errors and ease the
API monitoring process. They include the following:

• 404 error indicates that a requested resource wasn't found;

• 401 status response code is triggered by an unauthorized request;

• 200 status response code indicates that a request was successful; and

• 500 error signals an unrecoverable application fault on the server.

• Familiarity. Most developers are already familiar with key elements of the REST
architecture, such as Secure Sockets Layer (SSL) encryption and Transport Layer Security
(TLS).

• Language-independent. When creating RESTful APIs or web services, developers can

employ any language that uses HTTP to make web-based requests. This capability makes it
easy for programmers to choose the technologies they prefer to work with and that best suit
their needs.

• Pervasive. The popularity of REST is due to its widespread use in both server- and
client-side implementations. For example, on the server side, developers can employ REST-
based frameworks, including Restlet and Apache CXF. On the client side, developers can
employ a variety of frameworks (i.e., jQuery, Node.js, Angular, EmberJS, etc.) and invoke
RESTful web services using standard libraries built into their APIs.

• Web APIs. When it comes to caching, RESTful services employ effective HTTP
mechanisms. For example, by providing many endpoints, a REST API makes it ea
HTTP Request and format in REST

The RESTful HTTP Requests are categorized according to method types as the following:

• POST Method
• GET Method
• PUT Method
• DELETE Method

POST Method

The RESTful HTTP Request POST method is equivalent to Create functions and INSERT SQL statement.

The following example is to insert a new partner, Partner1, in ConfigStore database.

HTTP Example
Message
Type

Reques http://localhost:8090/tpmRest/v1/participants/participant?isHost=false&name=par
tner1&isActive=true
t

•
Respon Successful operation response:{"result":"Operate successfully"}
se • Failed operation response:{"errorMessage":"XXXXXX"}

GET Method

The RESTful HTTP Request GET method is equivalent to the Retrieve functions and Select SQL statement.

This following example is to retrieve values of enabled EZComm protocol of partner Buyer:
HTTP Example
Message
Type

Reques http://localhost:8090/tpmRest/v1/participants/enabledProtocolPropertyValues?par
ticipantName=Buyer
t &protocol=EZComm&names=["AllowOverrideFilename","dupDetectOutbound","dupDetectI
nbound"]

Respon {"result": [ false, false, false ]}

This following example is to retrieve enabled EZComm protocol property names from a partner:

HTTP Example
Message
Type

Request http://localhost:8090/tpmRest/v1/participants/partnerpropertydefinitions?proto
col=EZComm

Respons {"result":[{"defaultValue":null,"displayName":"Allow override of filename via

HTTP parameter","name":"AllowOverrideFilename","type":"boolean"},
e {"defaultValue":null,"displayName":"Duplicate Detection for
Outbound","name":"dupDetectOutbound","type":"boolean"},
{"defaultValue":null,"displayName":"Duplicate Detection for
Inbound","name":"dupDetectInbound","type":"boolean"},
{"defaultValue":null,"displayName":"Use tibXML
Packaging","name":"tibXMLPublicMsgFormat","type":"boolean"},
{"defaultValue":null,"displayName":"Store and Forward Authentication
Mode","name":"SFAuthenticationMode","type":"string"},
{"defaultValue":null,"displayName":"Store and Forward Authentication Mode
Proxy Agent","name":"ProxySFAuthenticationMode","type":"string"} ]}

This following example is to retrieve enabled EZComm protocol transport properties of partner Partner1:

HTTP Example
Message
Type

Reque http://localhost:8090/tpmRest/v1/participants/transports/all?participantName=pa
rtner1&protocolName=EZComm
st

Respo {"result":[{"name":"file","type":"FILE"},{"name":"http","type":"HTTP"}]}

nse
This following example is to retrieve the reference value of the FileScriptFile property of a File transport named
file under the EZComm protocol for partner Partner1:

Note: The file content data object, FileScriptsFile, without suffix, TPM REST API processes the request as
retrieving file content data object with .reference suffix.

HTTP Example
Messag
e Type

Reque http://localhost:8090/tpmRest/v1/participants/transportPropertyValues?participan
tName=partner1&protocolName=EZComm& transportName=file&names=["FileScriptsFile"]
st

Respo {"result":["c:/temp/rest/db.properties"]}
nse Note: TPM REST API responds with the according file content reference.

This following example is to retrieve the reference value of the FileScriptFile property of a File transport named
file under the EZComm protocol for partner Partner1:

Note: The file content data object, FileScriptsFile, with explicit .reference suffix, TPM REST API responds
with the according file content reference.

HTTP Example
Message
Type

Reques http://localhost:8090/tpmRest/v1/participants/transportPropertyValues?particip
antName=partner1
t &protocolName=EZComm&transportName=file&names=["FileScriptsFile.reference"]

Respon {"result":["c:/temp/rest/db.properties"]}
se
Note: TPM REST API responds with the according file content reference.

This following example is to retrieve the content value of the FileScriptFile property of a File transport named
file under the EZComm protocol for partner Partner1:

Note: The file content data object, FileScriptsFile, with explicit .content suffix, TPM REST API responds with
the file content.
HTTP Response and format,

The appliance returns responses to REST management interface requests.

When you send a REST request, the appliance responds with a structured response in JSON format. The
exact structure of the response depends on the resource and URI of the request, but all responses are
similar.

The response includes all available resources from any point within the API. It includes the resources by
embedding a _links element within the JSON response, which contains pointers to accessible
resources, including possible documentation. You can then target the resources within
the _links element in your subsequent REST management interface requests.

For example, when you specify a GET request for the REST API root
(https://example.com:5554/mgmt/), the response consists of the resources available that is
structured as a list of fields and values:

Query Parameters

You can use query parameters to control what data is returned in endpoint responses.

The sections below describe query parameters that you can use to control the set of items and
properties in responses, and the order of the items returned.

Control the set of items returned

To prevent the response from becoming too large, the number of items returned is limited by
default to 250. You can override this value by using the limit query parameter to specify a
different number. For example, the following call limits the number of orders returned to 5:

CopyGET /ccadmin/v1/orders?limit=5

To page through the results, you can use the offset parameter. For example, suppose you have
returned the first group of 250 orders using this call:

CopyGET /ccadmin/v1/orders

You can return the next group of 250 using the following call:

CopyGET /ccadmin/v1/orders?offset=250

The default value of offset is 0, which means the listing begins with the first item. So
setting offset to 250 means the listing begins with the 251st item.
You can use limit and offset together. For example, to return the 401st through 600th order:

CopyGET /ccadmin/v1/orders?limit=200&offset=400

Control the set of properties returned

Another way to reduce the size of responses is to return only certain properties. For example,
products can have a large number of properties, but you may need only certain ones.

You can use the fields parameter to restrict the set of properties returned to only those you
explicitly specify. The properties are specified as a comma-separated list. For example, to return only
the id and displayName properties of products

Protocol Semantics of HTTP(GET, PUT, POST, DELETE, HEAD, OPTIONS, TRACE)

HTTP request methods

HTTP defines a set of request methods to indicate the desired action to be performed for a
given resource. Although they can also be nouns, these request methods are sometimes
referred to as HTTP verbs. Each of them implements a different semantic, but some common
features are shared by a group of them: e.g. a request method can be safe, idempotent,
or cacheable.

GET

The GET method requests a representation of the specified resource. Requests

using GET should only retrieve data.

HEAD

The HEAD method asks for a response identical to a GET request, but without the
response body.

POST

The POST method submits an entity to the specified resource, often causing a change in
state or side effects on the server.

PUT

The PUT method replaces all current representations of the target resource with the
request payload.

DELETE
The DELETE method deletes the specified resource.

CONNECT

The CONNECT method establishes a tunnel to the server identified by the target resource.

OPTIONS

The OPTIONS method describes the communication options for the target resource.

TRACE

The TRACE method performs a message loop-back test along the path to the target
resource.

PATCH

The PATCH method applies partial modifications to a resource.

1. HTTP GET

Use GET requests to retrieve resource representation/information only – and not modify it in
any way. As GET requests do not change the resource’s state, these are said to be safe methods.

Additionally, GET APIs should be idempotent. Making multiple identical requests must
produce the same result every time until another API (POST or PUT) has changed the state of
the resource on the server.

If the Request-URI refers to a data-producing process, it is the produced data that shall be
returned as the entity in the response and not the source text of the process, unless that text
happens to be the output of the process.

1.1. GET API Response Codes

• For any given HTTP GET API, if the resource is found on the server, then it must return
HTTP response code 200 (OK) – along with the response body, which is usually either
XML or JSON content (due to their platform-independent nature).

• In case the resource is NOT found on the server then API must return HTTP response
code 404 (NOT FOUND).

• Similarly, if it is determined that the GET request itself is not correctly formed then the
server will return the HTTP response code 400 (BAD REQUEST).
2. HTTP POST

Use POST APIs to create new subordinate resources, e.g., a file is subordinate to a directory
containing it or a row is subordinate to a database table.

When talking strictly about REST, POST methods are used to create a new resource into the
collection of resources.

Responses to this method are not cacheable unless the response includes appropriate Cache-
Control or Expires header fields.

Please note that POST is neither safe nor idempotent, and invoking two identical POST
requests will result in two different resources containing the same information (except resource
ids).

2.1. POST API Response Codes

• Ideally, if a resource has been created on the origin server, the response SHOULD be
HTTP response code 201 (Created) and contain an entity that describes the status of the
request and refers to the new resource, and a Location header.

• Many times, the action performed by the POST method might not result in a resource that
can be identified by a URI. In this case, either HTTP response code 200 (OK) or 204 (No
Content) is the appropriate response status.

3. HTTP PUT

Use PUT APIs primarily to update an existing resource (if the resource does not exist, then API
may decide to create a new resource or not).

If the request passes through a cache and the Request-URI identifies one or more currently
cached entities, those entries SHOULD be treated as stale. Responses to PUT method are not
cacheable.

3.1. PUT API Response Codes

• If a new resource has been created by the PUT API, the origin server MUST inform the
user agent via the HTTP response code 201 (Created) response.

• If an existing resource is modified, either the 200 (OK) or 204 (No Content) response
codes SHOULD be sent to indicate successful completion of the request.

4. HTTP DELETE
As the name applies, DELETE APIs delete the resources (identified by the Request-URI).

DELETE operations are idempotent. If you DELETE a resource, it’s removed from the
collection of resources.

Some may argue that it makes the DELETE method non-idempotent. It’s a matter of discussion
and personal opinion.

If the request passes through a cache and the Request-URI identifies one or more currently
cached entities, those entries SHOULD be treated as stale. Responses to this method are not
cacheable.

4.1. DELETE API Response Codes

• A successful response of DELETE requests SHOULD be an HTTP response code 200

(OK) if the response includes an entity describing the status.

• The status should be 202 (Accepted) if the action has been queued.

• The status should be 204 (No Content) if the action has been performed but the response
does not include an entity.

• Repeatedly calling DELETE API on that resource will not change the outcome –
however, calling DELETE on a resource a second time will return a 404 (NOT FOUND)
since it was already removed.

REST: representational state transfer

REST is a set of architectural principles attuned to the needs of lightweight web

services and mobile applications. Because it's a set of guidelines, it leaves the implementation of
these recommendations to developers.

When a request for data is sent to a REST API, it’s usually done through hypertext transfer
protocol (commonly referred to as HTTP). Once a request is received, APIs designed for REST
(called RESTful APIs or RESTful web services) can return messages in a variety of formats:
HTML, XML, plain text, and JSON. JSON (JavaScript object notation) is favored as a message
format because it can be read by any programming language (despite the name), is human- and
machine-readable, and is lightweight. In this way, RESTful APIs are more flexible and can be
easier to set up.

An application is said to be RESTful if it follows 6 architectural guidelines. A RESTful

application must have:

1. A client-server architecture composed of clients, servers, and resources.

2. Stateless client-server communication, meaning no client content is stored on the server
between requests. Information about the session’s state is instead held with the client.

3. Cacheable data to eliminate the need for some client-server interactions.

4. A uniform interface between components so that information is transferred in a

standardized form instead of specific to an application’s needs. This is described by Roy
Fielding, the originator of REST, as “the central feature that distinguishes the REST
architectural style from other network-based styles.”

5. A layered system constraint, where client-server interactions can be mediated by

hierarchical layers.

6. Code on demand, allowing servers to extend the functionality of a client by transferring

executable code (though also reducing visibility, making this an optional guideline).

REST vs SOAP..

SOAP: simple object access protocol

SOAP is a standard protocol that was first designed so that applications built with different
languages and on different platforms could communicate. Because it is a protocol, it imposes
built-in rules that increase its complexity and overhead, which can lead to longer page load
times. However, these standards also offer built-in compliances that can make it preferable for
enterprise scenarios. The built-in compliance standards include security, atomicity, consistency,
isolation, and durability (ACID), which is a set of properties for ensuring reliable database
transactions.

Common web service specifications include:

• Web services security (WS-security): Standardizes how messages are secured and
transferred through unique identifiers called tokens.

• WS-ReliableMessaging: Standardizes error handling between messages transferred

across unreliable IT infrastructure.

• Web services addressing (WS-addressing): Packages routing information as metadata

within SOAP headers, instead of maintaining such information deeper within the
network.

• Web services description language (WSDL): Describes what a web service does, and
where that service begins and ends.

When a request for data is sent to a SOAP API, it can be handled through any of the application
layer protocols: HTTP (for web browsers), SMTP (for email), TCP, and others. However, once a
request is received, return SOAP messages must be returned as XML documents—a markup
language that is both human- and machine-readable. A completed request to a SOAP API is not
cacheable by a browser, so it cannot be accessed later without resending to the API.

Enterprise Slides
No ratings yet
Enterprise Slides
318 pages
From Mainframe To Cloud Computing: A Study of Programming Paradigms With The Evolution of Client-Server Architecture
No ratings yet
From Mainframe To Cloud Computing: A Study of Programming Paradigms With The Evolution of Client-Server Architecture
7 pages
Introduction of Distributed Computing
No ratings yet
Introduction of Distributed Computing
8 pages
WS&SOA
No ratings yet
WS&SOA
59 pages
Client Server Architecture - Tutorial
0% (2)
Client Server Architecture - Tutorial
118 pages
I-Mid Distributed Computing - Doc2
No ratings yet
I-Mid Distributed Computing - Doc2
17 pages
WSPPT Unit 1-4
No ratings yet
WSPPT Unit 1-4
169 pages
Unit 1
No ratings yet
Unit 1
71 pages
Untitled
No ratings yet
Untitled
296 pages
Unit2 B
No ratings yet
Unit2 B
22 pages
Cloud Computing Notes
No ratings yet
Cloud Computing Notes
21 pages
DISTRIBUTED SYSTEMS - Dis Unit 1-5
No ratings yet
DISTRIBUTED SYSTEMS - Dis Unit 1-5
29 pages
Unit-1 Wssoa
No ratings yet
Unit-1 Wssoa
30 pages
Client/Server Computing: Operating Systems: Internals and Design Principles, 6/E
No ratings yet
Client/Server Computing: Operating Systems: Internals and Design Principles, 6/E
79 pages
EPDA
No ratings yet
EPDA
25 pages
Distributed CS571
No ratings yet
Distributed CS571
36 pages
WINSEM2024-25 SWE4002 ETH VL2024250503219 2024-12-18 Reference-Material-I
No ratings yet
WINSEM2024-25 SWE4002 ETH VL2024250503219 2024-12-18 Reference-Material-I
18 pages
Concept Notes: Client Server Computing
No ratings yet
Concept Notes: Client Server Computing
7 pages
The Advantages of Client/Server Computing
No ratings yet
The Advantages of Client/Server Computing
5 pages
Chapter 1
No ratings yet
Chapter 1
28 pages
Distributed System Models
No ratings yet
Distributed System Models
39 pages
Lecture 11 - SDaA
No ratings yet
Lecture 11 - SDaA
35 pages
CC QB1 Solved
No ratings yet
CC QB1 Solved
9 pages
CH 4 Distributed System
No ratings yet
CH 4 Distributed System
6 pages
Gartner Market Guide For Network Detection and Response 2022
No ratings yet
Gartner Market Guide For Network Detection and Response 2022
13 pages
Grid and Cloud Computing Notes
100% (3)
Grid and Cloud Computing Notes
20 pages
Cloud Computing Question Ans
No ratings yet
Cloud Computing Question Ans
15 pages
KCS 713 Unit 1 Lecture 6
No ratings yet
KCS 713 Unit 1 Lecture 6
38 pages
DeltaV Mobile Product Data Sheet (PDS)
No ratings yet
DeltaV Mobile Product Data Sheet (PDS)
12 pages
Advanced Java
No ratings yet
Advanced Java
96 pages
Chapter-5 Network Programming
No ratings yet
Chapter-5 Network Programming
22 pages
Client-Server Reviewer
No ratings yet
Client-Server Reviewer
7 pages
Unit 1 WS
No ratings yet
Unit 1 WS
13 pages
Complete Unit 1
100% (1)
Complete Unit 1
14 pages
What Is A Design Pattern?: Distributed Applications Distributed Applications Are
No ratings yet
What Is A Design Pattern?: Distributed Applications Distributed Applications Are
3 pages
Dis Sys Architectures
No ratings yet
Dis Sys Architectures
55 pages
Client-Server Computing: Unit I - Introduction Objective
No ratings yet
Client-Server Computing: Unit I - Introduction Objective
30 pages
Civil 3D and Dynamo: Dynamic Culvert Design and Analysis
No ratings yet
Civil 3D and Dynamo: Dynamic Culvert Design and Analysis
44 pages
UNIT-1 Evolution of Distributed Computing
No ratings yet
UNIT-1 Evolution of Distributed Computing
54 pages
Distributed Systems Lab 1
No ratings yet
Distributed Systems Lab 1
24 pages
Project On Client Server Architecture and Peer To Peer Architecture Submitted by
No ratings yet
Project On Client Server Architecture and Peer To Peer Architecture Submitted by
64 pages
What Is IT Infrastructure and What Are Its Components
No ratings yet
What Is IT Infrastructure and What Are Its Components
7 pages
WS&SOA
No ratings yet
WS&SOA
54 pages
10) Introduction To Web Applications Material
No ratings yet
10) Introduction To Web Applications Material
8 pages
Client Server Architecture (Class Presentation Assignment)
No ratings yet
Client Server Architecture (Class Presentation Assignment)
20 pages
IPT Chapter 1
No ratings yet
IPT Chapter 1
11 pages
Record Client Request Requirements Information Sheet
No ratings yet
Record Client Request Requirements Information Sheet
9 pages
JavaScript - If... Else Statement
No ratings yet
JavaScript - If... Else Statement
4 pages
Web Services Notes
No ratings yet
Web Services Notes
36 pages
03 01 24 - 19 02 59 - DebugLog
No ratings yet
03 01 24 - 19 02 59 - DebugLog
81 pages
Report Final 3.1
No ratings yet
Report Final 3.1
27 pages
Edms User Mnual
No ratings yet
Edms User Mnual
18 pages
Chassis Name Platform Model Name: 4100S Tsumv59 24PHA4100S/67
No ratings yet
Chassis Name Platform Model Name: 4100S Tsumv59 24PHA4100S/67
28 pages
Concepts and Planning Distributed
No ratings yet
Concepts and Planning Distributed
4 pages
J2ee Multitier Architecture431 PDF
No ratings yet
J2ee Multitier Architecture431 PDF
16 pages
SeeGull MX 2.6.5.0 Release Notes Rev Y
No ratings yet
SeeGull MX 2.6.5.0 Release Notes Rev Y
51 pages
Client Server Model
No ratings yet
Client Server Model
8 pages
AOS Practical File1
No ratings yet
AOS Practical File1
74 pages
Aleph 20 Syslib Guide - Search
No ratings yet
Aleph 20 Syslib Guide - Search
21 pages
DMB-6100E IP To Analog Modulator User Manual - Digicast
No ratings yet
DMB-6100E IP To Analog Modulator User Manual - Digicast
26 pages
Introduction To Web Services: Preface
No ratings yet
Introduction To Web Services: Preface
17 pages
Cypress Programmer User Guide
No ratings yet
Cypress Programmer User Guide
28 pages
Kunal's Yaml Tutorial Notes
No ratings yet
Kunal's Yaml Tutorial Notes
12 pages
JAVA Internship
No ratings yet
JAVA Internship
63 pages
Interrupts
No ratings yet
Interrupts
34 pages
8793 IFSEC Global Periodic Table 2020
No ratings yet
8793 IFSEC Global Periodic Table 2020
1 page
Empact Standard Pitch Deck Template Guidance
No ratings yet
Empact Standard Pitch Deck Template Guidance
17 pages
Evolution of Client
No ratings yet
Evolution of Client
3 pages
An Introduction To Near-Field Communication and The Contactless Communication API
No ratings yet
An Introduction To Near-Field Communication and The Contactless Communication API
17 pages
f1 Self Assessment Checklist Doliente
No ratings yet
f1 Self Assessment Checklist Doliente
4 pages
Cics Mock Test III
No ratings yet
Cics Mock Test III
6 pages
Manual - Excel Masterclass 1 - DS7
No ratings yet
Manual - Excel Masterclass 1 - DS7
4 pages
Design Consistent Hashing: The Rehashing Problem
No ratings yet
Design Consistent Hashing: The Rehashing Problem
2 pages
Fundamentals of Data Warehouses
No ratings yet
Fundamentals of Data Warehouses
3 pages
Introduction To Embedded Systems: Printed Book
No ratings yet
Introduction To Embedded Systems: Printed Book
1 page
Device Management in Operating System
No ratings yet
Device Management in Operating System
5 pages
OOP - S2021 - Mid Term Exam
No ratings yet
OOP - S2021 - Mid Term Exam
2 pages
Alpha-Test Questionnaire
No ratings yet
Alpha-Test Questionnaire
4 pages
Cloud Computing
From Everand
Cloud Computing
Dr. Nirvikar Katiyar
No ratings yet
Essays on Infrastructure-as-code
From Everand
Essays on Infrastructure-as-code
Ravi Rajamani
No ratings yet
Cloud Computing Essentials: A Practical Guide with Examples
From Everand
Cloud Computing Essentials: A Practical Guide with Examples
William E. Clark
No ratings yet
Building Desktop Applications with Electron: Definitive Reference for Developers and Engineers
From Everand
Building Desktop Applications with Electron: Definitive Reference for Developers and Engineers
Richard Johnson
No ratings yet
Cloud computing: Moving IT out of the office
From Everand
Cloud computing: Moving IT out of the office
BCS, The Chartered Institute for IT
No ratings yet
Networking Programming with C++: Build Efficient Communication Systems
From Everand
Networking Programming with C++: Build Efficient Communication Systems
Robert Johnson
No ratings yet
Cloud Computing For Noobs
From Everand
Cloud Computing For Noobs
Silas Meadowlark
No ratings yet
A Concise Guide to Microservices for Executive (Now for DevOps too!)
From Everand
A Concise Guide to Microservices for Executive (Now for DevOps too!)
alasdair gilchrist
1/5 (1)
Edge Cloud Operations: A Systems Approach
From Everand
Edge Cloud Operations: A Systems Approach
Larry L Peterson
No ratings yet
Cloud Computing Made Simple: Navigating the Cloud: A Practical Guide to Cloud Computing
From Everand
Cloud Computing Made Simple: Navigating the Cloud: A Practical Guide to Cloud Computing
Poonam Devi
No ratings yet
Cloud Computing: Harnessing the Power of the Digital Skies: The IT Collection
From Everand
Cloud Computing: Harnessing the Power of the Digital Skies: The IT Collection
Christopher Ford
No ratings yet
Computer Science Self Management: Fundamentals and Applications
From Everand
Computer Science Self Management: Fundamentals and Applications
Fouad Sabry
No ratings yet