Posts Tagged ‘Enterprise JavaBean’

Spring supports remoting for six different RPC models:

1. Remote Method Invocation (RMI)

2. Hessian

3. Burlap

4. HTTP invoker

5. EJB

6. JAX-RPC

In all the models, services are configured into the application through spring configuration file as spring managed beans. This is accomplished by using a proxy factory bean that enable us to wire remote services into the properties of our beans as if they were local objects.

Spring provides ‘RmiProxyFactoryBean‘ to use the RMI service and ‘RmiServiceExporter’ to export any spring managed bean as a RMI service.

For wiring a Hessian based service to Spring client, Spring’s ‘HessianProxyFactory Bean’ is used. To export a Hessian Service ‘HessianServiceExporter’ is used and similarly for wiring a Burlap service ‘BurlapProxyFactoryBean’ is used and ‘BurlapServiceExporter’ is used to export a burlap service.

For exporting beans as HTTP invoker services, ‘HttpInvokerServiceExporter‘ is used .To access an HTTP invoker service ‘HttpInvokerProxyFactoryBean‘ can be used.

Spring provides two proxy factory beans to access the Enterprise Java Beans. ‘LocalStatelessSessionProxyFactoryBean’ is used to access the EJB in the same container(local) and another one is

‘SimpleRemoteStatelessSessionProxyFactoryBean’ which is used to access the remote EJBs.

For all the above models spring provides service exporter classes that exports Java Beans as remote service. Spring does not provide any EJB Service Exporter and it provides four abstract support classes to make the development of Spring enabled EJB. They are 

1. AbstractMessageDrivenBean to develop MDBs that accept sources other than JMS.

2. AbstractJmsMessageDrivenBean to develop MDBs that accept messages from JMS sources.

3. AbstractStatelessSessionBean to develop stateless session bean.

4. AbstractStstefulSessionBean to develop stateful session bean.  

‘JaxRpcPostProxyFactoryBean’ is used to wire a web service into the spring application.

The client makes calls to the proxy to provide the service and the proxy calls the remote service on behalf of the client.

——————————————–

Now we shall see how to wire other RMI services into spring application and also how to export our own service.

Remote Method Invocation (RMI) Model:

RMI was first introduced in JDK 1.1.  But developing and accessing  RMI services involves various steps and also have lookups which makes the code hard to test. Spring simplifies the RMI by providing a ‘proxy factory bean’ that enables us to wire the RMI services into spring application as if they were local beans. Spring also provides a remote exporter that converts our ‘spring managed beans’ into RMI services.

Spring’s ‘RmiProxyFactoryBean’ is a factory bean that creates a proxy to RMI service. It is declared spring configuration file under the <bean> tag as follows,

<bean  id=”service1″ 

   class=”org.springframework.remoting.rmi.RmiProxyFactoryBean”>

   <property name=”serviceUrl“>

  <value>rmi://${hostname}/service1</value>  

   </property>

   <property name=”serviceInterface”>

  <value>service1</value>

   </property>

</bean>

The url of the RMI service is set through the ‘serviceUrl’ property. The ‘serviceInterface’ property specifies the interface that the service implements and only through that the client invokes methods on the service.

For using the service the implementation  code is wired to the RMI using the following code,

<bean id=”serviceimpl”>

   <property name=”service1″>

   <ref bean=”service1″/>

   </property>

</bean>

——————————————-

First set the path and classpath as before. Next edit the RMI service.

//f:\springdemo\rmserver.java

import java.rmi.*;

public  interface  rmserver  extends Remote

{

   String   getresult(String   s)  throws RemoteException;

}

———————————————-

//f:\springdemo\rmserverimpl.java

import java.rmi.*;

import java.rmi.server.*;

public class rmserverimpl extends UnicastRemoteObject

   implements rmserver

{

   public static void main(String args[])

   {

  try

  {

   rmserverimpl   ob = new rmserverimpl();

   Naming.rebind(“rmserver”,ob);

   System.out.println(“ready”);

  }

  catch(Exception e1)

   {System.out.println(“”+e1);}

   }

   public rmserverimpl() throws RemoteException

   {

   System.out.println(“constructor ok”);

   }

   public String getresult(String  a)  throws RemoteException

   {

   return “Hai…”+a;

   }

}

———————————————-

//f:\springdemo\rmserver.xml

<?xml version=”1.0″ encoding=”UTF-8″?>

<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN”

