• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
  • Bear Bibeault
  • Jeanne Boyarsky
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • salvin francis
  • Stephan van Hulst
  • Frits Walraven
  • Carey Brown
  • Jj Roberts

Design Question for XML request/response documents

Ranch Hand
Posts: 165
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We're currently having an internal debate at my company concerning how to handle requests and responses for services. One of the opinions is that we can send out a "standard" document, which transfers needed data in the standard document required for processing, and the process runs, then populating the some attributes following processing. All of the attributes are populated after the service runs through the document For example:
<service id="performTransfer" requestId="120003">
<stockTransfer flag="" valid="" invalid="" errorText="">AGC</stockTransfer>
<numberofshares flag="" valid="" invalid="" errorText="">100</numberofshares>
<ordertotal flag="" valid="" invalid="" errorText="">1000000<ordertotal>
<option name="debitAccount" success=""/>
<option name="sendEmail" success=""/>
<service id="performTransfer" requestId="120003">
<stockTransfer flag="Y" valid="Y" >AGC</stockTransfer>
<numberofshares flag="Y" invalid="N" errorText="Number of shares exceeds limit">100</numberofshares>
<ordertotal flag="Y" valid="Y">1000000<ordertotal>
<option name="debitAccount" success="N"/>
<option name="sendEmail" success="Y"/>

The other opinion is that we have separate request and response documents. The request provides data needed for processing it. The response sends back the status of the items and the results of processing.
<serviceRequest id="performTransfer" requestId="120003">
<option name="debitAccount"/>
<option name="sendEmail"/>
<serviceResponse id="performTransfer" requestId="120003">
<stockTransfer flag="Y" valid="Y" >AGC</stockTransfer>
<numberofshares flag="Y" invalid="Y" errorText="Number of shares exceeds allowable number">100</numberofshares>
<ordertotal flag="Y" valid="Y" >1000000<ordertotal>
<option name="debitAccount" success="/>
<option name="sendEmail"/>

Seems to me like the intent of the messages is clearer with option #2- but maybe i'm being too strict on this. I suppose that you could infer the intent of the message by looking to see if the valid/invalid flags are set. Let me know any thoughts.........
Posts: 11962
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's another option: Encapsulate request/response-specific container elements with a top-level, standard envelope element.
This allows implementing certain "aspects" like interface versioning and yet retains the transparency of intent for each message.
permaculture is largely about replacing oil with people. And one tiny ad:
the value of filler advertising in 2020
    Bookmark Topic Watch Topic
  • New Topic