You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Jeff MAURY <je...@jeffmaury.com> on 2008/10/10 18:55:53 UTC
SOAP DSML Gateway
Hello,
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.
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 ?
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.
Any remarks ?
Jeff MAURY
--
La mélancolie c'est communiste
Tout le monde y a droit de temps en temps
La mélancolie n'est pas capitaliste
C'est même gratuit pour les perdants
La mélancolie c'est pacifiste
On ne lui rentre jamais dedans
La mélancolie oh tu sais ça existe
Elle se prend même avec des gants
La mélancolie c'est pour les syndicalistes
Il faut juste sa carte de permanent
Miossec (2006)
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.lastfm.fr/listen/user/jeffmaury/personal
Mes CDs à récupérer:
http://spreadsheets.google.com/ccc?key=pNeg4Doa_oCsh7CepKPaPTA&hl=en
Re: SOAP DSML Gateway
Posted by Emmanuel Lecharny <el...@gmail.com>.
Jeff MAURY wrote:
>> 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.
>>
>
> Can you give me some pointers about this API ?
>
it's in the apacheds/core project. The main class is CoreSession.java,
which allows you to create a new "LDAP session", and then to invoke the
LDAP operations (add, search, etc).
The best way to get a clue about how it should be used can be found in
the apacheds/core-integ project, in the tests package
org.apache.dorectory.server.core.jndi.referral. It contains a test for
each operation, with JNDI and Core API use.
A bit far from perfect, but a good start...
>> 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.
>>
>
> My intention is to start with a prototype. Of course, the authentication
> will be managed by the proxy.
>
Just fine.
Just post any question you have, we will try to help you as much as
possible.
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: SOAP DSML Gateway
Posted by Jeff MAURY <je...@jeffmaury.com>.
On Fri, Oct 10, 2008 at 7:16 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> 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.
Can you give me some pointers about this API ?
>
>
> 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.
My intention is to start with a prototype. Of course, the authentication
will be managed by the proxy.
Regards
Jeff MAURY
>
> Any remarks ?
>>
>> Jeff MAURY
>>
>>
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
--
La mélancolie c'est communiste
Tout le monde y a droit de temps en temps
La mélancolie n'est pas capitaliste
C'est même gratuit pour les perdants
La mélancolie c'est pacifiste
On ne lui rentre jamais dedans
La mélancolie oh tu sais ça existe
Elle se prend même avec des gants
La mélancolie c'est pour les syndicalistes
Il faut juste sa carte de permanent
Miossec (2006)
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.lastfm.fr/listen/user/jeffmaury/personal
Mes CDs à récupérer:
http://spreadsheets.google.com/ccc?key=pNeg4Doa_oCsh7CepKPaPTA&hl=en
Re: SOAP DSML Gateway
Posted by Jesse McConnell <je...@gmail.com>.
> 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
Re: SOAP DSML Gateway
Posted by Emmanuel Lecharny <el...@gmail.com>.
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