JSRI09 implementation
This is just an opening point to the discussion. This may change completely and there is lot to improve here. Shall we perform a Brainstorm upon this? Please feel free to add your comment, I will look at it and arrange thing in order time to time.
Server side Implementation
The JSR109 implementation is a tool that generates a web service and other necessary code to wrap an EJB. The EJB is running in the Container and the Web Service running in a JAX-RPC run time will expose that EJB as a web service.
This is how it looks like when the Wrapper Web service is generated and deployed in the JAX-RPC runtime.
Put it very simply there is a Jaxrpc-runtime has WS and a J2EE container has a EJB. We are fill the implementation of the WS so as to lookup the service and invoke ejb.
Client side Implementation
Initial thought: -
There are two cases to adressed here, The Client stub's and Dynamic proxy. We will support only the stub's first.
What we need id WSDL2Java with
jaxrpc-mapping support JAXR support with the support of the Ias jaxrpc-mapper we are supporting first one now. The JAXR supported is TODO
JSR109 implementation (Concrete view)
WHAT DOES IT DO?
The JSR109 implementation is a tool that generates a web service and other necessary code to wrap an EJB. The EJB is running in the Container and the WebService running in a JAX-RPC run time will expose that EJB as a webservice.
the code we have in the sf.net support follwing two senario's
1)(webservice.xml + jaxrpcmapper.xml + x.wsdl) --ws4j2ee-> (wrapping webservice and axis classes + ejb classes + ejb-jar.xml)
2)(ejb classes + ejb-jar.xml) -ws4j2ee-> (webservice.xml + jaxrpcmapper.xml + x.wsdl + wrapping webservice and axis classes)
The tool when the DD + webservice.xml is avalible
The tool when the DD + webservice.xml is not avalible
HOW DOES IT IMPLEMENTED
In most abstract view the tool does two things.
#Parse the WSDL and other deployment files and populate the information in the Data structures. #Use that populated information and generate the code.
We should keep these two things separated. Namely the Code generation part should not aware of the parsing mechanism. We should lay out a well defined interface between these two things.
The purposed Interface is J2EEWebServiceContext it has following sets of interfaces
#Set of interfaces that expose the info taken from JAX-RPC (Ias) #Set of interfaces that expose the info taken from WSDL (Srinath) #Set of interfaces that expose the info taken from web service .XML (Chatura). #Set of interfaces that expose the information from the ejb.xml file. We should use the Geronimo parser ... we will hide it behind our Interface.)
The Code generation part must not access the parsed information anyway other than though these interfaces. Possible exception may be use of JAXB implementation. But in such cases it should be discussed in the mailing list.
Whoever parsed the Configuration file or the WSDL should populate the data behind one of the above interfaces. We are using JAXB to parse the DD's. we use jaxrpc mapper when we have the WSDL and use the WSDL2Java when we do not have theWSDL.
to see the code please see the ews wesbservice's project CVS.
WSDLs and configuration file PARSING.
#WSDL (Srinath) #jaxrpcmapping (Ias) #ejb xml file #webservice.xml (Chatura)
We will write code to support what Geronimo not support now. We have to decide do we add this code to geranimo Deployment Code.
'''CODE GENERATION'''
Here is the purposed framework for the code generation. To explain the framework made of the modules (e.g EJB generation module, Wrapping web service generation module, WSDL generation module, Client stub generation module etc )
There is a interface called Genrator that represent a module writer
{{{ Generator{
- + generate();
- } }}}
When you call generate() method everything in the module should generated.
Each module consist of one or more files. The Writer represent a writer that write a single file. (e.g WebService Wrapper writer.)
Writer{ + writeCode(); }
When u call writeCode() on a Writer the file associate with the writer should be generated.
There are two factories for the Generator and Writer. This will hide the concrete impls. This framework will make sure
#Easy to adjust or change (module or files genaration.) #Every body will use same model for code generation
Here is a list of areas and the people's interests. That is not final but just to keep track.
1) JAXRPC Mapping file Parser (Ias) 2) Webservice .xml Web.xml or ejb.xml parser's we will be using JAXB. We are having the parser based code right now but are moving to replace them with JAXB code 3) Code genaration framework .. puting all the peices together is done. (srinath) 4) Wrapper WebService genarator:- We worte a primetive code that only do the look up and acsess the ejb. Mapping of the Webservice context to the ejb context is to be done. 5)ws utils - simple code that support only the lookup is done. 6)EJB writer - done , but uses different style we are change's it to use the same style as the other code genarations.
Here is the purposed plan.
1) We should start with the file parsing (1), (2), (3), (4) as it is independent from other decisions. For (1|2|3) I proposed to use DOM and programming model used at the wsdd deployment package of the axis. For WSDL (4) I proposed to use best from Axis WSDL package parsing code (with Ias help we should improve it, if we can do better.)
2) We should decide what is to be generated. We should try writing the needed class manually and seeing the result. (The Richard is working on it.)
3) Let us have our prototype code put in to a CVS and discuss about it.
4) Here is the proposed package structure. This is just a blind hit. (We need your ideas to finalize it.) I will put a copy to WIKI as well.
To see the src stucture please see http://cvs.sourceforge.net/viewcvs.py/ews/contrib/
Security
The specification says that the web server should pass the security information (say BASIC-AUTH: user name and the password) to the J2EE server so that server can authenticate the User. To talk with the J2EE server the web server should use RMI-IIOP over SSL. The Authorization should be handling by the J2EE server.
If the security information is reside in the SOAP message it follows the same path. The web server will pass the information to the J2EE server over a secure connection.
There are two Questions to be answered
1) When to have the security? The deployment descriptor (I am not sure which one yet) should specify that should the web server use the RMI-IIOP over SSL to access the J2EE server. The generating wrapping web service will differ accordingly.
2) How the wrapper web service accesses the security information (How to access the MesssageContext) is an issue. I believe that JSR109Utils package is for the things like that. We should negotiate with the Axis to give us a path. We could write a new Provider but Simple answer could be a static method in JSR109Utils to get accesses to the MessageContxt. We are using a new provider to do that.
We greately appreciate your comments at the geronimo-dev mailing lists - JSR109 team.