You are on page 1of 18

Web-Services and SOA

Why Web Services, while I have created Web Application using Servlets/JSPs?

Catch this point –


You created web application for User to Program interaction for delivering some static or dynamic contents.
While web services are for Program to Program interaction.

If both applications are in Java then you have choices like Socket Programming, RMI etc for establishing a
communication between them. But what if two different technologies want to communicate e.g. .NET wants
to invoke some functionality of our EJB components.

Still we have choices like CORBA or writing some application specific code like .NET makes an http call to
call your servlet, you returned the desired results in string or binary stream format. But there will be n number
of issues related to the data format, security, encoding, data posting etc.

Whatever can be accomplished by CORBA can be accomplished using Web service technologies and vice
versa, although the amount of effort required would be noticeably different. CORBA is complex and in
CORBA, there is a tight coupling between the client and the server. In Web services, everything is decoupled.
The client sends a message and receives a message. See the comparison –
Aspect CORBA Web services
Data model Object model SOAP message exchange model
Client-Server coupling Tight Loose
Location transparency Object references URL
Type system IDL XML schemas
static + runtime checks runtime checks only
Error handling IDL exception SOAP fault messages
Serialization built into the ORB can be chosen by the user
Parameter passing by reference by value (no notion of objects)
by value (valuetype)
Transfer syntax CDR used on the wire XML used on the wire
binary format Unicode
State Stateful stateless
Request semantics at-most-once defined by SOAP
Runtime composition DII UDDI/WSDL
Registry Interface Repository UDDI/WSDL
Implementation repository
Service discovery CORBA naming/trading service UDDI
RMI registry
Language support any language with an IDL binding any language
Security CORBA security service HTTP/SSL, XML signature

Author - Sumit Agarwal (jexperts@gmail.com)


So, why not to use something that is standard and simple?
Yes, the promise of web services is to enable a distributed environment in which any number of
applications, or application components, can interoperate seamlessly among and between organizations in a
platform-neutral, language-neutral fashion. This interoperation brings heterogeneity to the world of distributed
computing once and for all.

Real Life Example –


The Amazon.com provides some web services over internet. As well as writing private client applications to
extract specific book-related information, web service developers can use this service to create their own web
sites that incorporate information obtained from Amazon.com, without having to present it in the same way as
it appears on the Amazon.com web site.

When the user selects a book from one of MyXMLBooks.com's web pages, the HTTP request generated is
routed via a controlling servlet on the MyXMLBooks.com web server, which determines that it needs to
retrieve raw book data from Amazon.com. The servlet obtains this data by using a web service client
implemented by MyXMLBooks.com's developers. This client uses the web service interface published by
Amazon.com to invoke a method on its server that returns the required information. The method invocation is
performed by creating an XML message that contains the method name and any required parameters and then
sending it to Amazon.com's server using some standard protocol (SOAP ;-)

Have you realized how two different applications communicating to each other over internet without knowing
the underlying technologies of other side?

Author - Sumit Agarwal (jexperts@gmail.com)


Web Service Architecture –
In the above example there are mainly three players
1. Service Provider – Amazon.com created some web services
2. Service Registry – these web services are registered to some globally or locally accessible directory
3. Service Requester – MyXMLBooks.com wrote some code to find the services from this registry then
invoke the required functionality.

WSDL – Web Service Description Language (A XML document having info about your services)
UDDI – Universal Description, Discovery & Integration (like JNDI where we bind WSDL for client access)

So what we will be doing –

Creating Services - We will write our java class that we want to make a service. The functions inside this
class are the service functionalities.

Registering Services - Then we will create a WSDD file. A web service deployment descriptor contains a
bunch of things you want to "deploy" into Axis - i.e. make available to the Axis engine. Once we have this
file, we need to send it to an Axis server in order to actually deploy the described service. We do this with the
AdminClient, or the "org.apache.axis.client.AdminClient" class.

Requesting Services – we will write some code to access them. There are APIs those provide the
functionality for calling the deployed web services.

Author - Sumit Agarwal (jexperts@gmail.com)


