Return-Path: Delivered-To: apmail-ws-axis-dev-archive@www.apache.org Received: (qmail 61481 invoked from network); 4 Sep 2004 15:30:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 4 Sep 2004 15:30:46 -0000 Received: (qmail 7471 invoked by uid 500); 4 Sep 2004 15:30:42 -0000 Delivered-To: apmail-ws-axis-dev-archive@ws.apache.org Received: (qmail 7416 invoked by uid 500); 4 Sep 2004 15:30:42 -0000 Mailing-List: contact axis-cvs-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-cvs@ws.apache.org Received: (qmail 7403 invoked by uid 99); 4 Sep 2004 15:30:42 -0000 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.28) with SMTP; Sat, 04 Sep 2004 08:30:39 -0700 Received: (qmail 61454 invoked by uid 1762); 4 Sep 2004 15:30:38 -0000 Date: 4 Sep 2004 15:30:38 -0000 Message-ID: <20040904153038.61453.qmail@minotaur.apache.org> From: hemapani@apache.org To: ws-axis-cvs@apache.org Subject: cvs commit: ws-axis/contrib/ews/docs/src list2.txt run.txt web.xml list4.txt list1.txt webservice.xml list3.txt list5.txt service-ref1.xml ejb-jar.xml X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N hemapani 2004/09/04 08:30:38 Modified: contrib/ews/docs ews.css index.html Added: contrib/ews/docs/images ews-tool.gif ews-context.gif ews-invoke.gif ews-PCWframework.png ews-codegen.gif ews-archi.gif contrib/ews/docs architecture-guide.html Geronimov-ewsIntegration.html security.html intro.html Geronimov-axisIntegration.html transaction.html client.html ws4j2ee.html contrib/ews/docs/src list2.txt run.txt web.xml list4.txt list1.txt webservice.xml list3.txt list5.txt service-ref1.xml ejb-jar.xml Log: update the ews documentation Revision Changes Path 1.1 ws-axis/contrib/ews/docs/images/ews-tool.gif <> 1.1 ws-axis/contrib/ews/docs/images/ews-context.gif <> 1.1 ws-axis/contrib/ews/docs/images/ews-invoke.gif <> 1.1 ws-axis/contrib/ews/docs/images/ews-PCWframework.png <> 1.1 ws-axis/contrib/ews/docs/images/ews-codegen.gif <> 1.1 ws-axis/contrib/ews/docs/images/ews-archi.gif <> 1.2 +41 -21 ws-axis/contrib/ews/docs/ews.css Index: ews.css =================================================================== RCS file: /home/cvs/ws-axis/contrib/ews/docs/ews.css,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- ews.css 13 Jun 2004 16:12:09 -0000 1.1 +++ ews.css 4 Sep 2004 15:30:38 -0000 1.2 @@ -1,35 +1,55 @@ -.example { - BACKGROUND: #ccccff +.example { + background:#ccccff } + .xml { - BACKGROUND: #eeeeee + background:#eeeeee } + .java { - BACKGROUND: #eeeeee + background:#eeeeee } -H2 { - BACKGROUND-COLOR: #ffdda8 -} -H3 { - BACKGROUND-COLOR: #ffdda8; +body { + background-color:#FFFFFF; + font-family: Verdana, Arial, Helvetica, sans-serif; + margin-left: 40px; + color:#000000 } -H1 { - BACKGROUND-COLOR: #ffdda8; + +h2 { + text-decoration: underline; + background-color: #DCE1FF; + background-position: left; + margin-left: -30px} + +h3 { + margin-left: -10px } -code { - BACKGROUND-COLOR: #ffeefa; +h1 { + margin-left: -30px } -.note { - FONT-WEIGHT: bold + +.note { + font-weight:bold; } -.head { - FONT-WEIGHT: bold; FONT-SIZE: 240%; TEXT-ALIGN: center + +.head { + font-weight:bold; + font-size: 240%; + text-align: center; } -TD.section { - FONT-WEIGHT: bold; FONT-SIZE: 180%; BACKGROUND-COLOR: #82adf6; TEXT-ALIGN: center + +td.section { + background-color: #82ADF6; + font-size: 180%; + text-align: center; + font-weight: bold; } -SMALL.red { - COLOR: red + +small.red { + color: red } + + 1.2 +6 -2 ws-axis/contrib/ews/docs/index.html Index: index.html =================================================================== RCS file: /home/cvs/ws-axis/contrib/ews/docs/index.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- index.html 13 Jun 2004 16:12:09 -0000 1.1 +++ index.html 4 Sep 2004 15:30:38 -0000 1.2 @@ -16,12 +16,16 @@

Documentation

1.1 ws-axis/contrib/ews/docs/architecture-guide.html Index: architecture-guide.html =================================================================== Architecture Guide

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.

1.1 ws-axis/contrib/ews/docs/Geronimov-ewsIntegration.html Index: Geronimov-ewsIntegration.html =================================================================== Geronimo � EWS Integration

Geronimo � EWS Integration

Here I am trying to extend the Proposal by Luis and Jeremy Geronimov Axis Integration.

The geronimo � JSR-109 Service Impl integration basically consists in the definition of a deployment architecture that defines the way how web services are implemented in Geronimo server and a set of interfaces that will be used by classes responsible for the ws's deployment.

How a web service request is served

  1. A servlet listener that will wait for soap calls. This servlet provide by Axis will act as a JAX-RPC handler and will be in charge to dispatch request either to POJOs or EJBs.
  2. The Axis webapp will be deployed at startup. Or if It's possible as soon as JAX-RPC handler is need.
  3. There will be only one web-app where will reside the listeners and impl for the web ws, and the proxys to call the ejb service impl.

Deployment

  1. We will extend existing module in charge of WAR and EJB-JAR deployment, to take into consideration specific ws deployment files.
  2. The Geronimo deployer will call the EWS tool and it will generate the implementation classes + DD looking at the web service module. The EWS will take care of the parsing of the JSR109 specific DD (webservice.xml file and jaxrpc mapping file.) For avoid the web.xml and ejb-jar.xml are parsed twice EWS hope to use Geronimo DD mechanism (to my understating that can done via GBeans.) But right now EWS use DOM to parse them.
  3. The implementation classes will contains a web service. To deploy the webservice in the Axis 3 things should be done.
    • the classes in the webservice should be loaded to the WebContiner
    • the web service can be deployed in Geronimo using the Axis AdminClient
    • The web service Client side stubs should be generated and the service interface (XXLocator) should be bind under the JNDI context. (if service mappings defined)
    • The WSDL file of the Web service should be published in the JAXR registry
  4. If the implementation bean is based on EJB the EWS will generate an EJB that used the Session Bean. The Geronimo EJB-Jar deployment support will be used to deploy the generated EJB. The EJB should be Bind under the JNDI name as given in the Open EJB DD generated by the EWS.
  5. If we deployed the Axis webapp the first time a JAX-RPC handler is need, we will trigger an event that will do it

Concerns

  1. We have to be sure that the service has started after the web container, because our service depends on it. How do we manage dependencies??
  2. Is it possible to have more than one listener (JAX-RPC handler)
  3. How the �extend existing module in charge of WAR and EJB-JAR deployment� is done and we should decide how the EWS called from the module. I think to read and Loading the web service module, Class loading and parsing (created DDBeans and pass them in if that works or should I create the DDBeans myself.) the ejb-jar.xml and web.xml file EWS can use Geronimo services.
  4. To get the Geronimo Internal based implementation working. I think it is theoretically resolved but got to get it working.
1.1 ws-axis/contrib/ews/docs/security.html Index: security.html =================================================================== Security 1.1 ws-axis/contrib/ews/docs/intro.html Index: intro.html =================================================================== Introduction

Introduction to EWS

What is the EWS?

The project implements the support to add the web service support for a J2EE container. It provides a tool that generated the required code based on the �packaged J2EE web service� (explained in the third chapter) and the necessary runtime classes. EWS implementation is based on the JSR 109 �J2EE web services� specification by the JCP. It is also covered under the web service�s support for J2EE 1.4 specification. But it is not limited to the specification and in the security and the transaction the specification is exceeded.

How EWS does fits into the J2EE and Web service stacks?

EWS act as the part of the deploy tool for J2EE container to deploy the Web service in the J2EE container. EWS project provide a tool to accept the J2EE module as explained by the JSR109 specification and generated the required classes and the Runtime need to support the generated classes.


Figure: How the EWS fits in to the J2EE and Web services stack

What are the Goals of the EWS?

  1. Integrated the parts of the Web service implementations and bind them as a platform parallel to J2EE and fill any gaps. (E.g. Jaxrpc-mapping, specifying the Handler in the web service�s).
  2. Give the web services a programming model that is equivalent to the J2EE programming model. (Deploying a web service by writing an Interface + Implementation Bean and Deployment descriptors package it and deploy it in the Container. Then the Container should implement the supporting classes and make the web service available. .
  3. Let the Web service to be implemented based on the J2EE components and by doing so let it benefits from the value added services provide by the J2EE container.
  4. Define the security and transaction mapping from the web service to EJB and the EJB to web services. And make it possible to propagate transaction or the security information transparently through web service and EJBs.
  5. Make it possible for the application deployer to provide the transaction and security service to web service which are managed by the container and added by adding a new entry to deployment descriptor.

How Ways to write a J2EE web services?

There are two Ways to implements a J2EE web services

  1. J2EE web service based on Java Class.
  2. J2EE web service based on the Enterprise Java Bean

Aapplication developer should create following files.

  1. Service endpoint interface
  2. Implementation bean
  3. if web Service is based on EJB ejb-jar.xml or Web Service is based on Java Class web.xml file
  4. Webservices.xml file

Assembler Should packaged them to a Web Service Module.

Assembler should package those files in to a WAR file if it is the �scenario 1� and to an EAR file if it is �scenario 2�. Additionally EWS support deployment with JAR file as well.

Deployer should deploy the Web Service Module using the deploy tool.

How the Deployment of the Web Service Module Works?

When the above J2EE package is created the deployer will use the deploy tool called Ws4J2ee provided by the EWS project to deploy the web service in the J2EE container. According to the specification the deploy tool should do the following to deploy the web service in the J2EE container.

Validate the deployment artifacts

The deployment tool starts the deployment process by examining the deployable artifact and determining which modules are Web services enabled by looking for a webservices.xml deployment descriptor file contained within the module. Deployment of services occurs before resolution of service references. This is done to allow deployment to update the WSDL port addresses before the service references to them are processed.

Convert the Web services into standard J2EE artifacts

A Servlet is provided / generated to handle parsing the incoming SOAP request and dispatch it to an java implementation class or the EJB of the of the Web Service. The Java Implementation class if present can be act like another dependency class used by the above servlet. If the implementation is a stateless session bean the servlet obtains a reference to an instance of an appropriate EJBObject and dispatches the request to the stateless session EJB. How the request is dispatched to the Service Implementation Bean is dependent on the deployment tool and deploys time binding information supplied by the deployer. Deployment of each port-component is dependent upon the service implementation and container used. If Webservices.xml file has security of transaction information the servlet and other J2EE artifacts will have the required information to enable the Security and/or Transaction in both J2EE and Web Service Domains.

Deploy and publish the WSDLs

The deployment tool must deploy and publish all the ports of all WSDL documents described in the Web services deployment descriptor. The deployment tool updates or generates the WSDL port address for each deployed port-component. The updated WSDL documents are then published to a location determined by the deployer. It could be as simple as publishing to a file in the modules containing the deployed services, a URL location representing the deployed services of the server, a UDDI registry.

Resolving references to Web services

For each service reference described in the Web services client deployment descriptors, the deployment tool ensures that the client code can access the Web service. The deployment tool examines the information provided in the client deployment descriptor (the Service interface class, the Service Endpoint Interface class, and WSDL ports the client wants to access) as well as the JAX-RPC mapping information. In general the procedure includes providing an implementation of the JAX-RPC Service interface class declared in the deployment descriptor service reference, generating stubs for all the service-endpoint-interface declarations (if generated Stubs are supported and the deployer decides to use them), and binding the Service class implementation into a JNDI namespace.

Deployment of generated J2EE artifacts

Once the Web services enabled deployable artifact has been converted into a J2EE deployable artifact, the deployment process continues using normal deployment processes.

1.1 ws-axis/contrib/ews/docs/Geronimov-axisIntegration.html Index: Geronimov-axisIntegration.html ===================================================================


Geronimo – JSR-109 Service Impl Integration


The geronimo – JSR-109 Service Impl integration basically consists in the definition of a deployment architecture that defines the way how web services are implemented in Geronimo server and a set of interfaces that will be used by classes responsible for the ws's deployment..


The architecture proposal consist in:


  • A servlet listener that will wait for soap calls. This servlet provide by Axis will act as a JAX-RPC handler and will be in charge to dispatch request either to POJOs or EJBs.

  • The Axis webapp will be deployed at startup. Or if It's possible as soon as JAX-RPC handler is need.

  • There will be only one web-app where will reside the listeners and impl for the web ws, and the proxys to call the ejb service impl.

- Deployment


  1. We will extend existing module in charge of WAR and EJB-JAR deployment, to take into consideration specific ws deployment files.

  2. A service provided by the JSR-109 team will be used for the parsing of files descriptor related to ws like webservice.xml. If we deployed the Axis webapp the first time a JAX-RPC handler is need, we will trigger an event that will do it

  3. Once the parsing is done the binding in JNDI will occur.

  4. Then the service endpoint implementation given to axis. We will use Axis's integration facilities to register each ws in Axis's servlet.


The figure shows the ws deployent architecture defined for our proposal.









This figure shows the behavior of our proposal during deployment of apps.









Our concerns.

1. We have to be sure that the service has started after the web container, because our service depends on it. How do we manage dependencies. ?

2. Is it possible to have more than one listener (JAX-RPC handler) ?


1.1 ws-axis/contrib/ews/docs/transaction.html Index: transaction.html =================================================================== Transaction 1.1 ws-axis/contrib/ews/docs/client.html Index: client.html =================================================================== Client Implementation of EWS

Client Side Implementation

  1. The Service reference tags in the web.xml or ejb-jar.xml are parsed and the information about the web service is obtained.(This part is loosely implemented with DOM to parse the service reference).
  2. Using the WSDL file given the tool will generate the stubs to accesses the web service. This is done with Web service Client Stub generator tool with jaxrpcmapping file support which is implemented on the org.apache.geronimo.ews.jaxrpcmapping package. If WSDL does not exists wsdl should be generated from the SEI.
  3. The WSDL should be published in a registry (This part is not implemented).
  4. The generated Stubs should be bound to the JNDI name as specified in the service reference. This part is not implemented).
  5. 1.1 ws-axis/contrib/ews/docs/ws4j2ee.html Index: ws4j2ee.html =================================================================== WS4J2ee Tool

    WS4J2ee Tool

    Tools Functions

    1. Parse the webservice.xml file
    2. If wsdl file and jaxrpc mapping file does not exists create them using the SEI.
    3. Generate axis Skelton for axis using the "wsdl file".
    4. Generate ejb remote/local and home interface files if Web Service is based on EJB.
    5. generate the wrapper web service file.
    6. Generate the container DD if required.
    7. Generate the one jar file which has all information to deploy the service.

    The Architecture of Code generation tool

    Interestingly enough the architecture of the tool can be explained in the following Diagram.


    Figure: Ws4J2ee class composition

    The tool consists of three types of classes. They are Contexts, Parsers, and Generators. They are as a groups named as the XXContext, YYGenerator, XXparser in the Diagram. The Context is run time representation of the Deployment Descriptor or a module. The parser will parse what ever the actual representation of the module and generate the Context associated with the Module. Then the Generator use information in the Contexts and Generate the Deployment Descriptor, Java classes act.

    Each object is representing by the interfaces and there actual representations are hidden behind the Factory classes �XXFactory�. There is a Factory that Generate those factories and it is accepts in to the Ws4J2ee class (tools main class) as a parameter. Using that the Behavior of the tool can be altered programmatically without changing the code of the original tool.


    Figure: the components of the Project

    The Diagram shows the much more details structure of the Ws4J2ee tool. It shows the name of the each XXContext, XXParser and YYGenerator. Furthermore its shows the how the JAXB, Java2WSDL and the Jaxrpc mapper is used.

    The Context

    The communication of between the different parts of the code, especially between the above two part is done via a single object called J2EEWebserviceContext. This object followed the �Mediator Patten� without the Observing. It is passive and has the all the information collected through out the execution of the Programme and it is passed around the Programme. End of the parsing of the Input artifacts the J2EEContext has all the information populated inside itself, and then the code generation modules will make use of the J2EEWebserviceContext to get the required information.


    Figure: Composition of the J2EEWebserviceContext

    The J2EEWebserviceContext or �the Context� is made up of seven parts.

    1. The Webserivce Context � This is a runtime representation of the webserive.xml file.
    2. ) The WSDL context � information about the WSDL file.
    3. The JAXRPC Context - information about the jaxrpc mapping file.
    4. EJB context � runtime representation of the ejb module.
    5. Web context � runtime representation of the web module.
    6. Service reference Context � runtime representation of the service reference module.
    7. MiscInfo - this hold the Miscellaneous information.

    Each �XXContext� has set of interfaces and the actual implementations of the each context is Hidden behind the ContextFactory which uses the �Factory Patten�.

    The Parsing Module

    The EWS encounter a six deployment descriptors and one java class to parse. The java class is parsed by the Java2WSDL module and the WSDL context is passed in to the Context.

    Among the six deployment descriptors there are two deployment descriptors added to the JSR109, they are webservice.xml file and the jaxrpc-mapping file. For those two we are using (Java API for XML binding) JAXB to parse them.

    One XML file is a WSDL file and it is parsed by the Jaxrpcmapper which is an extension of WSDL2Java and Java2WSDL of axis.

    To parse the web.xml file and ejb-jar.xml and the service references the tool use DOM for the time been. We are considering possibility of using Geronimo DD parsing technique. (Use the method standalone, maybe we can get the information from Geronimo when our tool is used inside Geronimo).

    All the parsers are such that they are independent and they can be easily replaced by another parser that implements the required interfaces. All the information are populated in to the context and in the case of WSDLContext and JaxrpcMappingContext.

    The populated information is wrapper by Adapters to adept for the �XXContext� interfaces using the �Adepter Patten�.

    The Code Generation Framework

    The Code generation framework is composed of the two types of Objects called the Generator and Writers. The Generator represent a code module that take care of the generating a module. The Generator may have one or more Writers. Each writer will generate a single file. The code generator module is composed of number of Generators.

    Each concrete Writer and the Generator is hidden behind the Generator factory and the Writer factory. The framework is independent of the implementation of each writer and Generator.

    1.1 ws-axis/contrib/ews/docs/src/list2.txt Index: list2.txt =================================================================== package com.jwsbook.jaxrpc; public class BookQuoteBindingImpl implements com.jwsbook.jaxrpc.BookQuote,org.apache.geronimo.ews.ws4j2ee.wsutils.ContextAccssible{ private com.jwsbook.jaxrpc.BookQuoteEJB ejb = null; private org.apache.axis.MessageContext msgcontext; public BookQuoteBindingImpl(){} public void setMessageContext(org.apache.axis.MessageContext msgcontext){; this.msgcontext = msgcontext; } public com.jwsbook.jaxrpc.BookQuoteEJB getRemoteRef()throws org.apache.axis.AxisFault{ try { javax.security.auth.callback.CallbackHandler handler = org.apache.geronimo.ews.ws4j2ee.wsutils.security.jaasmodules. AutenticationCallbackHandlerFactory.createCallbackHandler(msgcontext); if(handler != null){ javax.security.auth.login.LoginContext lc = new javax.security.auth.login.LoginContext("TestClient", handler); lc.login(); } }catch (javax.security.auth.login.LoginException e) { e.printStackTrace(); throw org.apache.axis.AxisFault.makeFault(e); } try{ javax.naming.Context initial = new javax.naming.InitialContext(); Object objref = jndiContext.lookup("java:comp/env/ejb/"bookquote); com.jwsbook.jaxrpc.BookQuoteHome home = (com.jwsbook.jaxrpc.BookQuoteHome)objref; return home.create(); }catch (Exception e) { throw org.apache.axis.AxisFault.makeFault(e); } } public float getBookPrice(java.lang.String isbn) throws java.rmi.RemoteException,com.jwsbook.jaxrpc.InvalidIsbnException{ if(ejb == null) ejb = getRemoteRef(); return ejb.getBookPrice(isbn); } } 1.1 ws-axis/contrib/ews/docs/src/run.txt Index: run.txt =================================================================== JAX-RPC-MAPPER ============== written by Ias (iasandcb@tmax.co.kr) command-line: java -classpath target/ews-1.0.jar;target/lib/*.jar org.apache.geronimo.ews.jaxrpcmapping.WsdlToJ2ee target_wsdl -m jax-rpc-mapping_file -o output_dir example: java -classpath target/ews-1.0.jar;target/lib/*.jar org.apache.geronimo.ews.jaxrpcmapping.WsdlToJ2ee BookQuote.wsdl -m BookQuote.xml -o generated 1.1 ws-axis/contrib/ews/docs/src/web.xml Index: web.xml =================================================================== Apache-Axis MathFace MathFace Servlet testData.math.MathFaceImpl 1.1 ws-axis/contrib/ews/docs/src/list4.txt Index: list4.txt =================================================================== package com.jwsbook.jaxrpc; public interface BookQuote extends java.rmi.Remote { public float getBookPrice(java.lang.String isbn) throws java.rmi.RemoteException, com.jwsbook.jaxrpc.InvalidIsbnFault; } 1.1 ws-axis/contrib/ews/docs/src/list1.txt Index: list1.txt =================================================================== package com.jwsbook.jaxrpc; public class BookQuoteBindingImpl implements com.jwsbook.jaxrpc.BookQuote,org.apache.geronimo.ews.ws4j2ee.wsutils.ContextAccssible{ private com.jwsbook.jaxrpc.BookQuoteEJB ejb = null; private org.apache.axis.MessageContext msgcontext; public BookQuoteBindingImpl(){} public void setMessageContext(org.apache.axis.MessageContext msgcontext){; this.msgcontext = msgcontext; } public com.jwsbook.jaxrpc.BookQuoteEJB getRemoteRef()throws org.apache.axis.AxisFault{ try { if(msgcontext == null){ msgcontext = org.apache.axis.MessageContext.getCurrentContext(); } javax.security.auth.callback.CallbackHandler handler = org.apache.geronimo.ews.ws4j2ee.wsutils.security.jaasmodules. AutenticationCallbackHandlerFactory.createCallbackHandler(msgcontext); if(handler != null){ javax.security.auth.login.LoginContext lc = new javax.security.auth.login.LoginContext("TestClient", handler); lc.login(); } }catch (javax.security.auth.login.LoginException e) { e.printStackTrace(); throw org.apache.axis.AxisFault.makeFault(e); } try{ java.util.Properties env = org.apache.geronimo.ews.ws4j2ee.wsutils.PropertyLoader.loadProperties("jndi.properties"); javax.naming.Context initial = new javax.naming.InitialContext(env); Object objref = initial.lookup("ejb/bookquote"); com.jwsbook.jaxrpc.BookQuoteHome home = (com.jwsbook.jaxrpc.BookQuoteHome)javax.rmi.PortableRemoteObject.narrow(objref,com.jwsbook.jaxrpc.BookQuoteHome.class); return home.create(); }catch (Exception e) { throw org.apache.axis.AxisFault.makeFault(e); } } public float getBookPrice(java.lang.String isbn) throws java.rmi.RemoteException,com.jwsbook.jaxrpc.InvalidIsbnException{ if(ejb == null) ejb = getRemoteRef(); return ejb.getBookPrice(isbn); } } 1.1 ws-axis/contrib/ews/docs/src/webservice.xml Index: webservice.xml =================================================================== MathFaceService math.wsdl jaxrpc-mapping.xml MathFace ns1:math testData.math.MathFace MathFace 1.1 ws-axis/contrib/ews/docs/src/list3.txt Index: list3.txt =================================================================== package com.jwsbook.jaxrpc; public class BookQuoteBindingImpl implements com.jwsbook.jaxrpc.BookQuote{ private com.jwsbook.jaxrpc.BookQuote bean = null; private org.openejb.EJBContainer container; public BookQuoteBindingImpl(){ String containerID = "com.jwsbook.jaxrpc.BookQuoteBean"; org.openejb.ContainerIndex index = org.openejb.ContainerIndex.getInstance(); this.container = index.getContainer(containerID); } public float getBookPrice(java.lang.String isbn) throws java.rmi.RemoteException,com.jwsbook.jaxrpc.InvalidIsbnException{ java.lang.reflect.Method callMethod = org.apache.geronimo.ews.ws4j2ee.utils.Utils.getJavaMethod("com.jwsbook.jaxrpc.BookQuote","getBookPrice"); ContainerIndex index = ContainerIndex.getInstance(); int length = index.length(); for(int i = 0;i service/Joe javax.xml.rpc.Service WEB-INF/joe.wsdl WEB-INF/joe.xml sample.Joe JoePort 1.1 ws-axis/contrib/ews/docs/src/ejb-jar.xml Index: ejb-jar.xml =================================================================== math BookQuoteService MathFace testData.math.MathFaceHome testData.math.MathFace testData.math.MathFaceImpl Stateless Bean