[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tamie] uc3 two areas of updates this week
1. The addition of structure you propose
should be easy enough. I will do that today sometime. 2. Message correlation info is another
story. ebBP is at an abstraction level that does not represent specifics about
messaging protocols (only QOS requirements (or intents, as the SCA folks call
them)). So correlation info provided by lower
layers is not present. In ebMS 2 or 3, we could use the ConversationID value to
correlate across an instance of a concurrent run. Other WS implementations
might adopt a bilateral convention about some information carried in
WS-Addressing headers. RosettaNet headers are another place for that
information. And so forth. So ebBP only gives pattern level information and
requirements. (If we had the CPPA that references the
ebBP, then we might be able to supply the lower layer information.) If signals are used, I can look to see
whether that information is present. And the referenced Document/Specifications
might have transaction/session information that they carry. Unfortunately, process instance information
is something done differently across Data Exchange approaches, and even at
different (and sometimes redundant!) layers. From: Jacques R.
Durand [mailto:JDurand@us.fujitsu.com] Dale: Could we add a bit more [xml] structure to
the edge information: rewrite:
<Label2XPath>Accept,/OrderResponseSimple[AcceptedIndicator='true']</Label2XPath> as:
<Label2XPath
label="Accept">/OrderResponseSimple[AcceptedIndicator='true']</Label2XPath> Also, I believe we need somehow to add
some message correlation info to this graph, so that we know which message the
XPath condition/expression associated with each edge will apply to (because
there could be many concurrent such transactions intertwined, while each single
path across the LTS must select only related messages) -jacques From: 1. LTS diagram: added loop indication, TTP (time to perform)
failure edge, still experimenting with logically complex labels. Conjunctions
are marked explicitly and to avoid multi edge graphs (multiple edges between
two nodes), a disjunction is implicit currently. A “true”
label here is just an automatic “internal” transition, and if it is
in a conjunct, it can be ignored. (p and true) equals p. 2. Another addition to uc3 is adding to Jacques enhanced LTS
xml There are now mappings of the document labels to XPaths for
use in the conversion to scripts. I have not yet tried to produce the XML
format of the original prototype. Instead the following is output at the
moment. A list of Nodes Mixed List of Labels And of Edges Then the following
<Label2XPath>PurchaseOrderRequest,/Order</Label2XPath>
<Label2XPath>Accept,/OrderResponseSimple[AcceptedIndicator='true']</Label2XPath>
<Label2XPath>AddDetailResponse,/OrderResponse</Label2XPath>
<Label2XPath>Reject,/OrderResponseSimple[AcceptedIndicator='false']</Label2XPath>
<Label2XPath>PurchaseOrderCancellation,/OrderCancellation</Label2XPath> So, I have just produced xml container elements that contain
“rewrite rules” for the DocumentEnvelopeLanguage (the ebBP term for
a LTS action/label/channel), to XPath. Putting in namespace prefixes would be next. And if it is
useful, I could output, prefix to namespace rules/maps in other containers. I
would like to avoid tinkering with prefix redeclarations and scope, but it
seems to me that whoever writes the XPath could simplify out those complexities
when they stick the prefixes on the elements. I will check out some methods for
various profiles of ebBP usage that will output the prefix to namespace rules
eventually. The ConditionGuardLanguage mappings are also underway.
Several of the possible maps exploit signal message XPaths. When signals are
not used, I am uncertain that there will be an XPath on a message. (The events
might only be written to log files of the MSH on either or both ends. I think
this would have to be information obtained from other sources than the ebBP
because it involves some “private process/orchestration” side
information. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]