directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse McConnell" <jesse.mcconn...@gmail.com>
Subject Re: SOAP DSML Gateway
Date Fri, 10 Oct 2008 17:27:53 GMT
> 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


imo, if your going to go through the hassle of building a war, then you
should just bundle what you need in it and not worry about the j2ee
container your going into.  if you want to deploy into a j2ee container and
leverage its config then build and ear and do whatever you need to do with
that....

the nice thing about running with a plain war and not messing with j2ee bits
is you can deploy into jetty or tomcat (jetty! jetty!) easier...


> 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.



I can't speak directly to DSML but you should be able to do the
authentication bits and whatnot in jetty pretty easy.  We have a JAAS ldap
connector that I have tested with apacheds that maybe could be leveraged
somehow and am sure these smart apacheds guys would have other ideas...

I like the embedding jetty approach for the working prototype fwiw, it
_should_ let you get working on the meat of your issue without messing too
much...perhaps it would even be possible to deploy such a gateway war
directly into the embedded ads jetty instance and plugin that
functionality...just stabbing in the dark there though...I just lurk on the
these lists :)

jesse

-- 
jesse mcconnell
jesse.mcconnell@gmail.com

Mime
View raw message