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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ebxml-iic] edits for GetMessage() op



>             Durand: Some proposed additions in the section below (in
>             bold). Please update if not correct.
>             Should the Filter of a GetMessage() op produce a "Result"
>             element containing the resulting node-set?
>
>             Jacques
>
>             * Semantics of the GetMessage operation *
>
>             A fundamental * aspect * of the GetMessage operation is *
>             its behavior and effect * over the Message Store. 
>             The Message Store is an XML document object that contains
>             an XML representation of all synchronous and
>             asynchronously received ebXML messages for a Test Case.
>             The received messages for a particular Test Case MUST *
>             persist * in the Message Store  for the life of the Test
>             Case. Messages in the Message Store MAY contain all MIME,
>             SOAP and ebXML or other types of message content,
>             represented as an XML document.  The particular XML
>             representation of a message in the Message Store is based
>             upon an  a "best practice" schema for representing a
>             particular message type.  If the messages being stored are
>             ebXML messages using HTTP transport and a SOAP envelope,
>             the XML format of the Message Store document MUST validate
>             against the ebXMLMessageStore.xsd schema in appendix D.
>
>             The GetMessage Filter sub-operation queries the Message
>             Store document object, and retrieves (by default) the XML
>             content that satisfies the XPath expression specified in *
>             its * Filter child element.  * As the MessageStore is
>             updated every time a new message comes in, a GetMessage()
>             operation will automatically execute as often as needed,
>             until either (1) its Filter selects and returns a
>             non-empty node-set, or (2) the timeout (stepDuration)
>             expires. *
>
>             [MIKE] - suggest adding:
>
>              A TestPreCondition and/orTestAssertion sub-operation (
>             which also contain a single XPath query) query the
>             resulting document object constructed from the node-list
>             generated by a GetMessage Filter operation. That document
>             object to be examined by a TestPreCondition of
>             TestAssertion action MUST have a root element with a name
>             of test:Result ( as defined in the Result schema in
>             Appendix XX).   If the Test Driver is unable to create
>             a Result document object because the resulting node-list
>             contains any XML content other than elements ( such as an
>             attribute list), then the Test Driver MUST generate an
>             exception, and terminate the Test Case with a result of
>             "undetermined".  (i.e. if the XPath query does not
>             return XML content that can be built into a document
>             object, then it cannot be further examined with XPath in
>             the TestPreCondition or TestAssertion operations)
>              
>             [Jacques Durand] sounds good. I think we can even be more
>             specific: the Filter is supposed to apply to Message
>             elements always, and return such a set.
>
mm1: Would there ever be a condition where we query for a Test Result 
expecting that there would not be one?

>             * NOTES: *
>
>                   *        All the message items available for
>                   querying, are children of the MessageStore element.
>                   The Xpath expression in the Filter will typically
>                   select all the /MessageStore/Message elements that
>                   satisfy the filter, and these will be consolidated
>                   as children of a Result element, available for
>                   further querying, e.g. by the TestAssertion operation. *
>
>                   *        * *The messages that have been selected by
>                   a GetMessage() operation are (suggest remove the
>                   word 'normally'.. sounds ambiguous)
>                   * [Jacques Durand] fine.
>
>                    *"invisible" to future Getmessage() operations in
>                   the same test case, unless the "mask" attribute is
>                   set to "false" (default is "true"). A GetMessage()
>                   operation will execute over all messages in the
>                   message store for this test case, except those
>                   messages that have been masked by a previous
>                   GetMessage() operation.  * [MIKE] - My
>                   interpretation of what you are saying here ( and
>                   what will be necessary to implement) is that there
>                   will have to be 2 MessageStores ( this would seem
>                   the only efficient way to make this transparent to
>                   the test writer ).  If I do a <GetMessage
>                   mask="true"> ( the default ) then any messages that
>                   contain a node in the returned nodelist are "moved"
>                   to the "masked" MessageStore after the <GetMessage>
>                   operation.  
>                    
>                   [Jacques Durand] The way I see it, we don't need two
>                   message stores: we still always work with the
>                   original message store. Only, I make the following
>                   implementation assumptions: (1) in the message
>                   store, each message is numbered when added (e.g.
>                   M001, M002, M003 etc.) i.e. we add an identifier
>                   just for the sake of the message store (there is
>                   already an Id in the schema, but we are talking here
>                   of something different than the Id in the message
>                   header, probably would need to add that to the store
>                   schema?). (2)  When a Getmessage() is masking a
>                   message, it just adds its store identifier in a list
>                   of "masked messages" for this test case./ (3) When a
>                   GetMessage() executes, it selects messages that
>                   satisfy its Filter AND the identifier of which are
>                   not in the masked list./
>
mm1: Where are these concatenated type identifiers held (message stored 
identifier and identifier associated with the local one for that 
GetMessage)? Is it available in a 'local' store understood by that 
GetMessage() instance?  I think the only hesitation I have is the 
multiple hits to the message store by multiple test cases and ensuring 
deadlock conditions or other unforeseen events do not occur.