HelloWorld
So lets do some exercise for building confidence with web services ;-)

Axis Setup –
1. Unzip axis-1_4.zip downloaded from apache.
2. Copy its webapps folder to tomcat; now tomcat has axis web application.
3. Start tomcat >Catalina start and access http://localhost:8080/axis

Note - Before running the example, you'll need to make sure that your CLASSPATH includes

• axis.jar, jaxrpc.jar, saaj.jar, commons-logging.jar, commons-discovery.jar,


wsdl4j.jar, xerces or crimson.jar
• activation.jar, mail.jar

axis/WEB-INF/lib contained all the required jars, add activation and mail.jar for avoid
warnings.

Step 1 – HelloWorld.java
package org.test.ws;
public class HelloWorld {
public String sayHello(String name) {
return "Hello " + name;
}
}

Step 2 – Create a wsdd file, deploy.wsdd


<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="hello" provider="java:RPC">
<parameter name="className" value="org.test.ws.HelloWorld" />
<parameter name="allowedMethods" value="*" />
</service>
</deployment>

Author - Sumit Agarwal (jexperts@gmail.com)


Step 3 – Registering this service.

Note - Tomact must be running when you are executing this command.

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


<Admin>Done processing</Admin>
Or different view of the same thing DeployHello.java

package org.test.deploy;
import org.apache.axis.client.AdminClient;
public class DeployHello {
public static void main(String[] args) {
AdminClient.main(new String[] { "deploy.wsdd" });
}
}
Step 4 – Copy org/test/ws/HelloWorld.class in axis/WEB-INF/classes and restart tomcat.
Access http://localhost:8080/axis then click on List link.

See our hello service, client can get


its WSDL and can write program to
invoke the functionality.

Still without writing the client


program I can access this service
functions

http://localhost:8080/axis/services/hello?method=sayHello&name=Sumit

Author - Sumit Agarwal (jexperts@gmail.com)


Similarly you can write an html page in which you can take input in form element and in
action can call http://localhost:8080/axis/services/hello

hello.html
<form action="http://localhost:8080/axis/services/hello">
<input type="hidden" name="method" value="sayHello">
<input type="text" name="name">
<input type="submit">
</form>

As above, same xml document you will receive in response.

We can see the response document contain the service output


<sayHelloResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<sayHelloReturn xsi:type="soapenc:string"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">Hello
Sumit</sayHelloReturn>
</sayHelloResponse>

Repeating again ;-) Web Services are for program to program interaction, but what we did
here User to Program interaction.
Client Program - HelloClient.java
package org.test.ws;

import java.net.URL;
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
public class HelloClient {
public static void main(String[] args) {
try {
URL url = new URL("http://localhost:8080/axis/services/hello");

Service service = new Service();

Call call = (Call) service.createCall();


call.setTargetEndpointAddress(url);
Object result = call.invoke("sayHello", new Object[] { "Sumit" });
System.out.println(result);
} catch (Exception exception) {
exception.printStackTrace();
}
}
}Output - Hello Sumit
 Similarly you can put this code inside a servlet, JSP etc.
Now this is the right time to jump into the cup –

Author - Sumit Agarwal (jexperts@gmail.com)


WSDL – Web Service Description Language
When you will click on wsdl link of the service listing page
• hello (wsdl)
You will receive an xml document
<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions
targetNamespace="http://localhost:8080/axis/services/hello"
xmlns:apachesoap="http://xml.apache.org/xml-soap"
xmlns:impl="http://localhost:8080/axis/services/hello"
xmlns:intf="http://localhost:8080/axis/services/hello"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:message name="sayHelloRequest"> 2
<wsdl:part name="name" type="soapenc:string" />
</wsdl:message>
<wsdl:message name="sayHelloResponse">
<wsdl:part name="sayHelloReturn" type="soapenc:string" />
</wsdl:message>
<wsdl:portType name="HelloWorld"> 3
<wsdl:operation name="sayHello" parameterOrder="name">
<wsdl:input message="impl:sayHelloRequest"
name="sayHelloRequest" />
<wsdl:output message="impl:sayHelloResponse"
name="sayHelloResponse" />
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="helloSoapBinding" type="impl:HelloWorld"> 4
<wsdlsoap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="sayHello">
<wsdlsoap:operation soapAction="" />
<wsdl:input name="sayHelloRequest">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://ws.test.org" use="encoded" />
</wsdl:input>
<wsdl:output name="sayHelloResponse">
<wsdlsoap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://localhost:8080/axis/services/hello"
use="encoded" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="HelloWorldService"> 5
<wsdl:port binding="impl:helloSoapBinding" name="hello">
<wsdlsoap:address
location="http://localhost:8080/axis/services/hello" />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

