Hi Joe, Thanks for your answer. Could you elaborate a little bit about the authentication object? Was that part of the SOAP message?
Thanks Vikas -----Original Message----- From: Joe Plautz [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 16, 2004 1:09 PM To: [EMAIL PROTECTED] Subject: Re: Best Practice I think at a minimum, you use https. For actual authorization, I've had to create a home brew of sorts because of the way we store use information. This forces clients to send an authentication object as part of the message. There seem to be much more elegant solutions involving headers and such, but they almost always require a central user database, a luxury I don't have. But, this is not the first time that I have seen it implemented this way. Where I used to work, which got into web services several years ago just before a lot of the specifications have come out, also implemented authentication using a user authentication object. Hope this helps, Joe Plautz Vikas Phonsa wrote: > I would appreciate if someone could comment on the security and > authorization aspects of the web services. > > What is everybody using in that regard? > > Thanks > Vikas > > > -----Original Message----- > From: Joe Plautz [mailto:[EMAIL PROTECTED] > Sent: Tuesday, November 16, 2004 10:59 AM > To: [EMAIL PROTECTED] > Subject: Re: Best Practice > > I'll try and be more positive next time. I was trying to be impartial > ;-) I do agree that the developer doesn't have to deal much with the > WSDD. Using the ant axis tasks should be a best practice. It does > automate a lot of stuff that doesn't need to be dealt with. I would > actually go farther and say that it would be nice to be able to go from > class to WSDD in one easy step. Create your business classes, generate > the WSDD, deploy. I think the step of generating the WSDL from the class > > and then generating the server side "clutters" the process up a little > bit. It's another source of potential error. > > Anand Natrajan wrote: > >>I agree with Joe's analysis overall, but I would be a bit more > > positive > >>about approach #2. In this approach, you generate a Java class and use > > that > >>you deploy your service. That's Joe's preferred approach and mine as > > well. > >>However, the developer really doesn't have to diddle with WSDDs... or > > even > >>WSDLs for that matter. The Ant task for generating them - wsdl2java - > > isn't > >>that hard, and once learnt, it's dead easy to retain. In fact, here it > > is, > >>for posterity. ((: >> <axis-wsdl2java >> output="${wsdl.build.dir}" >> url="${wsdl.build.dir}/${wsdlName}.wsdl" >> serverside="true"> >> <mapping namespace="urn:${wsdlName}" >> package="com.abc.ws.stubs"/> >> <mapping namespace="urn:APICommon" >> package="com.abc.api.common"/> >> </axis-wsdl2java> >>This snippet assumes your common classes, e.g., data structures, are > > in the > >>com.abc.api.common package, and you want to give them a namespace of >>APICommon. Everything else is pretty straightforward. >> >>The above task makes classs-to-WSDL-to-WSDD generation really easy. > > The > >>developer has to deal with Java and Ant alone, not WSDDs and WSDLs. > > The only > >>gripe I have with this process is that Axis's wsdl2java insists on > > putting > >>_client-side_ stubs in the same directory as _server-side_ WSDDs. > > There's no > >>getting around that because both get generated in the same task. > > Annoying, > >>but we can live with it. >> >>Anand >> >>On Tue, 16 Nov 2004, Joe Plautz wrote: >> >>: Funny you should ask this question. >>: >>: When I asked it about 6 months ago it spawned a week long thread > > that, > >>: in my opinion never reached a conclusion. But, this is what I > > gathered > >>: from it. There are three schools of thought when it comes to > > creating > >>: Axis web services. 1) Start with a WSDL and generate your code from >>: that. 2) Start with a class and generate a WSDL so that you can > > generate > >>: the WSDD. 3)Start with a JWS or message service that accepts a > > string > >>: and parse it with Castor or some other xml binding engine. Remember > > each > >>: one has it's own specific merits and drawbacks. >>: >>: 1) The WSDL approach; you start with a WSDL and it is rather simple > > to > >>: create. Plus, it's the one location where you define your service. > > And > >>: then everything gets generated. The drawback comes in when you add >>: future functionality, you end up regenerating things over and over >>: again. And if you've added any functionality to any of the generated >>: classes outside of the impl class, you have to be careful when doing >>: your generation, it will get over written. >>: >>: 2) The class approach; you start with a class, I don't think there > > is an > >>: easier starting point for java developers. You create your code and >>: expose it to the world using the WSDD's. The drawback of this is >>: generating the WSDD's. WSDD's are a little bit more complicated than >>: WSDL's. You could create them by hand, but it's more prone to error. > > And > >>: to generate them you have to be pretty comfortable in ant, it can be >>: very hackish. >>: >>: 3) The String approach; I've never attempted using this approach but >>: there is a relatively popular article that recommends this. If you > > are > >>: heavily invested into Castor or some other framework, I see the > > merits > >>: of implementing this approach. Also, you theoretically could get by > > with > >>: exposing only one service. The drawbacks of this, you're adding > > another > >>: layer to an increasingly complex puzzle. Axis does all of the > > parsing > >>: for you already, why add another layer? >>: >>: I couldn't tell you which technique is the most popular, I would say >>: that the WSDL and Class approaches are the most common and are split >>: fairly evenly. The people that I've have personally run into have > > used > >>: the class approach exclusively. But, some of them were exposing > > EJB's so > >>: take that with a grain of salt. >>: >>: As for books/documentation, keep waiting for an Axis specific book. > > None > >>: exist show what you can really do with this technology. Most just >>: explain the architecture. One thing I have noticed though, version > > 1.2 > >>: documentation is way better than version 1.1. >>: >>: For tools, Mindreef SoapScope, is an excellent testing tool. Reads > > in > >>: and validates WSDL's. You can also test the service by inputing data >>: into a form. I use this all the time. Cape Clear has a WSDL tool > > that > >>: I've used a couple times. Very easy to create a WSDL from scratch. >>: >>: Axis is an excellent tool. It does have a lot of power in it and can > > be > >>: used in just about any way you wish. But, like EJB and other > > distributed > >>: technologies they need to be used where appropriate. Deciding where > > it's > >>: appropriate is something that comes with experience not reading it > > from > >>: somewhere. >>: >>: Have a great day, >>: Joe Plautz >>: >>: [EMAIL PROTECTED] wrote: >>: > >>: > Thanks, Nikki. >>: > >>: > We have a standard of complying to Basic Profile 1.0, for >>: > interoperability but, on top of that, I'm looking for generally > > accepted > >>: > good ways of doing stuff during development of web services > > servers and > >>: > clients. Beyond BP 1, are there useful ways to structure WSDL and > > type > >>: > definitions, are there any deployment tips, are there any patterns > > for > >>: > common problems in web services, tips on building and testing, and > > so > >>: > on. I've seen this sort of stuff for languages and technologies in > > the > >>: > past and, no doubt, best practices will emerge on web services, in > > the > >>: > future. Quite a good, thin, book of Java is "Java with Style" (or > > some > >>: > such title). It would be nice to have something like that for web >>: > services, but, until then, if anyone has produced anything in this > > vein, > >>: > that would be great. >>: > >>: > Thanks for the links. I was aware of them but don't think they > > have > >>: > anything specific on best practice, though some of the information > > might > >>: > prove useful for a best practices guide. >>: > >>: > Cheers, >>: > Tony >>: > >>: > >>: > >>: > >>: > Hi Tony >>: > >>: > Not sure what you're after in particular, >>: > >>: > For W3C's efforts in this area see links from > > http://www.w3.org/2002/ws/ > >>: > For OASIS efforts see http://www.oasis-open.org/specs/index.php >>: > >>: > For Axis there is the userguide, this list & if you search the > > archives of > >>: > this list for "books" you may find other helpful references. >>: > >>: > HTH >>: > Nikki >>: > >>: > --On Tuesday, November 16, 2004 11:41:41 +0000 > > [EMAIL PROTECTED] wrote: > >>: > >>: > > >>: > > Does no one have, or have knowledge of, any best practice in > > the web > >>: > > service arena? >>: > > >>: > > I'm looking for a set of hints and tips, rather than a 800 page > > book. > >>: > > >>: > > Tony >>: > > >>: > > >>: > > >>: > > Does anyone know of a published set of best practices, both for > > web > >>: > > services in general and Axis in particular? >>: > > >>: > > I've scoured the Net and found a few bits and pieces, but I'm > > looking for > >>: > > something more substantial (though not *too* substantial). >>: > > >>: > > Tony >>: > > >>: > >>: > >>: > >>: > ---------------------- >>: > NJ Rogers, Technical Researcher >>: > (Semantic Web Applications Developer) >>: > Institute for Learning and Research Technology (ILRT) >>: > Email:[EMAIL PROTECTED] >>: > Tel: +44(0)117 9287096 (Direct) >>: > Tel: +44(0)117 9287193 (Office) >>: > >>: > >>: >>. >> > > . >
