[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. tc ""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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]