OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

obix-xml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Who are our Allies?

One of the goals of moving to OASIS was to remove some exceptionalism from oBIX, i.e., to make sure that whatever we produce is a normal enterprise thing, that standard tools kits would know how to interact with oBIX, and that Enterprise programmers would recognize what we produce.


Peter has mentioned WSDM as a potential model for oBIX. This is intriguing, but not yet convincing to me (OTOH, this is because I need to get a lot more familiar with what WSDM means).  The short form is that WSDM exposes Resources (as defined in WSRF) and events (as defined in WS-Notification) under a framework that supports the usual WS-Security concepts.  It is also supposed to handle WS-Policy, but I am not sure that WS-Policy is far enough along to be of any use.  WS-Policy may turn out to be the link between what we now call oBIX services and enterprise directory services. There are also pre-built hooks for applying BPEL (Business Process Execution Language) the Resources.  BPEL integration may just be the value-add that makes the entire world rip out today’s control systems and replace them with oBIX compatible ones by Spring.


Mapping to what we have (which I am very please with) what we have been calling services look an awful lot like WS-Resources.  A WSDM point can expose one or many Resources.  Off the top of my head, I am thinking of a generic oBIX Resource, HVAC Resource, Access Control Resource, Fume Security Resource,  a Power Management Resource… If we have multiple like Resources exposed though one oBIX point, then we could define what WSRF calls Service Groups to encompass them. TO summarize the specifications that are WSRF:


WS-Resource Properties defines how the data associated with a stateful resource can be queried and changed using Web services technologies. This allows a standard means by which data associated with a WS-Resource can be accessed by clients. The declaration of the WS-Resource’s properties represents a projection of or a view on the WS-Resource’s state. This projection represents an implied resource type which serves to define a basis for access to the resource properties through Web service interfaces.

WS-Resource Lifetime defines two ways of destroying a WS-Resource: immediate and scheduled. This allows designers flexibility to design how their Web services applications can clean up resources no longer needed.

WS-BaseFaults defines an XML Schema type for a base fault, along with rules for how this fault type is used by Web services. A designer of a Web services application often uses interfaces defined by others. Managing faults in such an application is more difficult when each interface uses a different convention for representing common information in fault messages. Support for problem determination and fault management can be enhanced by specifying Web services fault messages in a common way. When the information available in faults from various interfaces is consistent, it is easier for requestors to understand faults. It is also more likely that common tooling can be created to assist in the handling of faults.

WS-ServiceGroup defines a means by which Web services and WS-Resources can be aggregated or grouped together for a domain specific purpose. In order for requestors to form meaningful queries against the contents of the ServiceGroup, membership in the group must be constrained in some fashion. The constraints for membership are expressed by intension using a classification mechanism. Further, the members of each intension must share a common set of information over which queries can be expressed.


There are no less than three Event system specifications, WS-Events, WS-Notification, and WS-Eventing.  AFIK WS-Events has faded away, and the duel is on between Eventing and Notification.  WSDM uses Notification. The good news is that it appears that WS-Notification will encompass the simpler WS-Eventing.  It is not much of a stretch to suggest the WS-Notification could encompass the oBIX alarm service as well.


Much of the WSDM spec, (so I have been told, I still need to curl up with it and read it) is specifying which of several compliant ways to do things.  We will probably need to get to this as well. There is another bit, something called “manageable resources” which seems to be defined as “resources that WSDM manages” I do not, as of this time, understand what this is, and whether we need to make oBIX resources manageable.


Under this model, if it fits, oBIX, then would consist of a series of WS-Building Controls , WS-Notification for Controls, the Historian (still to be defined later) and the oBIXML XSD defining the vocabulary of Building Controls. The other WSDM structures would apply.  If for some reason WSDM does not really fit Building Controls, all other servers (Security, etc) would be applied in a strictly analogous was to how they are under WSDM.


None of this is meant to deprecate the solid work done already. Rather this is meant to indicate a possible path for normalizing oBIX to align with other enterprise standards. If we can fit our work into the WS Resource Framework, then we can take advantage of other projects. For example, the WSRP


Why do I bring this up now? The committees for WS-Notification and WS-Resource Framework are both having Face-to-Face meetings in the Research Triangle (Raleigh-Durham-Chapel Hill) in the week that spans End of January / Beginning of February.  Several members of the WSDM committee will be in town as well.  I am trying to arrange a meeting (either one evening or Friday afternoon) to discuss areas of mutual interest.  I would welcome anyone on the XML committee who wanted to attend.  The meeting is purely exploratory, but it would be good to have more ears at it than mine.





""I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use." -- Galileo Galilei

Toby Considine
Facilities Technology Office
University of North Carolina
Chapel Hill, NC


Email: Toby.Considine@fac.unc.edu
Phone: (919)962-9073


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]