> 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 [EMAIL PROTECTED]