Author - Sumit Agarwal (jexperts@gmail.com)


 A WSDL document describes
• What the service can do
• Where it resides
• How to invoke it

 Defines binding for SOAP1.1, HTTP


GET/POST and MIME

 WSDL descriptions can be made available


from an UDDI registry

A WSDL document is a kind of structured language to describe a Web Service; it contains set of definitions to
define a web service

1. The <types> element defines the data type that are used by the web service
2. The <message> element defines the data elements of an operation. Each message can consist of one or
more parts. The parts can be compared to the parameters of a function call in a traditional programming
language
3. The <portType> element is the most important WSDL element. It defines a web service, the
operations that can be performed, and the messages that are involved
4. The <binding> element defines the message format and protocol details for each port
5. The <services> element defines the URL for the available services

So, if Amazon.com provides WSDL for its services then anyone can write client program for accessing these
services by figuring out the things from this WSDL file.

There are several eclipse and other plugins which generate client program, if WSDL provided to them. Even
you can get more automation from these plugins. These will make your life easier.

Author - Sumit Agarwal (jexperts@gmail.com)


SOAP – Simple Object Access Protocol
When we invoked our service
http://localhost:8080/axis/services/hello?method=sayHello&name=Sumit
We got an xml in response

<soapenv:Envelope 1
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body> 4
<sayHelloResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<sayHelloReturn xsi:type="soapenc:string"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/">
Hello Sumit
</sayHelloReturn>
</sayHelloResponse>
</soapenv:Body>
</soapenv:Envelope>
 SOAP is an XML based protocol for exchange of information
• Encoding rules for data type instances
• Convention for representing RPC invocations

 Designed for loosely-coupled distributed computing


• No remote references

 Used with XML Schema

 Transport independent

 SOAP with Attachments allows arbitrary data to be packaged.

SOAP RPC:
• Encode and bind data structures into xml.
• encode an RPC call

SOAP ‘document style’


• packages xml in an envelope

1. The SOAP Envelope element is the root element of a SOAP message. It defines the XML document
as a SOAP message.
2. The optional SOAP Header element contains application specific information (like authentication)
about the SOAP message.
3. If the Header element is present, it must be the first child element of the Envelope element.
4. The required SOAP Body element contains the actual SOAP message intended for the ultimate
endpoint of the message
5. An error message from a SOAP message is carried inside a Fault element. If a Fault element is
present, it must appear as a child element of the Body element. A Fault element can only appear once
in a SOAP message.

Author - Sumit Agarwal (jexperts@gmail.com)


UDDI - Universal Description, Discovery & Integration

3.

1. SW companies, standards
bodies, and programmers
populate the registry with
Marketplaces, search
descriptions of different types
engines, and business
of services
apps query the registry
to discover services at
other companies

2.
UDDI Registry 4.
Business Service
Businesses populate
Descripti Types
the registry with ons Business uses this
descriptions of the
data to facilitate
services they
easier integration
support
with each other over
the Web

 Standards based specification for service description and discovery


 Programmatic descriptions of businesses and services they support
 UDDI Supports
• Cataloging services based on publish requests
• Maintaining taxonomies to support searching
• Search by humans or machines
 UDDI enables a business to
o Describe its business and its services
• Discover other businesses that offer desired services
o Integrate with other businesses

Currently we have not used UDDI; we used an axis servlet http://localhost:8080/axis/services/hello?wsdl that
generate and send WSDL in response.

