You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Srinath Perera <he...@opensource.lk> on 2003/10/25 17:43:41 UTC

Re: JSR 109 implementation for Apache (architecture for discussion )

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