EWS Architecture

Modules

  1. Ws4J2ee Tool to accept the Web Service Module and generate the required artifacts to deploy a J2EE web service.
  2. J2EE web Service Security implementation.
  3. J2EE Web Service Transaction information.
  4. Client Side implementation(This part is only partially implemented since this is J2EE Container specific.)

Architecture Diagram

The tool will generate invocation code and a EJB if required. The invocation code with the Axis core classes provides the servlet that Dispatch the SOAP messages. The EJB will have a dummy Remote (Local) interface and dummy Home (LocalHome) interface. They are for deploy the ejb in the container and there existence is transparent from the deployer EWS user.

Web Service Invocation


Figure: The Execution flow when the J2EE Web service is invoked.
  1. The WS client will send the SOAP request to axis.
  2. Axis will parse the SOAP request.
  3. Axis will call the request message handlers associated with the web service. (They will take care of the security and transaction mapping of the WS).
  4. Axis will create the Invocation code instance. (At this point the axis will find the implementation bean. If it is a java Class Axis may load it itself. If it is a EJB Invocation code call the J2EE container and get a reference to the service Implementation Bean of ejb. This may be service Implementation Bean itself or an indirect reference.).
  5. Then the invocation code will call the corresponding method in the service Implementation.
  6. If result exists it will be given to the axis. Axis will call the response handlers associated with the Web Service.
  7. The result is marshaled and sent to the Client as SOAP.

Invocation of Implementation Bean

Invocation of the Implementation bean when the Web Service is based on Java Class is simple as it is done in the same VM and it is just a java method call. The Implementation bean is initiated using the default constructer and the method is invoked. But the invocation When the Web Service is based on Stateless Session bean is complex as there are three of possible approaches.

  1. Use the Remote interface to invoke the Service Implementation Bean from the JAX-RPC runtime.
    	
    java.util.Properties env = PropertyLoader.loadProperties("jndi.properties");
    javax.naming.Context initial = new javax.naming.InitialContext(env);
    Object objref = initial.lookup("ejb/bookquote");
    BookQuoteHome home = (BookQuoteHome)PortableRemoteObject
    	
    	
  2. Use the Local interface to invoke the Service Implementation Bean from the JAX-RPC runtime. This is possible only if the web container and the J2EE Container reside in a Same Java Virtual machine.
    	
    Context initial = new javax.naming.InitialContext();
    Object objref = jndiContext.lookup("java:comp/env/ejb/"bookquote);
    BookQuoteHome home = (BookQuoteHome)objref;
    	
    	
  3. Use the internals of the J2EE container. This involved the least performance penalty but the implementation is specific to the Geronimo.
    	
    ContainerIndex index = ContainerIndex.getInstance();
    int length = index.length();
    for(int i = 0;i < length;i++){
        EJBContainer contianer = index.getContainer(i);
        if(contianer!= null){
            String name = contianer.getEJBName();
            if("BasicStatelessBean".equals(name)){
        	    Class bean = Class.forName("org.openejb.test.stateless.BasicStatelessBean");
                Object[] arguments = new Object[]{isbn};
                Object result = container.invoke(callMethod, arguments, null);
                return result;
             }
    	}
    }
    	
    	

Handling Security and Transaction

The security and transaction information are intercepted at the Axis Handlers and processed or propagated in to the J2EE container. For more information please refer to the security and transaction sections.