>                   / /
>
>                   [MIKE2] - Here is perhaps where the problem is. 
>                   XPath processors only perform what is stated in the
>                   query.  In order to "add" this to a test writer's
>                   XPath query (which can be expressed in a virtually
>                   infiniate number of ways) and still make it
>                   "transparent" to the test writer... the Test Driver
>                   must either:
>
>                   a)Automatically modify the query to include checking
>                   the <Message> element's "masked" attribute for value
>                   of true/false.. (scary since the same XPath query
>                   can be expressed in a virtually infinite number  of
>                   ways.. and parsing and substituting query text 
>                   would be very difficult)
>
>                   b) Have the test writer explicitly write their XPath
>                   query (like below) to include a
>                   @masked="true/false" since there is only one
>                   MessageStore, containing both masked and unmasked
>                   messages, and the XPath processor must be able to
>                   differentiate the two types
>
>                    /MessageStore[Message
>                   @masked="true"//eb:MessageHeader/eb:MessageData[eb:ConversationId='123']]
>
>
>                   c) Have the default be that all incoming messages
>                   that match a particular <Filter> operation are
>                   actually "removed" from the MessageStore ( that is
>                   the only way to transparently "mask" them for a test
>                   writer...and  an XPath processor)  This makes it
>                   transparent to the test writer, and if they want to
>                   "save" messages that they've <Filter>ed, the must
>                   specifically do a <GetMessage mask="false"/> to save
>                   them for subsequent queries..
>
>                   The one thing that a test writer would have to be
>                   aware of  ( if they wish to examine message content
>                   in a subsequent <TestStep> or <Thread> ) is that
>                   they need to explicitly set mask="false"
>
>                   This can be easily  done using XSLT (XSLT processors
>                   can take several input docs: the store, and the
>                   masked list.)
>
>                   [MIKE2] - I agree that an XSLT processor could
>                   easily modify an incoming message to add a "masked"
>                   attribute.  It's the modification of the incoming
>                   XPath query that is very problematic.  I'd opt to
>                   "remove" masked messages from the MessageStore.. and
>                   keep life simple for XPath query writers.. and the
>                   Test Driver...
>
>                    This is a bit tricky ( will require the Test Driver
>                   to traverse "back up" the document tree to the root
>                   <MessageStore> element, and copy the <Message>(s)
>                   that contain the matching node-set node(s) and
>                   delete them from the "unmasked" MessageStore. and
>                   add them to the "masked" MessageStore.  This will be
>                   a bit time-consuming for the Test Driver ( unless
>                   the default is mask="false".. a more likely scenario
>                   in testing I think ).   Also.. there is the issue of
>                   "side-effects".   Since the MessageStore is a
>                   "global" data resource, available to
>                   any concurrently running Thread... "masking" (i.e.
>                   deleting) messages that may be needed by a
>                   concurrently running GetMessage operation would
>                   introduce problems unless the test writer is aware
>                   of them. 
>                   [Jacques Durand] Well, masking / unmasking is the
>                   choice of the test writer. But "side effect" is a
>                   relative concept: Thread A consuming a coming
>                   message that was intended for itself, and leaving it
>                   in the store, will be a serious side effect for
>                   Thread B which will see it...
>
>                   [MIKE2] - Agreed.  Then I would recommend a
>                   "removal" type masking as the easiest way to keep
>                   scripting simple, and make the default
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]