Introduction to Web Services

Web Services can convert your applications into Web-applications.

Web Services are published, found, and used through the Web.

What You Should Already Know

Before you continue, you should have a basic understanding of the following:

• HTML
• XML

If you want to study these subjects first, find the tutorials on our Home page.

What are Web Services?

• Web services are application components

• Web services communicate using open protocols
• Web services are self-contained and self-describing
• Web services can be discovered using UDDI
• Web services can be used by other applications
• XML is the basis for Web services

How Does it Work?

The basic Web services platform is XML + HTTP.

XML provides a language which can be used between different platforms and programming
languages and still express complex messages and functions.

The HTTP protocol is the most used Internet protocol.

Web services platform elements:

• SOAP (Simple Object Access Protocol)

• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)

We will explain these topics later in the tutorial.

Web Services take Web-applications to the Next Level

By using Web services, your application can publish its function or message to the rest of the world.

Web services use XML to code and to decode data, and SOAP to transport it (using open protocols).
With Web services, your accounting department's Win 2k server's billing system can connect with
your IT supplier's UNIX server.

Web Services have Two Types of Uses

Reusable application-components.

There is things applications need very often. So why make these over and over again?

Web services can offer application-components like: currency conversion, weather reports, or even
language translation as services.

Connect existing software.

Web services can help to solve the interoperability problem by giving different applications a way to
link their data.

With Web services you can exchange data between different applications and different platforms.

Web Services have three basic platform elements: SOAP, WSDL and UDDI.

What is SOAP?
SOAP is an XML-based protocol to let applications exchange information over HTTP.

Or more simple: SOAP is a protocol for accessing a Web Service.

• SOAP stands for Simple Object Access Protocol

• SOAP is a communication protocol
• SOAP is a format for sending messages
• SOAP is designed to communicate via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP is a W3C standard

Read more about SOAP on our Home page.

What is WSDL?
WSDL is an XML-based language for locating and describing Web services.

• WSDL stands for Web Services Description Language

• WSDL is based on XML
• WSDL is used to describe Web services
• WSDL is used to locate Web services
• WSDL is a W3C standard
Read more about WSDL on our Home page.

What is UDDI?
UDDI is a directory service where companies can register and search for Web services.

• UDDI stands for Universal Description, Discovery and Integration

• UDDI is a directory for storing information about web services
• UDDI is a directory of web service interfaces described by WSDL
• UDDI communicates via SOAP
• UDDI is built into the Microsoft .NET platform

Read more about UDDI in our WSDL Tutorial.

Web Services Example

Any application can have a Web Service component.

Web Services can be created regardless of programming language.

A Web Service Example

In the following example we will use ASP.NET to create a simple Web Service that converts the
temperature from Fahrenheit to Celsius, and vice versa:

<%@ WebService Language="VBScript" Class="TempConvert" %>

Imports System
Imports System.Web.Services

Public Class TempConvert :Inherits WebService

<WebMethod()> Public Function FahrenheitToCelsius

(ByVal Fahrenheit As String) As String
dim fahr
fahr=trim(replace(Fahrenheit,",","."))
if fahr="" or IsNumeric(fahr)=false then return "Error"
return ((((fahr) - 32) / 9) * 5)
end function

<WebMethod()> Public Function CelsiusToFahrenheit

(ByVal Celsius As String) As String
dim cel
cel=trim(replace(Celsius,",","."))
if cel="" or IsNumeric(cel)=false then return "Error"
return ((((cel) * 9) / 5) + 32)
end function

end class
This document is saved as an .asmx file. This is the ASP.NET file extension for XML Web Services.

Example Explained
Note: To run this example, you will need a .NET server.

The first line in the example states that this is a Web Service, written in VBScript, and has the class
name "TempConvert":

<%@ WebService Language="VBScript" Class="TempConvert" %>

The next lines import the namespace "System.Web.Services" from the .NET framework:

Imports System
Imports System.Web.Services

The next line defines that the "TempConvert" class is a WebService class type:

Public Class TempConvert :Inherits WebService

The next steps are basic VB programming. This application has two functions. One to convert from
Fahrenheit to Celsius, and one to convert from Celsius to Fahrenheit.

The only difference from a normal application is that this function is defined as a "WebMethod()".

