[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tamie] Event Board
|
Jacques, See [inline]. -Cho From: Durand, Jacques R.
[mailto:JDurand@us.fujitsu.com] 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.? [Our
original idea: All the events can be stored at MEB no matter they come from. The
test user can then play with MEB. The test user can catch and process the needed
events from MEB, catch and store to PEB the to-be-used events from MEB. Whether
TEB is created for convenience purpose is up to the test user.] 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... [This
is a good idea for the test user to be aware of kinds (types) of events. I will
continue to work on this. But I still think that the Event Adaptor feeds events
to the MEB. The users has to determine which events are stored, deleted, or
viewed. Let’s continue to talk.] 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 ? [I
guess that you say two things here: the role of Event Adaptor and permanent
storage of events for late use. Our original idea: the same answer as above.
The Event Adaptor feeds Events to the MEB. If the test user want to use a
particular subset of events for other test case instances, he or she needs to catch
and store them.] And happy lunar year too (and here
is a question from an ignorant: how many of these lunar years in a
"solar" year ??? :-) [Good
question! The lunar calendar has also January to December, which lags about 30
to 40 days behind the solar calendar. So we have only one new year for lunar
calendar. The good thing is that we have two holidays: solar new year and lunar
new year, and a couple of days before and after.] -Jacques From: Hyunbo Cho [mailto:hcho@postech.ac.kr]
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]