OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] [off-topic] Web services best practice information?

[ 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>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS