Scott,
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.
Elaine
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 -- <~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