Use "WebMethod()" to convert the functions in your application into web services:

<WebMethod()> Public Function FahrenheitToCelsius

(ByVal Fahrenheit As String) As String
dim fahr
fahr=trim(replace(Fahrenheit,",","."))
if fahr="" or IsNumeric(fahr)=false then return "Error"
return ((((fahr) - 32) / 9) * 5)
end function

<WebMethod()> Public Function CelsiusToFahrenheit

(ByVal Celsius As String) As String
dim cel
cel=trim(replace(Celsius,",","."))
if cel="" or IsNumeric(cel)=false then return "Error"
return ((((cel) * 9) / 5) + 32)
end function

Then, end the class:

end class

Publish the .asmx file on a server with .NET support, and you will have your first working Web
Service.

Look at our example Web Service

ASP.NET Automates the Process
With ASP.NET, you do not have to write your own WSDL and SOAP documents.

If you look closer at our example Web Service, you will see that ASP.NET has automatically created
a WSDL and SOAP request.

Web Services How to Use

Using the Web Service Example

In the previous page we created a Web service.

The FahrenheitToCelsius() function can be tested here: FahrenheitToCelsius

The CelsiusToFahrenheit() function can be tested here: CelsiusToFahrenheit

These functions will send an XML response like this:

<?xml version="1.0" encoding="utf-8" ?>

<string xmlns="http://tempuri.org/">38</string>

Put the Web Service on Your Web Site

Using a form and the HTTP POST method, you can put the web service on your site, like this:

Fahrenheit to Celsius:

Submit

Celsius to Fahrenheit:

Submit

How To Do It
Here is the code to add the Web Service to a web page:

<form
action='http://www.example.com/webservices/tempconvert.asmx/FahrenheitToCelsius'
method="post" target="_blank">
<table>
<tr>
<td>Fahrenheit to Celsius:</td>
<td><input class="frmInput" type="text" size="30" name="Fahrenheit"></td>
</tr>
<tr>
<td></td>
<td align="right"><input type="submit" value="Submit" class="button"></td>
 </tr>
</table>
</form>

<form
action='http://www.example.com/webservices/tempconvert.asmx/CelsiusToFahrenheit'
method="post" target="_blank">
<table>
<tr>
<td>Celsius to Fahrenheit:</td>
<td><input class="frmInput" type="text" size="30" name="Celsius"></td>
</tr>
<tr>
<td></td>
<td align="right"><input type="submit" value="Submit" class="button"></td>
</tr>
</table>
</form>

Substitute the "www.example.com" in the code above with the address of your web site.

Web Services Summary

This tutorial has taught you how to convert your applications into web-applications.

You have learned how to use XML to send messages between applications.

You have also learned how to export a function (create a web service) from your application.

Now You Know Web Services, What's Next?

The next step is to learn about WSDL and SOAP.

WSDL

WSDL is an XML-based language for describing Web services and how to access them.

WSDL describes a web service, along with the message format and protocol details for the web
service.

If you want to learn more about WSDL, please visit our WSDL tutorial.

SOAP

SOAP is a simple XML-based protocol that allows applications to exchange information over HTTP.

Or more simply: SOAP is a protocol for accessing a web service.

If you want to learn more about SOAP, please visit our SOAP tutorial.
Web Services
Normally a Service represents any kind of feature or some piece of
functionality that a specific kind of client can take it from. For
example, a printer service, where the clients are either the
applications or the programs using the printers. Likewise, consumers
of an ATM service are Bank Customers. These are the list of real-world
services goes on in our daily-life.

Web services was first time introduced in EJB2.1, while EJB3.0 made
the web services development easy and more flexible. Here we are
going to describe the general concept of web services and then explain
them how the ejb supports to implement both the web services and
web services client.

Web Services Concept: Web services are the mechanism to develop

a Service-Oriented-Architecture (SOA). SOA is an architectural
approach for designing large scale distributed systems to integrate
heterogeneous application on the service interfaces. Web services
technologies support to the Service-Oriented-Architecture in various
ways. Some of them are illustrated below:

• A service requestor uses the selection criteria to the query registry for finding the
services description.
• A service requestor can bind and use the service if it finds a suitable descriptor.

Web services are used in various fields such converting a temperature