http://www.springframework.org/dtd/

 spring-beans.dtd”>

<beans>

  <bean id=”rmserver”

  class=”org.springframework.remoting.rmi.RmiProxyFactoryBean”>

   <property name=”serviceUrl”>

   <value>rmi://localhost/rmserver</value>  

   </property>

   <property name=”serviceInterface”>

   <value>rmserver</value>

   </property>

  </bean>

  <bean   id=”rmserverimpl”  class=”rmserverimpl”>

    <property name=”rmserver”>

  <ref bean=”rmserver”/>

  </property>

  </bean>

</beans>

———————————————

//f:\springdemo\rmspring.java

import java.rmi.*;

import org.springframework.beans.factory.*;

import org.springframework.beans.factory.xml.*;

import org.springframework.core.io.*;

public class  rmspring

{

   public static void main(String args[])

   {

  try

  {

   System.out.println(“Wait..”);

   Resource   res = new ClassPathResource(“rmi.xml”);

   BeanFactory   factory = new XmlBeanFactory(res);

   rmserver bean1 = (rmserver) factory.getBean(“rmserver”);

   String r=bean1.getresult(args[0]);

   System.out.println(r);

  }

  catch(Exception e1)

  {System.out.println(“”+e1);}

   }

}

—————————————

To run:

f:\springdemo>javac rmserver.java

f:\springdemo>javac rmserverimpl.java

f:\springdemo>rmic rmserverimpl (To create stub and skeleton)

f:\springdemo>javac rmspring.java

f:\springdemo>start rmiregistry (a blank window will appear)

f:\springdemo>java rmserverimpl

Open another Window and run the client code by giving the argument

f:\springdemo>java rmspring “sam”

We will get the output as:

Wait..
……
Hai… sam

Here we have removed the ‘lookup’ code in the client side.

—————————————————————–

Spring also supports the server side of RMI. Here the service itself is written with spring and it is exposed as an RMI service. Here the bean is written as a simple JavaBean. Also we need not generate the stub and skeleton using ‘rmic’ command and manually add it to RMI registry. Instead of these traditional procedure ‘RmiServiceExporter’ is used to export any Spring managed bean as an RMI service. It wrapps the bean in an adapter class. The adapter class is then bound to RMI registry and the proxies request the service.

<bean   class=”org.springframework.remoting.rmi.RmiServiceExporter“>

   <property name=”service1″>

   <ref bean=”service1″/>

   </property>

   <property name=”serviceName”>

  <value>service1</value>

   </property>

   <property name=”serviceInterface”>

  <value>service1</value>

   </property>

</bean>

The ‘serviceName property’ indicates the name of service and ‘serviceInterface’ specifies the interface implemented by the service. There is no need of ‘serviceUrl’ here

First set the path and classpath as before. Next edit the service.

//f:\springdemo\rmservice.java

public  interface  rmservice

{

  String   getresult(String  s);

}
——————————————

//f:\springdemo\rmserviceimpl.java

public class rmserviceimpl  implements  rmservice

{

   public static void main(String args[])

   {

  System.out.println(“ready”);

   }

   public rmserviceimpl()

   {

  System.out.println(“constructor ok”);

   }

   public String getresult(String  a)

   {

  return “Hai”+a;

   }

}

——————————————

//f:\springdemo\rmservice.xml

<?xml version=”1.0″ encoding=”UTF-8″?>

<!DOCTYPE beans PUBLIC “-//SPRING//DTD BEAN//EN”

http://www.springframework.org/dtd/  spring-beans.dtd”>

  <beans>

   <bean 3″>remoting.rmi.RmiServiceExporter”>

   <property name=”service”>

   <value>rmservice</value>  

   </property>

   <property name=”serviceName“>

   <value>service1</value>  

   </property>

   <property name=”serviceInterface“>

   <value>rmservice</value>

   </property>

   </bean>

   <bean id=”rmservice”>

   </bean>

</beans>

——————————————

//f:\springdemo\rmserviceclient.java

import java.io.*;

import org.springframework.beans.factory.*;

import org.springframework.beans.factory.xml.*;

import org.springframework.core.io.*;

class   rmserviceclient

{

   public static void main(String args[])

