Hi All, Jeremy, Richard this is a fix for the Jeremy's comment. The changes are given down here and the architecure doc is updated as well.
it is @ http://www.cse.mrt.ac.lk/~hemapani/JSR109/architecture.html sorry about not answering other comments. I will come back on monday. (I am having problem checking mails on my reguler account and rading mails from archives.) And for the Richard I was reading few of your articles and thinking you are the person for the 6 in the list :) thanks for Aaron Mulder i will send the images on the monday. thanks for help. thanks Srinath Changes -- About the DD parsing -------------------- * (As Jeremy said we have to make sure there is no overlapping of work with geranimo. Only thing to worry is we should think of the case that JSR109 standalone. Say for JonAs. We should have clear interfaces for the interaction and have the required Geronimo code as a jar (may be). I believe we can work it out.) you should hook the XML parsing stuff into Geronimo's deployment mechanism - I believe Aaron Mulder was already asking what, if any, additional elements were needed in the vendor DDs. We want to avoid the case where the same XML gets parsed many times by many services. This should also be integrated with Geronimo's MBean model so that the web services specific components are manageable. 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 accesses the J2EE server. The generating wrapping web service will differ accordingly. 2)How the wrapper web service accesses the security information (How to accesses 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 should define a common interface for this process to easily deal with the case that JAX-RPC runtime is not Axis. (Unfortunately they have to do a small change to their code.) * Any body has better answer for 2 here. >A couple of comments on the architecture page: >I don't see any mention of client side support (e.g. using a web >service >from an EJB) - is this something you are planning to address? >You should hook the XML parsing stuff into Geronimo's deployment >mechanism - I believe Aaron Mulder was already asking what, if any, >additional elements were needed in the vendor DDs. We want to avoid >the case where the same XML gets parsed many times by many services. >This should also be integrated with Geronimo's MBean model so that the >web services specific components are manageable. >Can you define the hooks into the security services e.g. how you would >support future message level authentication (I would like to know we >had >at least considered some of the security issues). >-- >Jeremy
