[
Lists Home |
Date Index |
Thread Index
]
Dennis Sosnoski wrote:
> Ian Graham wrote:
>
>> Yes, We're aiming for WS-I compliance, so this is consistent with what
>> we were thinking. And we consciously want to avoid multiparts, for
>> the reasons you outlined (below, but chopped).
>>
>> But I can't find any examples of current practice -- what works well,
>> what doesn't, etc. Would've thought this would be a common pattern,
>> somehow ...
>>
>> As per Joseph's thought, I looked at ws-dev
>> (http://aspn.activestate.com/ASPN/Mail/Browse/Threaded/ws-dev), but it
>> seems that list died off about 2 years ago ... Is it revived somewhere
>> else?
>>
>>
>>
> I don't know of much out there that actually talks about these types of
> issues. The whole topic of header usage is still pretty much up in the
> air, though with OASIS formalizing a version of WS-Security this should
> help establish usage patterns.
Thanks -- at least I now know I didn't simply miss the obvious.
> Your particular requirement, to enable debug information in the request
> and have it returned in the response, is somewhat unusual in that most
> applications would not want to expose any type of internal information
> to clients. I can see where it would make sense for some environments,
> though, especially when there may be external dependencies that need to
> be tracked during the processing of requests. All I can suggest is that
> you look at the types of information you want to include and define an
> XML format to match. You might also want to try your questions about
> best practices on a mailing list for the particular framework you expect
> to be using for your services, since header processing techniques will
> differ from one framework to another.
The goal is to allow for optional debugging information -- turn it on
when wanted (in development or when encountering a weird problem in
production), but otherwise leave it off. We have found, for example,
that its hard to diagnose an application problem when you're hooking up
4+ new applications (client, web services mid-tier, 2+ backend
applications) begin tested end to end. Thus the idea of having the WS
message - when appropriate -- gather up all the debug data from all the
layers and return it to the client, where it can be saved/viewed/analyzed.
Best --
--
Ian Graham
H: 416.769.2422 / W: 416.513.5656 / E: <ian.graham@utoronto.ca>
|