   {

  try

  {

   System.out.println(“Wait..”);

   Resource  res = new ClassPathResource(“rmservice.xml”);

   BeanFactory  factory = new  XmlBeanFactory(res);

   System.out.println(“factory created”);

   rmservice bean1 = (rmservice)factory.getBean(“rmservice”);

   String s = bean1.getresult(args[0]);

   System.out.println(s);

  }

  catch(Exception e1)

   {System.out.println(“”+e1);}

   }

}

—————————————

To run:

f:\springdemo>javac rmservice.java

f:\springdemo>javac rmserviceimpl.java

f:\springdemo>javac rmserviceclient.java

f:\springdemo>java rmsserviceclient

We will get Output as:

Wait..

Feb 12, 2012 10:55:07 PM  

   org.springframework.beans.factory.

   xml.XmlBeanDefinitionReader

   loadBeanDefinitions

INFO: Loading XML bean definitions from

  class path resource[rmservice.xml]

Feb 12, 2012 10:55:07 PM

   org.springframework.beans.factory.

   support.AbstractBeanFactory getBean

INFO: Creating shared instance of

  singleton bean ‘rmservice’

constructor   ok

Hai…sam  

Here the service interface doesn’t extend the ‘java.rmi.Remote’ method and ‘RemoteException’ is not thrown by the methods. There is no binding in the implementation code. Also we can direcly run the client. No run to run ‘rmserverimpl’ first. Also there is no need to run the RMI registry.

This post visualizes changes between Java EE Standards 5 and 6. The comparison of standards is listed in four sections Web-Services, Web-Container, Enterprise Application technologies and Maintenance. Hope this helps someone.

Web Service related changes

Java EE 5 (JSR-244) Java EE 6 (JSR-316)
JAX-RPC 1.1 JSR 101 JAX-RPC 1.1
Enterprise Web Services 1.2 JSR 109 Enterprise Web Services 1.3 (new version)
Web Service Metadata 1.0 JSR 181 Web Service Metadata 1.0
Streaming API for XML 1.0 JSR 173 Streaming API for XML 1.0
JAX-WS 2.0  JSR 224 JAX-WS 2.2 (new version)
JAXB 2.0 JSR 222 JAXB 2.2 (new version)
SOAP with Attachments API for Java (SAAJ) JSR 67 Java APIs for XML Messaging 1.3 (new version) spec
new! JAX-RS 1.1 JSR 311
new! Java API for XML Registries (JAXR 1.0) JSR 93

The new redesigned Java API for XML Web Services (JAX-WS) is the base or a middle part of a newly Java EE 6 Web service stack.  The new stack  includes JAX-WS 2.0, JAXB 2.0, and SAAJ 1.3. and is also called “integrated stack”.  JAX-WS was designed to take place of JAX-RPC. Due this also JSR-109 was updated because it describes run time architecture of JEE Web Services Stack. JAXB which provides an easy way to bind an XML schema to java and vice verse, was updated to.

The SOAP with Attachments API for Java (SAAJ) (also known as Java APIs for XML Messaging (JAXM)) provides a standard way to send XML documents over the Internet from the Java platform and was updated slightly containing now other consolidated standard.

New are JAX-RS, which provides support for RESTful Web services and JAXR which enables pull-parsing API for reading and writing XML documents. Also available in Java SE.

Web Applications related changes

Java EE 5 Java EE 6
JSTL JSR 52 JSTL
JavaServer Faces 1.2 JSR 252 JavaServer Faces 2.0 (new version)
JavaServer Pages 2.1 JSR 245 JavaServer Pages 2.2 /EL 2.2 (new version)
Java Servlet 2.5 JSR 154 Java Servlet 3.0 JSR 315 (new version)
new! Debugging Support for Other Languages 1.0 JSR 45

In Java EE 6 we have updates of all technologies of the Web Container except JSTL. So e.g. Servlet 3.0 improves Servlet concept in pluggability and some ease of development. It’s also introduces Async Servlet, and long waited File Uploading!. Also now configuration can be done by annotations.

New a specification of Debugging Support for Other Languages 1.0
This describes standardized tools for correlating Java virtual machine byte code to source code of languages other than the Java programming language, so it would guarantee debugging possibility of everything what runs is JSR-45 certified container.

Enterprise Technologies changes