Use http://ws.apache.org/juddi/ an open source API for UDDI specification. Just imagine it like LDAP is
specification and Sun’s iPlanet or Microsoft Active Directory etc. is an implementation.

Author - Sumit Agarwal (jexperts@gmail.com)


Java2WSDL
If you want to generate WSDL for your services directly, you can do that by using java2wsdl service.

Note - Set the required jars into the classpath, you will all required jars from axis/WEB-INF/lib folder.

> java org.apache.axis.wsdl.Java2WSDL


-o hello.wsdl 1
-l"http://localhost:8080/axis/services/hello" 2
-n "http://localhost:8080/axis/services/hello" 3
-p"org.test.ws" "http://localhost:8080/axis/services/hello" 4
org.test.ws.HelloWorld 5
or
package org.test.ws;
import org.apache.axis.wsdl.Java2WSDL;

public class J2WSDL {


public static void main(String[] args) {
String a[] = new String[] { "-o", "hello.wsdl", 1
"-lhttp://localhost:8080/axis/services/hello", 2
"-n", "http://localhost:8080/axis/services/hello", 3
"-porg.test.ws","http:// localhost:8080/axis/services/hello",4
"org.test.ws.HelloWorld" }; 5

Java2WSDL.main(a);
}
}

Where:

1. -o indicates the name of the output WSDL file


2. -l indicates the location of the service
3. -n is the target namespace of the WSDL file
4. -p indicates a mapping from the package to a namespace. There may be multiple mappings.
5. The class specified contains the interface/class of the web service.

The output WSDL document will contain the appropriate WSDL types, messages, portType, bindings and
service descriptions to support a SOAP rpc, encoding web service. If your specified interface methods
reference other classes, the Java2WSDL tool will generate the appropriate xml types to represent the classes
and any nested/inherited types. The tool supports JAX-RPC complex types (bean classes), extension classes,
enumeration classes, arrays and Holder classes.

It will generate same WSDL file as we have earlier. So now you know the logic behind hello (wsdl) link ;-)

Author - Sumit Agarwal (jexperts@gmail.com)


WSDL2Java
This tool takes WSDL and generates all of the glue code for deploying the service, as well as stubs for
accessing it.

Two Main Reason for using this Tool -


1. We have written deploy.wsdd file earlier then used AdminClient to deploy and register the service.
Simillarly we can write undeploy.wsdd file. You don’t need to write these wsdd files this tool will
generate for you ;-)

2. There are several ways for invoking a web service the way we used recently called Dynamic
Invocation Interface (DII). Another way using generated Stubs from Service WSDL.
This tool will generate all these stubs and required file for you.
Step 1 – Generate required files by using WSDl2Java command
>java org.apache.axis.wsdl.WSDL2Java
-o . 1
–d Session 2
-s -S true 3
-Nhttp://localhost:8080/axis/services/hello org.test.ws 4
hello.wsdl 5
Or public class WSDL2Java {
public static void main(String[] args) {
String a = new String[] { "-o", ".",
"-d", "Session",
"-s", "-S", "true",
"-Nhttp://localhost:8080/axis/services/hello", "org.test.ws",
"hello.wsdl" };
WSDL2Java.main(a);
}
}

1. Base output directory (.)


2. Scope of deployment (Application, Request, or Session)
3. Turn on server-side generation (we wouldn't do this if we were accessing an external Web service, as
we would then just need the client stub)
4. mapping of namespace to package
5. Name of WSDL file

This will generate these files in org/test/ws directory

Author - Sumit Agarwal (jexperts@gmail.com)


• HelloSoapBindingImpl.java: This is the implementation code for our Web service. This is the one file
we will need to edit, tying it to our existing HelloWorld.
• HelloWorld.java: This is a remote interface to the HelloWorld system (extends Remote, and methods
from the original HelloWorldi.java throw RemoteExceptions).
• HelloWorldService.java: Service interface of the Web services. The ServiceLocator implements this
interface.
• HelloWorldServiceLocator.java: Helper factory for retrieving a handle to the service.
• HelloSoapBindingSkeleton.java: Server-side skeleton code.
• HelloSoapBindingStub.java: Client-side stub code that encapsulates client access.
• deploy.wsdd: Deployment descriptor that we pass to the Axis system to deploy these Web services.
• undeploy.wsdd: Deployment descriptor that will undeploy the Web services from the Axis system.

