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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx-implement message

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


Subject: AW: [ws-rx-implement] interop & InOrder


Hi Doug,
yes I think we also should test exactly-once DA.

We currently think about the topic how the provider can recognize that
a message received is an exactly-once (EO) or an exactly-once-in-order
(EOIO)
message for reasons of optimization.

Also we have worry about performance issues when using a separate
sequence
for each EO message. 

So in my opinion we need a way, of sending many EO messages usinge ONE
sequence
or a special support for EO messages sent by WS-RM.

What are possible ways for doing this?

1) Using lastMessageFlag which exists in WS-RM 2005 spec.
   disadvantages:
    This flag has not to be pinned to the last and only business message
    but also can be sent as stand-alone message. So the provider
    always has to wait until the second message was received for
deciding whether
    EO or EOIO DA is present.
   
    But if one think about a mediated messaging hub which receives
incoming
    sequences and maps the corresponding messages to n outgoing
sequences
    (because of late content based routing), the lastMessageFlag must be
possible
    to sent the lastMessageFlag as stand-alone message.

    The flag was removed in current version of WS-RX.

    So the lastMessageFlag is not really suitable for deciding which DA
is present.

- We have a DA configuration on provider side on design-time level.
  The designer of an interface can decide if in-order contract should be
fulfilled
  by RM Layer or by application (from RM Layer point of view, the first
case
  is DA = EOIO and the second case DA = EO). The contract on consumer
side is: all
  message sent to one logical sequence (a layer above WS-RM) will be
delivered in-order.
  If the application creates EO messages, they can be bundled in one
sequence in messaging
  layer but configuration is needed for indicating DA = EO on provider
side.
  If we are using design-time configuration (I think this would be
necessary, because
  the application has to know if it is reponsible for fulfilling the
contract of
  in-order processing), one interface could only either be used for EO
or for EOIO DA
  (DA definition from WS-RM point of view).
  Also it is a little bit strange to assigning a DA "in-order" to an
interface. What is the
  semantic? Should this only relate to the chronological order of
operation calls of one
  interface? Or can operation calls of different interfaces handled in
one sequence?
  But then we would need a higher level entity (e.g. a scenario) for
defining in-order
  relations.
- Should WS-RM offer special support for EO messages? Or should EO
messages be only
  a specialization of EOIO messages? Think about performance issues
(overhead of
  sequence creation/closing).

In our current non WS-RM based implementation we are transmitting a QoS
(=DA) property in
a SOAP header for telling the provider side which DA must be applied. So
the DA is only
driven by the way the calls on consumer side are done.

(In the current WS-RX discussions the DA will no longer be transmitted).

What's your opinion concerning these topics?

How do you handling EO messages? Separate sequence per message, 
or one sequence for many EO messages? DA configuration on provider?
DA configuration side on interface level?

Kind regards,
Stefan


________________________________

	Von: Doug Davis [mailto:dug@us.ibm.com] 
	Gesendet: Dienstag, 21. Februar 2006 16:28
	An: ws-rx-implement@lists.oasis-open.org
	Betreff: [ws-rx-implement] interop & InOrder
	
	

	In the past when we did RM interops we only tested InOrder DA -
right now the interop doc is silent on this.  I've been assuming we'd be
doing InOrder again this time but I wanted to know what other people's
assumptions were.  If people agree we should add that to the doc - and
if we do then we can change the <LastMessage> element to be a simple
boolean-type of flag (e.g.  <LastMessage/>) instead of including the
last msg # in it.   
	
	thanks, 
	-Doug 
	



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