value from Fahrenheit to Celsius. More realistic examples built using
the web services are heterogeneous applications such as billing
application and report generator, interconnected in-house
architectures. A service interface is just like an object interface with a
slight difference that the contract between the interface and the client
is more flexible and the implementation of client and the service is not
much tightly coupled as compared to EJB or other distributed platform.
Looser coupling allows the client and service implementation to run on
various platforms, independently such as Microsoft .NET is capable of
using a Java EE application server to access a service running on it.
From the client's point of view, web services's life cycle is more static
as compared to average objects because web services stay around
rather than pop-up and go away, even if the services are implemented
using the object technology.

Features of Web Services:

Following are the unique features of a Web-Service based application.

• Language Independent
• Operating System Independent

Language Independent:

Let us assume that a Web-Service is running in a remote machine.

Suppose an application (can be a Web-Service also) want to gain the
functionality of the Web-Service by accessing it. It is not that both the
Web-Service and the client application must be built in the same
language or technology. They can be different.

Web Services Standards: The de facto standardized set of web

services can be summarized by using an equation.

Web Services = WSDL + SOAP + UDDI

Lets take a quick look over WSDL and UDDI, but we are not going to
cover these topics here because these are less useful. The requestor
does not necessarily have the registry to know the services and its end
point address. Registry not only supports a simple naming service but
also queries for the services that follow the given predicate.

WSDL: There is no need to write down the xml file. The tool you are
using automatically creates an xml file. A number of things are worth
nothing while using WSDL.

• The service description includes an endpoint address: WSDL is similar to java

interface and an object reference joined together or in other words, we can say
web services don't have distinct identities. Since they are not objects therefore
they must be viewed like objects. It does not have any client visible state therefore
your are not able to compare the two references for equality.
• It uses larger number of concepts than in java: Service provides one or more
ports at an address. Ports are the representation of the service interfaces that binds
to protocols.
• Operations result in terms of input and output messages rather than
parameters and return values:
• Services are bind using SOAP binding:
Building a Web Service with JEE: The creation of the portable and
interoperable distributed components from the web services is not a
trivial task. Either regular Java classes or stateless EJBs can be easily
deployed as web services. Package the Java regular classes in a web
module and EJB web services in normal ejb-jar modules.

Two options are there to deploy an application, you can use one of the
two deployment options given below:

Java Class versus Stateless EJB: It depends upon you whether you
should have a regular Java class or EJBs as your technology to build a
Web Service. We can easily develop java classes than EJBs. Java
classes are pure java objects and do not have the extra baggage that
the EJBs do. One benefit of using EJB is that it supports the features
such as declarative transaction and security. EJB leaves free to the
developer just to concentrate only on applying the business logic
without worrying about the infrastructure services.

Packaging Requirement: Whatever you are using either a regular

Java class or EJB, in both the conditions you need to package several
artifacts into your WAR or ejb-jar accordingly, to expose components
as a Java Web Service. Web Services use the following two packaging
structures based on either regular Java classes or EJBs.

Web app (.war) for a regular Java web service:

/WEB-INF/
web.xml
webservices.xml
oracle-webservices.xml
mapping-file.xml
wsdl/ it is wsdl
file
/classes/(includes
endpoint and bean classes)
/lib/

ejb-jar for an EJB-based web service:

/META-INF/
ejb-jar.xml
webservices.xml
oracle-
webservices.xml
mapping-file.xml
 wsdl/ the wsdl file
ejb classes (includes
endpoint and bean classes)

Lets discuss each of the descriptors and the deployment-time artifacts

one-by-one.

• WSDL: We are not going to discuss about the WSDL any more as we have
already discuss it in the previous section.
• Web Services Deployment Descriptor: webservices.xml is the standard
deployment descriptor that a JEE plateform requires. This descriptor specifies the
description for deployment about the set of web services into the JEE application
server and also their dependencies on the container resources and services. The
mapping.xml file that contains Java-to-WSDL mapping and the service endpoint
interface for the HelloWorld web service is also specified by this deployment
descriptor.
• Endpoint interface: The Web Service endpoint implements the java.rmi.Remote
interface therefore every method of web service endpoint interface must throw the
java.rmi.RemoteException. The deployment descriptor registers to the end point
for the module (ejb-jar.xml) or web.xml. The deployment descriptor (e.g. ejb-
jar.xml) should have the following entry.

