You are on page 1of 18
Web-Services and SOA Why Web Services, while I have created Web Application using Servlets/JSPs? Catch this

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 to invoke some functionality of our EJB components.

e.g.

.NET wants

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

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.

So, why not to use something that is standard and simple? Yes, the promise of web

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 –

Web Service Architecture – In the above example there are mainly three players 1. Service Provider

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.

Web Service Architecture – In the above example there are mainly three players 1. Service Provider

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 –

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

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

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

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

Step 3 – Registering this service. Note - Tomact must be running when you are executing

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

Step 3 – Registering this service. Note - Tomact must be running when you are executing

Author - Sumit Agarwal (jexperts@gmail.com)

Similarly you can write an html page in which you can take input in form element

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>

Similarly you can write an html page in which you can take input in form element

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

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 describes What the service can do • • Where it resides •

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

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

SOAP – Simple Object Access Protocol When we invoked our service http://localhost:8080/axis/services/hello?method=sayHello&name=Sumit We got an xml
  • 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 2 . 1 . SW companies, standards bodies, and

UDDI - Universal Description, Discovery & Integration

2.

1.

UDDI - Universal Description, Discovery & Integration 2 . 1 . SW companies, standards bodies, and

SW companies, standards

bodies, and programmers

populate the registry with

descriptions of different types of services

UDDI - Universal Description, Discovery & Integration 2 . 1 . SW companies, standards bodies, and
UDDI - Universal Description, Discovery & Integration 2 . 1 . SW companies, standards bodies, and
UDDI Registry Business Service Descripti Types
UDDI Registry
Business
Service
Descripti
Types
UDDI - Universal Description, Discovery & Integration 2 . 1 . SW companies, standards bodies, and
UDDI - Universal Description, Discovery & Integration 2 . 1 . SW companies, standards bodies, and

Businesses populate the registry with descriptions of the services they support

3.

UDDI - Universal Description, Discovery & Integration 2 . 1 . SW companies, standards bodies, and

Marketplaces, search engines, and business apps query the registry to discover services at other companies

4.
4.

Business uses this

data to facilitate easier integration 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 Describe its business and its services Discover other businesses that offer desired services Integrate with other businesses

o

o

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.

Java2WSDL If you want to generate WSDL for your services directly, you can do that by
Java2WSDL
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 ;-)

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

Author - Sumit Agarwal (jexperts@gmail.com)

WSDL2Java This tool takes WSDL and generates all of the glue code for deploying the service,
WSDL2Java
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)

WSDL2Java This tool takes WSDL and generates all of the glue code for deploying the service,
• HelloSoapBindingImpl.java: This is the implementation code for our Web service. This is the one file

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

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

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

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

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

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

Web Services Security Security Requirements – Integrity : Data is not modified during transmission – Confidentiality

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

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.

EAI - Enterprise Application Integration EAI is a business computing term for the plans, methods, and

The above diagram will give you a real life scenario.

Author - Sumit Agarwal (jexperts@gmail.com)