[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Event Board
Happy
new lunar year! Here
is modified description (requirements) on Event Board Management that Jacques
emailed on 1/22/2009. Again discussion has been made with Dr. Jungyub Woo at
NIST and Mr. Yunsoo Lee at Torpedo. -Cho --------------------------- 1.
Functionality of Event Adaptor (EA) -
to send Events out to the external entities (for the request of Monitor) -
to receive Events from the external entities -
to mediate external events into
Events that have proper structure for eTSM processing. E.g. they transform B2B
messages into eTSM xml Events. They are acting as Event Sources (per the EPTS
terminology). -
to post Events to Main Event Board (MEV) Note
1) Since EA does not post outgoing Events, Monitor should do so if necessary. Note
2) If
there is a need to separate event flows based on their source and not based on
their content (e.g. different companies testing their own B2B platform which
generate similar events) , then Company A and B will send their events to
different event adapters (EA-A
and EA-B). In a fully
separated event processing, these adapters will feed events to two different EBs, which
will in turn be consumed
by separate eTSM engines. 2.
Functionality of Evaluation Adaptor (EVA) -
to call external evaluation engines and return the outcomes to Monitor Note
1) since EVA does not post evaluation outcomes, Monitor should do so if necessary 3. Event Boards
management: -
Event Board consists of Main Event Board (MEB), Temporary Event Board (TEB),
and Permanent Event Board (PEB). -
A test
script must know about EBs, can declare and create some, or reference existing PEBs. MEB and TEB may be
deleted after the execution of the associated Test Case is stopped. However PEB
is stored which can be used for the purpose of deferred test. Note
1) we can assume that EV management can be done within a test script except for
deletion of PEV. PEV can exist permanently unless requested by the test user. -
Monitor can read and write all Event Boards. -
Event Adaptor can post the incoming events to only Main Event Board. Monitor
can also post Events to only Main Event Board. Therefore all the Events could be in the MEB, represented by a
proper index (e.g. database index). -
TEB can be used for efficiency
reason. Test scripts will need
to deal with "small" event boards (or "Event Streams" per
the EPTS terminology). In
this case, a subset of Events can be separate from MEV and stored to TEB. For example, there
could be an event board for each PurchaseOrder event, collecting all events
related to this PO - i.e. sharing the same POref #. -
a Test script should be able to work on different EBs in a generic way. E.g. a
Test Case verifying that PO exchanges are conform to spec, must be able to work
on a different EB at each invocation (e.g. depending on the PO ref #). The
CATCH operator must be designed so that it can reference an EB in a
parametrized way. For example, all EBs that collect events related to the same
PO ref #, wil have an identifier of the form "POtrack:ref123" where
the first part "POtrack" is a class of EBs (here the class of all EBs
that track PO-related events), and second part "ref123" is a
particular PO ref #. The Test script that verifies a single PO exchange will
have a CATCH statement of the form: <catch ebclass="POtrack",
ebinst="myPO/@ref">, or something equivalent. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]