[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tamie] Event Board
Cho and all:
We will put this on the agenda for this Tuesday Feb 3rd
meeting.
Some comments:
1- I have the feeling that one type of EB over these 3
types (PEB, MEB, TEB) might be superfluous... in particular: can't we consider
PEB and MEB the same?
Or is the "MEB" acting only as an event input (fed by the
event adapters) and PEB as only for outputs from scripts, like test
results, etc.?
2- could we make a list of various kinds of events we need
to manage so that we better understand the requirements
we must address?
(e1). External events that contain business data,
e.g. Purchase Order, and that needs to be processed usually within
"conversations". e.g. all events relating to the same
POref#.
(e2). Internal events generated by test scripts just for
the sake of synchronization across "scriplets" (or "testflows"). Need to be
discarded at the end of a test case execution
(e3). Internal Events that capture the result of test case exec. Need to
persist beyond test case execution time.
(e4). External events that represent some status
notification about business environment, e.g. a server is down: need be shared
by all test case scripts.
(e5). Etc...
3- Could there be some E.Boards that do not fall into these
categories: PEB, MEB, TEB ?
An event Board is I believe similar to Event Stream (see
EPTS glossary). That suggests that the flow of incoming events as converted by
the Event Adapter, could be split into several smaller event streams (like evt
queues or topics), each one of these event streams (i.e. smaller Event Board)
being consumed by a different test case instance, e.g. event stream for a single
Purchase Order. Such an EB is not necessarily "temporary"... could be just a
subset of a larger persistent Event Board, like a "view" on a common EB. So
isn't such an EB outside any of these categories: PEB, MEB, TEB
?
And happy lunar year too (and here is a question from an
ignorant: how many of these lunar years in a "solar" year ???
:-)
-Jacques
From: Hyunbo Cho [mailto:hcho@postech.ac.kr] Sent: Monday, January 26, 2009 7:02 AM To: tamie@lists.oasis-open.org Cc: 'Jungyub Woo'; 'gazuo' Subject: [tamie] 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]