<service-endpoint>
oracle.ejb21.ws.HelloServiceInf
</service-endpoint>

Following is the code for the Web Service endpoint for a HelloWorld
web service:

public interface HelloServiceInf

extends java.rmi.Remote {
java.lang.String
sayHello(java.lang.String name)
throws java.rmi.RemoteException;
}

• Vendor-specific deployment descriptors: We can not specify several

implementation-specific reference, such as endpoint addresses, context root in the
Web Services deployment descriptor but we can rather specify the vendor-specific
deployment descriptor. For example if you are using OC4J then an oracle-
webservices.xml file is required to package in WAR or ejb-jar to define the
properties.
• Java-WSDL mapping: Mapping between the WSDL and Java types is defined in
this file. Mapping file does not have any standard name, web services deployment
descriptor defines its name.
Before deploying your component as a web service, first you must
package all these artifacts in the ejb-jar module or in the WAR. Most of
the development tools like Oracle JDeveloper simplifies the
development task of web services simply by mapping files, generating
the deployment descriptor etc. Moreover most of the application
servers provide Web Services assembly tools that fulfill the JEE web
service packaging requirements.

Before understanding the components required to make up a Web

Service and the associated packaging requirements, first you must
deal with the architectural issues when developing a web service.

Approaches to Construct Services: The main thing about building a

Web Service is to identify the service along with its right granularity.
Its depends upon you either you can expose an existing component
that is built as a Java class or EJB and expose it as a service or build
the new service. You can use either top-down or bottom-up approach
while building a new service.

