Jeff MAURY wrote:
Hello,
Hi,
I may need in the near future a SOAP DSML gateway on top of ADS. So, before
developing it standalone, I would prefer work for the community and
therefore, I am interested about the ADS people remarks.
So please read my general design ideas and questions about it.
1) Web service stack
The standard way of developing Web Service in J2EE is to use JAX-WS
annotations. However, this JCP has a major drawback in my opinion: it does
not address the deployment phase, so there is no way to build a WAR file
that can be deployed to any J2EE container, each implementation will have
its own way of declaring the Web Services. So we have two choices:
- build an incomplete WAR and let's the user complete the task (not my
prefered given the complexity of J2EE)
- use a specific open source WS stack like Axis2, CXF or Spring WS to
build the WAR. The pro of this solution is that we just need to deploy the
WAR file, the con is that is will not use the WS stack of the target J2EE
container.
Not really my favorite field, I will let others comment about such a choice.
2) Interface for ADS
Even if the first implementation will use LDAP to communicate with ADS, I
think we should address the case where the gateway will be embedded into ADS
(with Jetty, I've heard the work is planned to already started). So my
question is: is there an internal API inside ADS that allows direct calls
between a client and ADS ?
You have three possibilities :
1) develop your solution on top of JNDI, and communicate with a remote
LDAP server. There are obvious problems with this approach, one of them
is that you can't transmit a MessageId using JNDI.
2) develop your solution on top of JNDI, but using the JNDI layer we
have developped. The big difference with solution #1 is that you don't
anymore communicate with ADS through the network. The problems remain
the same than with sol. #1
3) We have a brand new API which is wrapped on top of ADS, but it may
need to be polished. (this is the main drawback). But the biggest
advantage is that you can't be closer to the Ldap semantic.
I think that sol. #3 should be favored, even if it requires to tweak the
current code to get a better API.
FYI, ADS 1.5.5 will contain Jetty embedded, but it might be a good idea
to define a solution which is not tight to jetty. We should deploy a
war, whatever servlet engine we use. The idea behind Jetty embedding is
to offer a convenient all-in-one solution for users.
3) There is still an issue with the authentication: the DSML has an
Authentication element but it does not store the credentials, only the
identification of the user. So my recommandation is to extract the missing
information from the communication: password is basic authentication has
been done, certificate if Client SSL has been used,.... I have seen that a
DSML parser exists in the Studio, I think I can reuse it with some small
modifications.
DSML does not deal with authentication. It has to be done at the upper
layer, when the user establishes the connection. The biggest problem is
that WebService are basically a connectionless mode, when Ldap is a
connected protocol. Nothing new for those used to deal with HTTP, but
that mean some session management on the proxy. Assuming that a user
first authenticate himself on the WebServer, we will have to reuse this
authentication to log on the server.
But this is a very first rough suggestion, it has to be refined in order
to implement the correct solution. At this point, a working prototype
might help.
Any remarks ?
Jeff MAURY
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