Step 2 – HelloSoapBindingImpl: Fill-in Wrapper to Call the Existing HelloWorld Code

We need to tweak one of the output source files to tie the Web service to HelloWorld.java.
HelloSoapBindingImpl.java is waiting for us to add the stuff into the methods that it created. The lines
that we added are in bold:

package org.test.ws;
public class HelloSoapBindingImpl extends HelloWorld {
HelloWorld h = new HelloWorld();

public String sayHello(String name) throws java.rmi.RemoteException {


return h.sayHello(name);
}
}

We are simply tying in to the existing class. We could have hard-coded the methods in this class, but in the
real world, we probably want to wrap logic as Web services, and not just enable access via that interface or
class.

Step 3 – Deploy the Service to Apache Axis

Compile the Service Code: >javac org\test\ws\*.java


Package the code for Axis to find:
>jar cvf hello.jar org/test/ws/*.class
> mv hello.jar %TOMCAT_HOME%/webapps/axis/WEB-INF/lib
Deploy the Web Service using the WSDD Deployment Descriptor:
>java org.apache.axis.client.AdminClient deploy.wsdd
<admin>Done processing</admin>

Now our hello Web service is alive and running in the server!

Author - Sumit Agarwal (jexperts@gmail.com)


Step 4 – Write a Client That Uses the Generated Stubs to Easily Access the Web Service

All we need to do in the code is to get access to the service via the ServiceLocator, and then call methods on
the remote handle that we have to the service.

package org.test.ws;

public class HelloTester {


public static void main(String [] args) throws Exception {
// Make a service
HelloWorldService service =
new HelloWorldServiceLocator();

// Now use the service to get a stub to the service


HelloWorld hello = service.getHelloWorld();

// Make the actual call


System.out.println(hello.sayHello(“Sumit”))
}
}

It looks just like normal Java; none of that SOAP or RPC code is in sight. Isn't that nicer? (Take another look
at the HelloClient that we used at the beginning, and compare it to this code.)

Hope, Now you will be comfortable with this web service stack

SOA (Service Oriented Architecture) - SOA is an architectural style for building software applications that
use services available in a network such as the web. It promotes loose coupling between software components
so that they can be reused. Applications in SOA are built based on services. A service is an implementation of
well-defined business functionality, and such services can then be consumed by clients in different
applications or business processes.

Web service is one of the way implementing SOA.

;-)

Author - Sumit Agarwal (jexperts@gmail.com)


Exposing Servlets and EJBs as a service -
Yes, like a simple java class we can expose servlet, ejbs too as a web service. For all popular application
servers, you will do these steps for achieving this

Servlet as a Web Service, you need to execute the following steps:

1. Build a class that implements the business method of your Web Service. Note that this class is
categorized as a Servlet, but it does not need to extend the Servlet or HttpServlet class.

2. Build a Remote interface for the service that lists all of the methods that the service exposes.

3. Create a Servlet mapping in your web.xml file that maps a URL pattern to your service Servlet.

4. Build or generate a WSDL file. This file is part of the Web Services standard and it describes the
services that you publish, complete with parameter types and return values, in a platform-independent
way.

5. Build or generate a JAX-RPC mapping file. Your application server uses this file to map Web
Service requests to your Servlet.

6. Build a webservices.xml file.

7. Assemble a WAR file containing your compiled service code and the configuration files that we
mentioned thus far.

In the end, the deployment structure of your WAR file should resemble the following:

WEB-INF/
WEB-INF/classes
WEB-INF/mapping.xml
WEB-INF/web.xml
WEB-INF/webservices.xml
WEB-INF/wsdl
WEB-INF/wsdl/MyWebService.wsdl
As with all Web applications, the classes directory contains all of the compiled classes, which in this case
includes your compiled Web Service Servlet and Remote interface. The web.xml configuration has all of your
Servlets, resource mappings, etc., as well as a Servlet Mapping entry for your Web service.

And thankfully, the Java Web Services Developer Pack (WSDP) includes a tool, wscompile, that generates
the other configuration files: mapping.xml, webservices.xml, and *.wsdl. You need to provide it with a
relatively simple configuration file to tell it how to build those files.

Author - Sumit Agarwal (jexperts@gmail.com)


EJB as a Web service, you need to execute the following steps:

The configuration requirements for building a Web Service out of a Stateless Session Bean are similar to the
Servlet requirements. The following are the steps required to publish a Stateless Session Bean as a Web
Service:

1. Build a Stateless Session Bean (as you normally would) containing the service method you want to
expose.

2. In the ejb-jar.xml file, add a <session-endpoint> node to the <session> node in the <enterprise-
beans> section that references the Stateless Session Bean's remote interface.

3. Build or generate a webservices.xml file; but, in the <service-impl-bean> node insert an <ejb-link>
instead of a <servlet-link> (more on these details later).

4. Build or generate a JAX-RPC mapping document (same).

5. Build or generate a WSDL file for your service (same).

6. Assemble the JAR file.

The JAR file looks a little different from the WAR file; the configuration files are all in the META-INF folder
instead of the WEB-INF folder. For example:

META-INF/
META-INF/ejb-jar.xml
META-INF/mapping.xml
META-INF/webservices.xml
META-INF/wsdl
META-INF/wsdl/MyWebService.wsdl
And as with all EJB JAR files, your compiled code goes in the root of the JAR file (in the appropriate
package-defined folders).

Author - Sumit Agarwal (jexperts@gmail.com)


Web Services Security
Security Requirements
– Integrity : Data is not modified during transmission
– Confidentiality : Nobody else is able to read data during transmission
– Non Repudiation : The parties involved in a transaction can not deny their involvement and
actions

Additional capabilities in web services bring additional security Requirements.

Specialized Security Requirements of WS


End-to-end instead of Point-to-point Security
– SSL provides point-to-point security
– Sufficient if only 2 parties are involved
– End-to-end security is required when more than 2 parties are involved.
Persistent security credentials
– Security credentials should be accepted by all involved
– Single sign on across multiple domains
Selective privacy
– While buying goods from internet, the buyer would want the seller not to know about the
instructions given to the bank and the bank not to know the goods bought. The same
xml soap request is used for the transaction that requires selective privacy
Solutions are -
XML Encryption
XML Encryption is a standard proposed by World Wide Web Consortium (W3C).
Provides capabilities to selectively encrypt/decrypt part of an XML document
XML Signature
XML Signature is the supporting standard of XML Encryption proposed by W3C
It allows XML documents to be digitally signed so that the integrity of the document is
ensured. It also solves the problem of non-repudiation
SAML (Security Assertion Markup Language)
It is an XML-based framework for exchanging security information.
Provides single sign-on capabilities to web services using persistent security tokens
WS-Security
Series of specifications from an industry group including IBM, Microsoft and Verisign
Specifies enhancements to SOAP message, aimed to protect the integrity and
confidentiality of a message and authenticating the sender

Author - Sumit Agarwal (jexperts@gmail.com)


EAI - Enterprise Application Integration
EAI is a business computing term for the plans, methods, and tools aimed at modernizing, consolidating, and
coordinating the computer applications in an enterprise. Typically, an enterprise has existing legacy
applications and databases and wants to continue to use them while adding or migrating to a new set of
applications that exploit the Internet, e-commerce, extranet, and other new technologies.

Now think web services are for what? ;-) Basically we are doing EAI using web services, there can be other
ways but web services are the simplest one.

In B2B (business to business) communication, we require interoperability, asynchronous calling means JMS
and management (like monitoring) of all these happening. Again need of some server like jboss, weblogic etc
which provide all these functionalities and ease development of the application. Here is the birth of EAI
servers like WebMethods (I like this), Tibbco, BizTalk etc. These servers are based on JMS and web services.

The above diagram will give you a real life scenario.

Author - Sumit Agarwal (jexperts@gmail.com)

You might also like