axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Thomas Manes <>
Subject Re: Roger's Rules for Web Services
Date Thu, 17 Nov 2005 01:24:59 GMT
I think it depends on how far reaching you need the services to be.

If you are a company like eBay or Amazon that wants mass consumers to
consume the service, you should [currently] avoid all soap headers -- even
WS-Security. That's because lots of SOAP implementations for scripting
languages don't support WS-Security.

If you are building services that will be consumed by partners or
professional consumers, I think it's quite reasonable to use widely
implemented standard soap headers -- which today means WS-Security. But you
should generally avoid other headers, including pre-standard soap headers
(WS-Addressing, WS-RM, etc), and home-grown non-standard soap headers. But
you should always let your application requirements dictate your decisions.
Depending on the circumstances and the nature of the relationships with the
consumers, it might be more reasonable to use a pre-standard or home-grown
soap header than putting infrastructure info in the soap body. In general,
it's better to use pre-standard headers than home-grown headers.

If you are building services that will be used internally where you have
control over both sides of the conversation, then you definitely should use
WS-Security, and it's better to put infrastructure info into headers than in
the soap body.


On 11/16/05, Soactive Inc <> wrote:
> I would interpret this to mean that it may be a bad practice to invent
> your own custom headers (could SOAP or HTTP) that someone is not familar
> with or is not a standard. That said, I agree that any
> security/access-related info needs to be part of the SOAP headers
> (WS-Security/SAML, etc.) or HTTP headers (Basic Auth) but NOT the
> body/payload.
> -Arun
> On 11/16/05, Paul Barry <> wrote:
> >
> > What do you think of this comment?
> >
> > But don't get too creative and stuff names and passwords into cute
> > spaces in headers and such. The more you get inventive here, the
> > harder it is for others to use the services.
> >
> > First of all, is he referring to HTTP headers or SOAP headers.
> > Assuming SOAP headers, if you are using the "user name and password in
> > every call" style, wouldn't it make sense to include that in the SOAP
> > header rather than the body? or is that a bad idea?
> >
> > On 11/13/05, Anne Thomas Manes <> wrote:
> > > Great article by Roger Sippl:
> > >
> > >
> > >
> >

View raw message