• Top-down approach: While building the services from scratch, this is the most
appropriate approach. With this approach start describing the service with WSDL
instead of jumping right into the implementation. This is the most preferable
approach since services become maintainable, more usable and interoperable due
to the control over the WSDL while deploying your web service, careful
consideration of the operations and message exposed. Several JEE vendors
provide tools to make the approach easier such as Oracle Application Server's
web services assembler generates deployment descriptors, interfaces and skeleton
implementation classes which can be used to build your application.
• Bottom-up approach: This approach is used whenever an existing Java class or
EJB is to be exposed as a Web Service. The reason behind the populalrity of this
approach is that, this approach allows to reuse the existing business logic without
rewriting the applications. While using this approach, you have to create a WSDL
to describe the Web Service along with other deployment descriptors and add a
web service end-point interface for the implementation to which you want to
expose as a Web Service. Tools provided by application servers (such as Oracle
Application Server's web services assembler tool) are used to make the life
simpler by generating the descriptors such as webservices.xml, WSDL and
mapping files for Web Services components free up the developer from manually
creating these files.

Tips for developing Web Services: Here are the some points
that must follow while developing Web Services.
 • Most of the conventional best practices are for JEE applications that are relevant
to Web Services. for example, avoid exposing a component involve in the long-
run transaction as a Web Service.
• Confirm design of your Web Service so that it can create minimum network
traffic.
• Do not overuse Web Services in your applications. Check the necessity to expose
your application as a Web Service.
• Compare your security requirements with the performance of your application as
security comes with the higher cost. Performance of end-to-end security for web
services are quite costly.

To build java based web services, J2EE Blueprint Application ( Java

Adventure Builder) provides a nice blueprint application.

After designing, developing and deploying, we generally create the

associated components to interact with the given service.

Invoking Web Services: Web Service can have the client of any of
the following type: Dynamic Invocation Interface (DII) or dynamic
proxy, static stub.

Building a Web Service client may be complex similar to build a simple

web service. But JEE 1.4 makes it simple to use the web services for
JEE developers from any type of JEE component such as EJB
components or web clients.

Invoking a Web Service is similar to invoking any other resource using

JNDI via the following:

• First define your component by using a "service-ref" element in the deployment

descriptor. For example, if you are accessing the HelloWorldService web service
by using web module then the module's web.xml file may contain the following:

<service-ref>
<service-ref-
name>service/HelloWorldService</service-ref-
name>
<service-
interface>oracle.ws.HelloWorldService</service-
interface>
<wsdl-file>META-
INF/HelloWorldService.wsdl</wsdl-file>
<service-qname>urn:oracle-ws</service-qname>
</service-ref>
 • Allow your application to find Web Service just by specifying the location of the
Web Service in the vendor-specific deployment descriptor.
<service-ref-mapping
name="service/HelloWorldService">
<port-info>
<wsdl-port namespaceURI="urn: HelloWorldService"
localpart="HelloWorldServicePort"/>
<stub-property>
<name>javax.xml.rpc.service.endpoint.address</name>
<value>http://localhost:8888/hello/HelloWorldInf</value>
</stub-property>
</port-info>
</service-ref-mapping>
•
• Package type classes and end-point interface with your application before
deploying it to the server. Make the JNDI lookup to use a Web Service.

InitialContext ctx= new InitialContext();

HelloServiceInf hs = (HelloServiceInf)
ctx.lookup("java:comp/env/service/HelloWorldService");
HelloWorld hello= hs.getHelloWorldServicePort();
String myhello = hs.sayHello("Zulfiqar") ;

Simplifying SOA Development with JEE 5.0: Building service-

oriented applications are rather difficult with JEE, JEE 5.0 is designed
to simplify the development by using Web Services Metadata
annotations defined by JSR 181. Web Services Metadata and EJB 3.0
both are used to provide friendly environment to the developer.

To develop a simple Java Web Service in JEE 1.4, several Web Service
artifacts such as mapping files, WSDL, proprietary web services
deployment descriptor and several verbose standard are designed in
JEE 5.0. Web Services Metadata specification receives a by default
configuration approach similar to EJB 3.0 for simplifying the
development process. Web Services Metadata annotation process
generates these files for you so just concentrate on the
implementation class.

Following is the Java Web Service developed using Web Services

Metadata:

package oracle.jr181.demo;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService(name =
"HelloWorldService",
targetNamespace =
"http://hello/targetNamespace" )
public class HelloWorldService {
@WebMethod public String
sayhello(String name ) {
return "Hello” +name+ “ from
jws";
}
}

EJB 3.0 uses regular Java classes to simplify the development process.
EJB-based Web Services developed using EJB 3.0 and Web Services
Metadata, are much simpler. HelloWorld EJB is the example given
below developed by using EJB 3.0 and Web Services Metadata. Don't
worry while creating WSDL, deployment descriptors, etc., since the
application server generates these artifacts during deployment.

package oracle.ejb30.ws;
import javax.ejb.Remote;
import javax.jws.WebService;
@WebService
public interface HelloServiceInf extends
java.rmi.Remote{
@WebMethod java.lang.String
sayHello(java.lang.String name)
throws java.rmi.RemoteException;
}

Implementation of HelloWorld EJB using EJB 3.0 is given below:

package oracle.ejb30.ws;
import java.rmi.RemoteException;
import javax.ejb.Stateless;
@Stateless(name="HelloServiceEJB")
public class HelloServiceBean
implements HelloServiceInf {
public String sayHello(String name) {
return("Hello "+name +" from first
EJB3.0 Web Service");
}
}
The above example demonstrates the simplification of service
development while simplifying by using Web Services Metadata and
EJB 3.0.

Conclusion

This articles gives you the understanding about the basics of building
Web Services using the J2EE platform. You can build and deploy your
Web Services in J2EE-compliant application servers such as Sun Java
System Application Sever, Oracle Application Server 10g, etc.

Web service
Web services architecture.

Web services in a service-oriented architecture.

A Web Service (also Webservice) is defined by the W3C as "a

software system designed to support interoperable machine-to-
machine interaction over a network. It has an interface described in a
machine-processable format (specifically WSDL). Other systems
interact with the Web service in a manner prescribed by its description
using SOAP-messages, typically conveyed using HTTP with an XML
serialization in conjunction with other Web-related standards." [1] Web
services are frequently just Internet Application Programming
Interfaces (API) that can be accessed over a network, such as the
Internet, and executed on a remote system hosting the requested
services. Other approaches with nearly the same functionality as web
services are Object Management Group's (OMG) Common Object
Request Broker Architecture (CORBA), Microsoft's Distributed
Component Object Model (DCOM) or Sun Microsystems's Java/Remote
Method Invocation (RMI).

In common usage the term refers to clients and servers that

communicate over the Hypertext Transfer Protocol (HTTP) protocol
used on the Web. Such services tend to fall into one of two camps: Big
Web Services[citation needed] and RESTful Web Services.
"Big Web Services" use Extensible Markup Language (XML) messages
that follow the Simple Object Access Protocol (SOAP) standard and
have been popular with traditional enterprise. In such systems, there
is often a machine-readable description of the operations offered by
the service written in the Web Services Description Language (WSDL).
The latter is not a requirement of a SOAP endpoint, but it is a
prerequisite for automated client-side code generation in many Java
and .NET SOAP frameworks (frameworks such as Spring, Apache Axis2
and Apache CXF being notable exceptions). Some industry
organizations, such as the WS-I, mandate both SOAP and WSDL in
their definition of a Web service.

More recently, REpresentational State Transfer (RESTful) Web services

have been regaining popularity, particularly with Internet companies.
By using the PUT, GET and DELETE HTTP methods, alongside POST,
these are often better integrated with HTTP and web browsers than
SOAP-based services. They do not require XML messages or WSDL
service-API definitions.

A highly dynamic and loosely coupled environment increases not only

the probability of deviation situations that occur during the execution
of composite services, but also the complexity in exception handling.
Due to the distributed nature of SOA, loosely coupled feature of web
services, the monitoring and exception handling issues about web
services in SOA context is still an open research issue.

When running composite web services, each sub service can be

considered autonomous. The user has no control over these services.
Also the web services themselves are not reliable; the service provider
may remove, change or update their services without giving notice to
users. The reliability and fault tolerance is not well supported; faults
may happen during the execution. Exception handling in the context of
web services is still an open research issue.

Specifications
+Profiles

To improve interoperability of Web Services, the WS-I publishes

profiles.. A profile is a set of core specifications (SOAP, WSDL, ...) in a
specific version (SOAP 1.1, UDDI 2, ...) with some additional
requirements to restrict the use of the core specifications. The WS-I
also publishes use cases and test tools to help the deployment of
profile compliant Web Services. The WS is the editing web service.

Additional specifications, WS

Some specifications have been developed or are currently being

developed to extend Web Services capabilities. These specifications
are generally referred to as WS-*. Here is a non-exhaustive list of
these WS-* specifications.

WS-Security
Defines how to use XML Encryption and XML Signature in SOAP to secure
message exchanges, as an alternative or extension to using HTTPS to secure the
channel.
WS-Reliability
An OASIS standard protocol for reliable messaging between two Web services.
WS-Transaction
A way of handling transactions.
WS-Addressing
Is a standard way to insert address in the SOAP header.

Some of these additional specifications have come from the W3C.

There is much discussion around the organization's participation, as
the general Web and the Semantic Web paradigms appear to be at
odds with much of the Web Services vision. This has surfaced most
recently in February 2007, at the Web of Services for the Enterprise
workshop. Some of the participants advocated a withdrawal of the
W3C from further WS-* related work, and a focus on the core Web.
[citation needed]

In contrast, OASIS has standardized many Web service extensions,

including Web Services Resource Framework and WSDM.

Styles of use
Web services are a set of tools that can be used in a number of
ways. The three most common styles of use are RPC, SOA and REST.

Remote procedure calls

Architectural elements involved in the XML-RPC.

RPC Web services present a distributed function (or method) call
interface that is familiar to many developers. Typically, the basic unit
of RPC Web services is the WSDL operation.

The first Web services tools were focused on RPC, and as a result this
style is widely deployed and supported. However, it is sometimes
criticised for not being loosely coupled, because it was often
implemented by mapping services directly to language-specific
functions or method calls. Many vendors felt this approach to be a
dead end, and pushed for RPC to be disallowed in the WS-I Basic
Profile.

Service-oriented architecture

Web services can also be used to implement an architecture according

to Service-oriented architecture (SOA) concepts, where the basic
unit of communication is a message, rather than an operation. This is
often referred to as "message-oriented" services.

SOA Web services are supported by most major software

vendors and industry analysts. Unlike RPC Web services, loose
coupling is more likely, because the focus is on the "contract"
that WSDL provides, rather than the underlying implementation
details.

Middleware Analysts use Enterprise Service Buses which combine

message-oriented processing and Web Services to create an Event-
driven SOA. One example of an open-source ESB is Mule.
Representational state transfer

Finally, Representational State Transfer (REST) attempts to

describe architectures which use HTTP or similar protocols by
constraining the interface to a set of well-known, standard operations
(like GET, POST, PUT, DELETE for HTTP). Here, the focus is on
interacting with stateful resources, rather than messages or
operations. An architecture based on REST (one that is 'RESTful') can
use WSDL to describe SOAP messaging over HTTP, which defines the
operations, can be implemented as an abstraction purely on top of
SOAP (e.g., WS-Transfer), or can be created without using SOAP at all.

WSDL version 2.0 offers support for binding to all the HTTP request
methods (not only GET and POST as in version 1.1) so it enables a
better implementation of RESTful Web services.[2] However, support
for this specification is still poor in software development kits, which
often offer tools only for WSDL 1.1.

Criticisms
Critics of non-RESTful Web services often complain that they are too
complex[3] and based upon large software vendors or integrators,
rather than open source implementations.

One big concern of the REST Web Service developers is that the SOAP
WS toolkits make it easy to define new interfaces for remote
interaction, often relying on introspection to extract the WSDL and
service API from Java, C# or VB code. This is viewed as a feature by
the SOAP stack authors (and many users) but it is feared that it can
increase the brittleness of the systems, since a minor change on the
server (even an upgrade of the SOAP stack) can result in different
WSDL and a different service interface. The client-side classes that can
be generated from WSDL and XSD descriptions of the service are often
similarly tied to a particular version of the SOAP endpoint and can
break if the endpoint changes or the client-side SOAP stack is
upgraded. Well designed SOAP endpoints (with handwritten XSD and
WSDL) do not suffer from this but there is still the problem that a
custom interface for every service requires a custom client for every
service.

There are also concerns about performance due to Web services' use
of XML as a message format and SOAP and HTTP in enveloping and
transport, however emerging XML parsing/indexing technologies, such
as VTD-XML, promise to address those XML-related performance
issues.

Similar efforts
Several other approaches exist to solve the set of problems that Web
services address, both preceding and contemporary to it. RMI was one
of many middleware systems that have seen wide deployment. More
ambitious efforts like CORBA and DCOM attempted to effect distributed
objects, which Web services implementations sometimes try to mimic.

More basic efforts include XML-RPC, a precursor to SOAP that was only
capable of RPC, and various forms of HTTP usage without SOAP.
List of Web service specifications
From Wikipedia, the free encyclopedia
Jump to: navigation, search

There are a variety of specifications associated with web services.

These specifications are in varying degrees of maturity and are
maintained or supported by various standards bodies and entities.
Specifications may complement, overlap, and compete with each
other. Web service specifications are occasionally referred to
collectively as "WS-*", though there is not a single managed set of
specifications that this consistently refers to, nor a recognized owning
body across them all. The reference term "WS-*" is more of a general
nod to the fact that many specifications are named with "WS-" as their
prefix. This page includes many of the specifications that might be
considered a part of "WS-*".

This list is incomplete; you can help by expanding it.

Contents
[hide]

• 1 Web Service Standards Listings

• 2 XML Specifications
• 3 Messaging Specifications
• 4 Metadata Exchange Specifications
• 5 Security Specifications
• 6 Privacy
• 7 Reliable Messaging Specifications
• 8 Resource Specifications
• 9 Web Services Interoperability organization (WS-I) Specifications
• 10 Business Process Specifications
• 11 Transaction Specifications
• 12 Management Specifications
• 13 Presentation Orientated Specification
• 14 Draft Specifications
• 15 Other
• 16 Standardization

• 17 See also

[edit] Web Service Standards Listings

These sites contain documents and links about the different Web
Services standards identified on this page.

• IBM's Web Services Standards Page

• Microsoft's Web Services Standards Page
• World Wide Web Consortium's Web Services Activity
• innoQ's WS-Standards Poster
• OASIS Standards and Other Approved Work
• XML CoverPages
• Open Grid Forum Final Documents

[edit] XML Specifications

• XML (eXtensible Markup Language)
• XML Namespaces
 • XML Schema
• XPath
• XQuery
• XML Information Set
• XInclude
• XML Pointer

[edit] Messaging Specifications

• SOAP (formerly known as Simple Object Access Protocol)
• SOAP Message Transmission Optimization Mechanism
• WS-Notification
o WS-BaseNotification
o WS-Topics
o WS-BrokeredNotification
• WS-SoapOverUDP
• WS-Addressing
• WS-Transfer
• WS-Eventing
• WS-Enumeration
• WS-MakeConnection

[edit] Metadata Exchange Specifications

• WS-Policy
• WS-PolicyAssertions
• WS-PolicyAttachment
• WS-Discovery
o WS-Inspection
• WS-MetadataExchange
• Universal Description, Discovery, and Integration (UDDI)
• WSDL 2.0 Core
• WSDL 2.0 SOAP Binding
o Web Services Semantics (WSDL-S)
• WS-Resource Framework (WSRF)

[edit] Security Specifications

• WS-Security
• XML Signature
• XML Encryption
• XML Key Management (XKMS)
• WS-SecureConversation
• WS-SecurityPolicy
 • WS-Trust
• WS-Federation
• WS-Federation Active Requestor Profile
• WS-Federation Passive Requestor Profile
• Web Services Security Kerberos Binding
• Web Single Sign-On Interoperability Profile
• Web Single Sign-On Metadata Exchange Protocol
• Security Assertion Markup Language (SAML)
• XACML

[edit] Privacy
• P3P

[edit] Reliable Messaging Specifications

• WS-ReliableMessaging
• WS-Reliability
• WS-RM Policy Assertion

[edit] Resource Specifications

• Web Services Resource Framework
• WS-BaseFaults
• WS-ServiceGroup
• WS-ResourceProperties
• WS-ResourceLifetime
• WS-Transfer
• Resource Representation SOAP Header Block

[edit] Web Services Interoperability

organization (WS-I) Specifications
These specifications provide additional information to improve
interoperability between vendor implementations.

• WS-I Basic Profile

• WS-I Basic Security Profile
• Simple Soap Binding Profile

[edit] Business Process Specifications

 • WS-BPEL
• WS-CDL
• Web Services Choreography Interface
• WS-Choreography
• XML Process Definition Language

[edit] Transaction Specifications

• WS-BusinessActivity
• WS-AtomicTransaction
• WS-Coordination
• WS-CAF
• WS-Transaction
• WS-Context
• WS-CF
• WS-TXM

[edit] Management Specifications

• WS-Management
• WS-Management Catalog
• WS-ResourceTransfer
• WSDM

[edit] Presentation Orientated Specification

• Web Services for Remote Portlets

[edit] Draft Specifications

• WS-Provisioning Describes the APIs and Schemas necessary to facilitate
interoperability between provisioning systems in a consistent manner using Web
services

[edit] Other
• Devices Profile for Web Services (DPWS)
• ebXML

[edit] Standardization
 • ISO/IEC 19784-2:2007 Information technology -- Biometric application
programming interface -- Part 2: Biometric archive function provider interface
• ISO 19133:2005 Geographic information -- Location-based services -- Tracking
and navigation
• ISO/IEC 20000-1:2005 Information technology -- Service management -- Part 1:
Specification
• ISO/IEC 20000-2:2005 Information technology -- Service management -- Part 2:
Code of practice
• ISO/IEC 24824-2:2006 Information technology -- Generic applications of ASN.1:
Fast Web Services
• ISO/IEC 25437:2006 Information technology -- Telecommunications and
information exchange between systems -- WS-Session -- Web Services for
Application Session Services

List of web service protocols

From Wikipedia, the free encyclopedia
Jump to: navigation, search

The following is a list of Web service protocols.

• BEEP - Blocks Extensible Exchange Protocol

• E-Business XML
• Hessian
• JSON-RPC
• Qworum - Defines the concept of Qworum services, which are building blocks for
web applications. Qworum services return XML results like conventional RPC
services. In addition they can interact with the end-user through web pages during
the call, and they can call other Qworum services.
• REST (Representational State Transfer)
• SOAP - outgrowth of XML-RPC, originally an acronym for Simple Object
Access Protocol
• Universal Description, Discovery, and Integration (UDDI)
• Web Services Description Language (WSDL)
• WSFL - Web Services Flow Language (superseded by BPEL)
• WSCL - Web Services Conversation Language
• XINS Standard Calling Convention - HTTP parameters in (GET/POST/HEAD),
POX out
• XLANG - XLANG-Specification (superseded by BPEL)
• XML-RPC - XML Remote Procedure Call