tamie message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: About event management
- From: "Durand, Jacques R." <JDurand@us.fujitsu.com>
- To: <tamie@lists.oasis-open.org>
- Date: Thu, 22 Jan 2009 12:25:24 -0800
Here is some input
from an off-line investigation from Dr. Cho, Dr. Woo and myself, about
events:
(some other options
have not been describd here)
1. Event Boards
management:
- For efficiency
reason, test scripts will need to deal with "small" event boards (or "Event
Streams" per the EPTS terminology). 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 #.
- Input events may
need to be automatically partitioned in such smaller Event Boards (or EB). The
way EBs are implemented is abstracted: they could all be in the same event
store, represented by a proper index (e.g. database index), or could be in
separate event stores. The definition, creation and management of EBs is under
control of the Event Manager (EM).
- A test script must
know about EBs, can declare and create some, or reference existing ones managed
by the EM. Some EBs are "read only", some others are "read-write".
- Event Adapters are
mediating 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).
- an Event Adapter
is not concerned with specific Event Boards. It is associated with an Event
Manager and sends events to it. the EM is in charge of assigning the event to
the right Event Board(s). Several Adapters can feed the same
EM.
- 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 (adaptA and adaptB). In a fully separated event processing, these
adapters will feed events to different EM instances (EM-A and EM-B) that will
create and manage two sets of EBs, which wil in turn be consumed by separate
eTSM engines.
- 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.
2. "Script
Container" design:
See last
section:
Top-Level Script Containers (to
investigate)
We attempt to define a structure that will provide some
contextual info useful for overal test case
execution.
This structure would contain also definition of Event types in
use.
It may contain config info for for Event Adapters - i.e.
contextual info that is assumed to be known from the Test environment, in order
to run the test scripts.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]