Win a copy of Java Concurrency Live Lessons this week in the Threads forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Design Question for XML request/response documents  RSS feed

 
Matthew X. Brown
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:
Request:
<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>
<optionalProcessing>
<option name="debitAccount" success=""/>
<option name="sendEmail" success=""/>
</service>
Response:
<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>
<optionalProcessing>
<option name="debitAccount" success="N"/>
<option name="sendEmail" success="Y"/>
</service>

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">
<stockTransfer>AGC</stockTransfer>
<numberofshares>100</numberofshares>
<ordertotal>1000000<ordertotal>
<optionalProcessing>
<option name="debitAccount"/>
<option name="sendEmail"/>
</serviceRequest>
<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>
<optionalProcessing>
<option name="debitAccount" success="/>
<option name="sendEmail"/>
</serviceResponse>

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.........
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • 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.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!