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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tamie message

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


Subject: next TaMIE call


I will schedule next TaMIE call for the following date as it appears to suit most people:
 

(a) Thursday Aug 21st, 4pm PT

Let me know if any hard conflict.

 

I am still wrapping-up the minutes of F2F. Below is a very partial start for your review. More complete minutes to be posted end of week.

Event Description:

------------------

TaMIE F2F , July 2008
http://www.oasis-open.org/apps/org/workgroup/tamie/
Date:
Thursday-Friday July-24-25, 2008
Host: Fujitsu
US Toll Free: 877-995-3314
US Toll/International: 210-339-1806
Passcode: 9589308
 
Attendees:
----------
 
- Dale Moberg (Axway)
- Chuck Morris (Northrop Grumman / CGI)
- Jacques Durand (Fujitsu)
- Hyunbo Cho (Pohang Univ., Korea)
- Dong-Hoon Lim (KIEC)
- Mohammad Abidi (AIAG)
Dial-in:
- Stephen Green (SystML)
- Nenad Ivezic (NIST)
 
 
 
Action Items:
-------------
 
Minutes:
-------
 
------------------------------------------------------------------------
Thursday 7/24, AM (9:15am - 12:30pm)
------------------------------------------------------------------------
1. Kick-off & administration matters:
- Get last minute "wish list items" from participants.
- adjustments to agenda.
- feedback on relevant patents.
 
- agreed to swap agenda items, e.g. Event model to be looked again later in the day
when KIEC have access to their server to show their model.
- Jacques: a short list of patents on testing methodology and tools have been
communicated to me. Having some past experience with patent, so far I do not eTSM
infringing the essential claims of these. We mostly improve on known technologies
though the combination of event-driven technology and testing, can be considered as new.
- list of patents:
- 6662217, December 2003, Godfrey et al.
http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1
&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&d=PALL
&RefSrch=yes&Query=PN%2F6662217
- 6681383, January 2004, Pastor et al.
- 6697967, February 2004, Robertson
- 6766477, July 2004, Grucci et al.
- 7123014, June 2007, Drummond
 
2. (Req 02) Review of "Canonical" Use Cases for Business Transactions
- UN/CEFACT Bus. Tx. Patterns
- selecting a typical set of basic B2B patterns in OAGI, AIAG, RosettaNet, UMM.
- what is to be monitored/tested.
 
- We review the work done by UN/CEFACT (UMM) on categorizing business transaction patterns.
Clearly, messages are events.
- main areas subject to monitoring:
o the exchange pattern itself (could be abstracted using LTS). Includes error messages.
o global variables: timing, or any other aggregated value generated from several messages.
o use of underlying protocol (HTTP req-response, SOAP / REST binding, etc)
o conformance to contract (i.e. to some metadata doc, e.g. CPPA, WSDL, WS-Policy...)
assuming the metadata doc is itself cast as an event.
- all 6 bus. tx. patterns appear to pose no special challenge.
- Jacques: the value of an integrated monitoring is that there might be dependencies
between these aspects: a PO for a particular product or from some particular user
may require a level of QoS not needed by another product, and this for the same type of
bus Tx.
- Stephen: the "signals" in a business transaction could use a different channel,
and need be checked for well-formedness. E.g. in ebXML ebBP.
- Mohammad: AIAG exchanges mostly conform to OAGI definitions: BODs are based on
verbs and nouns. E.g. A noune (e.g. PO) is subject to several ops: request, change, cancel...
E.g. "get" and "show" are typical.
- At higher level beyond atomic bus transactions? Full collaborations, like in ebBP, or as
driven by WS-BPEL. Agreement that they too will need monitoring. Mostly resulting in
a chain of events likely to comply to an LTS state machine.
 
3. The Event model:
- Review of the WS-I "XML container" for MIME / SOAP messages (Jacques).
- when events = metadata document.
- header elements for the Event XML wrapper.
- assumed event board implementations (from flat file to XML DB)
- Data hiding in eventBoard (Req 014, and beyond)
- Security aspects and requirements.
 
- Where we are today: an event model that defines roughly 3 parts:
- (a) A short list of predefined event attributes. To be finalized.
These can be split in two: (a1) attribute with values that are automatically generated by
the Event Board, like the event ID and posting timestamp, (a2) attributes that
come from the event content (or from the "posting operation") like event type.
The event type attribute in eTSL: some types are predefined for evts that are generated
by the test case execution. Other type values would result from some profiling of
the event header when matched to a specific external event, e.g. a RosettaNet PO message
may use the PIP name or the message Action name. The evt type of an ebXML message may
be concatenation Service+Action. But that is not for TaMIE to decide.
- (b) A list of configurable name+value pairs ("event properties"). These result from
the profiling of events used in a particular context. To be set by the posting operation.
The only restriction (to be finalized by TaMIE) is that all events of a same type,
must use same list of names in their properties. Could some property values be
of complex type? e.g. XML complex element? Yes.
- (c) An unstructured part, the "content". Expected to be an XML doc. Could have
external references to other docs (e.g. MIME attachments).
- about Event ID: generated by Event Board at posting time. There are advantages
at this ID to express a total order on the event board, e.g. a sequence number.
Will make processing easier. Has some equivalent in databases.
- The posting timestamp is different from the "originating timestamp" usually set
by the originator (e.g. message sender). We cannot expect it to be unique, due to
high volume of evt posting and time granularity not fine enough.
 
 
 


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