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. 0
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: 1
| 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.