Java EE 5 Java EE 6
Common Annotations JSR 250 Common Annotations
JCA 1.5 JSR 112 JCA 1.6 JSR 322 (new version)
JavaMail 1.4 JavaMail 1.4
JMS 1.1 JSR 914 JMS 1.1
JTA 1.1 JSR 907 JTA 1.1
Enterprise JavaBeans 3.0 JSR 220 Enterprise JavaBeans 3.1 JSR 318
(new version)
JPA 1.0 JSR 220 (together with EJB 3.0) JPA 2.0 JSR 317 (new version)
new! Contexts and Dependency Injection for Java (Web Beans 1.0) JSR 299
new! Dependency Injection for Java 1.0 JSR 330
new! Bean Validation 1.0 JSR 303
new! Managed Beans 1.0 JSR-316

In Enterprise Application section we see some important changes and new specifications. Most famous and important is  JSR-299 Context and Dependency Injection (CDI) which is there to unify the JavaServer Faces-managed bean component model with the Enterprise JavaBeans component model to simplify the programming model and architecture of web-based applications. Look an Weld Framework as reference implementation to this.

The similar sounding Standard Dependency Injection for Java JSR-330 just define a standard and common known DI like in spring and other frameworks. Look at popular Guice DI-Framework from Google which implements JSR-330.

Bean Validation  introduces a very cool annotation based and architecture layer independent Java Bean validation.

There are also some interesting improvements in EJBs. Singleton is a new type and can be only one per container, it is also possible to use @Local Beans (Same VM) without interface. Also JPA 2.0 has advanced query possibilities and validation.

Management Technologies

Java EE 5 Java EE 6
J2EE Application Deployment 1.2 JSR 88 J2EE Application Deployment 1.2
JavaBeans Activation Framework (JAF) 1.1 JSR 925 JavaBeans Activation Framework (JAF) 1.1
J2EE Management 1.0  JSR 77 J2EE Management 1.1 (new version)
Java Authorization Contract for Containers 1.1 JSR 115 Java Authorization Contract for Containers 1.3(new version)
new! Java Authentication Service Provider Interface for Containers JSR 196
new! [JavaSE] JAXP 1.3 JSR 206
new! [JavaSE] JDBC 4.0 JSR 221
new! [JavaSE] JMX 2.0 JSR 255

Nothing special to mention here.

Java EE 6 Certified Application Server

Please feel free to correct me or provide additional information.

Web Services – Web Services Tutorials

Posted: January 12, 2012 in Random Posts
Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

In this section of the Web Services tutorial you will be familiarized with the Web Services.

Introduction

The next generation of distributed computing has arrived. A Web service is a unit of managed code that can be remotely invoked using HTTP, that is, it can be activated using HTTP requests.

Historically speaking, remote access to binary units required platform-specific and sometimes language-specific protocols. For example, DCOM clients access remote COM types using tightly coupled RPC calls. CORBA requires the use of tightly coupled protocol referred to as Internet Inter-ORB Protocol (IIOP), to activate remote types. Enterprise JavaBeans (EJBs) requires a Remote Method Invocation (RMI) Protocol and by and large a specific language (Java). Thus each of these remote invocation architectures needs proprietary protocols, which typically require a tight connection to the remote source.

One can access Web services using nothing but HTTP. Of all the protocols in existence today, HTTP is the one specific wire protocol that all platforms tend to agree on. Thus , using Web services, a Web service developer can use any language he wish and a Web service consumer can use standard HTTP to invoke methods a Web service provides. The bottom line is that we have true language and platform integration . Simple Object Access Protocol (SOAP) and XML are also two key pieces of the Web services architecture.

What is a Web Service

Web services constitute a distributed computer architecture made up of many different computers trying to communicate over the network to form one system. They consist of a set of standards that allow developers to implement distributed applications – using radically different tools provided by many different vendors – to create applications that use a combination of software modules called from systems in disparate departments or from other companies.

A Web service contains some number of classes, interfaces, enumerations and structures that provide black box functionality to remote clients. Web services typically define business objects that execute a unit of work (e.g., perform a calculation, read a data source, etc.) for the consumer and wait for the next request. Web service consumer does not necessarily need to be a browser-based client. Console-baed and Windows Forms-based clients can consume a Web service. In each case, the client indirectly interacts with the Web service through an intervening proxy. The proxy looks and feels like the real remote type and exposes the same set of methods. Under the hood, the proxy code really forwards the request to the Web service using standard HTTP or optionally SOAP messages.

Web Service Standards

Web services are registered and announced using the following services and protocols. Many of these and other standards are being worked out by the UDDI project, a group of industry leaders that is spearheading the early creation and design efforts.

