• Canoe 2009 Interoperability

How should standardization efforts proceed?

NOTE: The reader is strongly encouraged to modify/add to the notes below for the benefit of all.

Participants:

• Andre Dietrich
• Björn Schilling
• Naweed Tajuddin
• Tomasz Wiktor Wlodarczyk

NOTE: Slides are attached.

Guiding Questions

Here are some questions to get you started, but feel free to define your own.

• What parts of the system should be subjected to standardization?
  • Data formats, APIs, programming models?
• What should not be standardized?
  • What concepts are most in flux, application dependent, etc.
• What standards exist today in this space?
• What are their limitations?
• What standards should exist?

Summary of breakout session discussion

Please summarize the points from the break out sessions here.

What parts of the system should be subjected to standardization? What should not be standardized? What standards should exist?

• Languages likely should not be standardized, due to varying degrees of expressiveness required for different applications. A generic and flexible language may be difficult and cumbersome to use, whereas simplified languages may be insufficient for some applications (i.e. what to do if a specific operator is not available?). On the other hand, SQL is more or less the same across the various database platforms. The key behind SQL, however, is that it is based on a mathematical foundation; namely relational algebra. Until such a formalism is found for EP, a standardized language might not be worthwhile.

• Standardization of data formats to enable cross-system data exchange may prove valuable. One example can be WITSML (Wellsite information transfer standard markup language). It is XML-based standard for transmitting technical data between organizations in the petroleum industry. It is supported by all major international oil companies, this way it guarantees data interoperability in the industry. Further, ontology-like data model ISO15926 ("Industrial automation systems and integration—Integration of life-cycle data for process plants including oil and gas production facilities") was defined to increase interoperability.

• APIs may be difficult to standardize. There should exist an API for basic event processing operators such as publish and subscribe. APIs for the transport of rules from one EP system to another would also increase interoperability. Beyond these basic primitives, and perhaps a few others, it is unclear how API standardization would increase interoperability to justify the increased complexity/overhead.

• Standardization of programming models may not be necessary or worthwhile at this early stage.

What standards exist today in this space? What are their limitations?

• There exist some ontology development to define what event is. However, it does not relate directly to the interoperability issues.
• There exist some efforts in standardization in the event processing. One example is IBM's common base event (CBE). However, they still have not gained wide approval.
• Standards are being developed for Web-based publish/subscribe systems. There are two primary specs: WS-Eventing and WS-Notification. The standards are competing and it appears WS-Eventing will emerge, but the outcome is still unclear. The primarily limitations of the specs are that they are very cumbersome to use. This is more true for WS-Notification. In an attempt to make it as generic and flexible as possible, the spec has become difficult to understand, implement, and use. WS-Eventing is more lightweight, and this appears to be to its advantage. Another problem is that there is a lot of disagreement on the details of the specs themselves. The authors can not agree on seemingly insignificant details such as where a particular XML tag should be place, or what it should be called, etc.

What can be done to help the standardization effort?

• There is a conflict between academia and industry that is hindering interoperability. Industry has adopted XML as the standard message format, but academia refuses to use it as it produces weaker results.
• The EPTS is a good step forward. However, it must continue to push forward, even in the face of disagreements. Thoughts, ideas, and standards must be published in order to receive feedback, and then revised and improved accordingly. This will hopefully lead to consensus and adoption.
• Big corporations and governments interested in applying event processing technologies could (by contracts) enforce adoption of a standard.
• A public report should be published based on this work to further publicize the problem and increase knowledge of the problem space.
• A suitable way to enable event interoperability would be to design a standard framework that every system could communicate with. Thanks to this, every provider could keep their own internal implementation and just provide one standard external interface.