More on the DEBS use case tutorial

I am now in my hotel room in Tarrytown, NY; one of the nearby towns is known as "Village of Sleepy Hollow", I always wondered about the origin of this name, and who wants to say -- I live in sleepy hollow.. I have seen some other strange name. For example, there is a USA small town called - "bird in hand".

I have noticed that Pedro Bizarro has posted the DEBS use case tutorial provided by the EPTS use case work groups on slideshare in form of 7 presentations. Enjoy!

It is interesting to note the "lessons learned" presentation, it summarizing ten lessons.

• Architecture
  • Lesson 1: State-based event processing
    
  • Lesson 2: Incident objects
  • Lesson 3: Integration with other data management systems
  • Lesson 4: System of systems
• Languages
  
  • Lesson 5: Query languages
  • Lesson 6: Classification and rules groups
  • Lesson 7: Customization
• Glossary
  • Lesson 8: Changes to glossary
• Use Cases
  • Lesson 9: Changes to questionnaire
  Lesson 10: Better instructions to describe a use case
  

I agree with the state-based lesson; I am advocating the notion of context which can include various types of state and segmentation, and I view it as a first class citizen in the model. This is both architecture and language issue.


What they call "incident object" seems to be an object that describes derived event that has some internal structure which can be updated by programs. This seems to be quite trivial notion that events need to have some structure, and be able to participate in processing other events, may be retained over time; I think that this is true for any event, as event may also mean "event object". About the question whether it can be updated by programs, this is a matter of taste, since they want to keep these objects in temporal databases, temporal databases has adopted an "append only" model, where changes create other objects, and there is some reasoning behind it. I may dedicate a postings to this topic.

Integration with other data management systems -- given that Dieter Gawlick is co-leading this workgroup, one can expect that there is a database-centric view of event processing, his views on this topics are well known. I agree that databases can be integrated with event processing systems for various reasons (state keeping, reference, meta-data holding, high availability...), but event processing may also be integrated with a messaging system, with business process management system, with a BAM system, and with sensor networks, so I would extend it to integration with other parts of the enterprise architecture.

System of systems has to do with modularization and some implementation issue (e.g. bounds of local and global states). In my view EPN can be defined recursively such that an EPA can represent an EPN, thus we can express "system of systems". I am not sure that this requires any conceptual difference.

Query languages -- I am not sure I got the exact point here, but it seems that all event processing styles require to express conditions such as predicates for various uses. I think this is already happening. The issue whether internal state can be queried is different, and not relate to the language issue.

Classification / customization-- This is again one of the context dimensions, as context can classify populations according to classification predicates. Languages that are more syntactic oriented like the SQL derivatives hide classification inside SQL Where, but where context is supported as a primitive concept then classification is an explicit construct; this also allows customization. The use of vocabulary, as been used in rule languages, can be helpful here.

Glossary -- I'll leave the glossary discussion to the glossary workgroup for a while.

Use cases description --- the goal of this entire exercise was to "debug" the use cases template; I hope that the use case workgroup will finalize the template soon, and move to the next phase -- getting a substantial number of using cases and draw conclusions about their types, requirements etc--- it will be a great help to the community if we'll succeed to classify the applications to a finite, small, number of classes, where in each of them we'll be able to specify important functional and non-functional requirements. More on this -later.