Universal Description, Discovery, and Integration (UDDI) is a protocol for describing available Web services components. This standard allows businesses to register with an Internet directory that will help them advertise their services, so companies can find one another and conduct transactions over the Web. This registration and lookup task is done using XML and HTTP(S)-based mechanisms.

Simple Object Access Protocol (SOAP) is a protocol for initiating conversations with a UDDI Service. SOAP makes object access simple by allowing applications to invoke object methods or functions, residing on remote servers. A SOAP application creates a request block in XML, supplying the data needed by the remote method as well as the location of the remote object itself.

Web Service Description Language (WSDL), the proposed standard for how a Web service is described, is an XML-based service IDL (Interface Definitition Language) that defines the service interface and its implementation characteristics. WSDL is referenced by UDDI entries and describes the SOAP messages that define a particular Web service.

ebXML (e-business XML) defines core components, business processes, registry and repository, messaging services, trading partner agreements, and security.

Implementing Web Services

Here comes a brief step-by-step on how a Web service is implemented.

  • A service provider creates a Web service
  • The service provider uses WSDL to describe the service to a UDDI registry
  • The service provider registers the service in a UDDI registry and/or ebXML registry/repository.
  • Another service or consumer locates and requests the registered service by querying UDDI and/or ebXML registries.
  • The requesting service or user writes an application to bind the registered service using SOAP in the case of UDDI and/or ebXML
  • Data and messages are exchanged as XML over HTTP

Web Service Infrastructure

Even though Web services are being built using existing infrastructure, there exists a strong necessity for a number of innovative infrastructures. The core architectural foundation of Web services are XML, XML namespaces, and XML schema. UDDI, SOAP, WSDL, ebXML and security standards are being developed in parallel by different vendors

Web Services Technologies and Tools

There are a number of mechanisms for constructing Web services. Microsoft has come out with a new object-oriented language C# as the development language for Web services and .NET framework. Microsoft has an exciting tool called Visual Studio .NET in this regard. The back end database can be Microsoft SQL Server 2000 in Windows 2000 Professional.

Sun Microsystems has its own set of technologies and tools for facilitating Web services development. Java Servlets, Java Server Pages (JSPs), Enterprise JavaBeans (EJB) architecture and other Java 2 Enterprise Edition (J2EE) technologies play a very critical role in developing Web services.

There are a number of tools for developing Web services. They are Forte Java IDE, Oracle JDeveloper, and WebGain Studio.

Sun Microsystems has taken an initiative called Sun ONE (Open Network Environment) and is planning to push Java forward as a platform for Web services. It is developing Java APIs for XML-based remote procedure calls and for looking up services in XML registries – two more JAX family APIs: JAX/RPC (Java API for XML Remote Procedure Calls) and JAXR (Java API for XML Registries). These will wrap up implementations of Web services standards, such as SOAP and UDDI.

IBM also for its part has already developed a suite of early-access tools for Web services development. They are Web Services Toolkit (WSTK), WSDL Toolkit, and Web Services Development Environment (WSDE).

Apache Axis is an implementation of the SOAP (“Simple Object Access Protocol”) submission to W3C.

From the draft W3C specification:

SOAP is a lightweight protocol for exchanging structured information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.

Apache Axis is an Open Source SOAP server and client. SOAP is a mechanism for inter-application communication between systems written in arbitrary languages, across the Internet. SOAP usually exchanges messages over HTTP: the client POSTs a SOAP request, and receives either an HTTP success code and a SOAP response or an HTTP error code. Open Source means that you get the source, but that there is no formal support organization to help you when things go wrong.

Conclusion

For the last few years, XML has enabled heterogeneous computing environments to share information over the Web. It now offers a simplified means by which to share process as well. From a technical perspective, the advent of Web services is not a revolution in distributed computing. It is instead a natural evolution of XML application from structured representation of information to structured representation of inter-application messaging.

Prior to the advent of Web services, enterprise application integration (EAI) was very difficult due to differences in programming languages and middleware used within organizations. This led to the situation where interoperability was cumbersome and painful. With the arrival of Web services, any application can be integrated as long as it is Internet-enabled.

It is difficult to avoid the popularity and hype that is surrounding Web services. Each software vendor has some initiative concerning Web services and there is always great speculation about the future of the market for them. Whichever way it turns out, Web service architectures provide a very different way of thinking about software development. From client-server to n-tier systems, to distributed computing, Web service applications represent the culmination of each of these architectures in combination with the Internet.