axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elaine Nance <>
Subject Re: Simple question....
Date Wed, 30 Mar 2005 16:50:00 GMT

I'm really a newbie to SOAP and Java, but I'd probably use a 
resource file and make it as simple as possible.

For example:
resource location	true/false

But I find that the simplest method which completely solves a 
problem is usually the best.  Unnecessary complexity in software 
should be against the law, except it's even worse to write 
unmaintainable code.


Scott Wilson wrote:
> Hi Elaine,
> I've got a similar problem to Dan, and haven't seen any great answers 
> posted to date...
> I'm doing some R&D on 'secure' federated resource discovery using SAML 
> to pass attributes about the principal to a bunch of repositories along 
> with their query.
> So far, so good. I have a nice federated search client that can talk SRW 
> & SAML, and signs its messages. (If you send SAML assertions, you really 
> must sign them).
> The only thing is, my search client also needs to be able to 
> cross-search repositories that are open access. In this case, the client 
> has to be configured such that if a target is known to support digital 
> signatures, it must sign the message (and expect a signed response), 
> whereas if the target is open-access, the message exchange goes vanilla. 
> If I sign my messages to 'vanilla' targets they reject my request (not 
> understanding my "MustUnderstand" -  even if they do somehow fail to 
> notice this problem, I reject their responses as they don't have a 
> required security header).
> I've been using WSS4J to handle signing, configured via the 
> client-config.wsdd file.
> I'd rather manage this in the configuration properties than coding it 
> into the client. But if the only answer is to make my classes smart 
> enough to programmatically sort out WSS4J, then so be it...
> - Scott
> On 25 Mar 2005, at 04:00, Elaine Nance wrote:
>> Dan,
>> Here are also simple questions, not particularly aimed at you:
>> Why would your service be responsible for what the subscriber does to 
>> handle the responses?  If the interface is fully specified by the wsdl 
>> then the client will be able to consume it.
>> What, specifically, are you doing that you need to concern yourself 
>> with client-side handlers?
>> I'm not being a smartie here.  I see a lot of posts similar to yours 
>> and I wonder why:
>>   1) the provider wants to be responsible for the subscriber - frankly 
>> I'd love it if our enterprise IT even *thought* about providing usable 
>> client code.  I will absolutely settle for a wsdl which doesn't make 
>> me hand-code parsers for every string-wrapped xml document.
>>   2) so many services don't seem to be designed as services - it's as 
>> if the cart is driving the horse, as in "we already have the 
>> application/interfaces/classes that we'd like to expose as a web 
>> service" . . .
>>   3) SOAP is decided as the solution when the problem hasn't been 
>> analyzed
>> Elaine
>> Dan O'Neill wrote:
>>> I'm tired trying to get them to work. Do Client-side service-specific
>>> handlers work? If you put them in client-config.wsdd? I know that if I
>>> change them to global they work?
>>> I've got some working by using setClientHandlers() in the client code
>>> but I don't always have the luxury of changing people's java client?
>> <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>  |  Computers are useless. They can only give you answers.
>>  |                                 --  Pablo Picasso  --
>> <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  |  Computers are useless. They can only give you answers.
  |                                 --  Pablo Picasso  --

View raw message