Yes it was. It's something the carries application specific information as well as customer and user specific information. It's not great by any means, but it doesn't allow access either. But, by doing it this way, I've tried to keep the services as more of one time shots. Not as something that needs to be called over and over again in rapid succession.

Vikas Phonsa wrote:
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)
: >
: >
:
.


.


.

Reply via email to