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: obix, discovery, and more...

I'm starting to get back into obix after a summer of distractions.  Lately I've been doing
some brainstorming on our current design and how it relates to discovery.  This process
has led to the following conclusions:
- The main value of the work we did under the guise of the PointService is really to normalize
  how primitives are represented and annotated with meta-data (like min, max, range, etc)
- That led me to think that maybe the PointService is really just the service used to read and
  write data primitives
- That led me to think about the DiscoveryService as a way to read complex structures down
  to the primitive level
- That led me to think that maybe Discovery and Points is really all just one thing...
What I am thinking is that we collapse Discovery and Points into a single service which I've been
thinking of as the Reflection service.   To me it encapsulates two primary goals:
 - to learn the structure of any vendor's system without needing to know a whole bunch
   of types and data structures ahead of time
 - to normalize key data primitives so that systems can exchange basic data
I've been thinking about the Reflection service similar to COM's IDispatch or Java/.Net reflection
APIs.  It lets me use a small set of wrapper types to generically describe and interact with the
vendor's native data model without needing to know all the gory details about the vendor's native
type system. 
Plus we would still use the Reflection service as a discovery and jump point into other more rigidly
defined services.  Thus reflection can be used to interact with a vendor's system generically using
loose typing, but still let's us jump to strongly typed services for solving domain specific problems
like history, scheduling, or alarming.
My thinking is that the reflection service provides two operations Get and Put.  I've haven't given
a lot of thought to the exact XML syntax, but just to show an example:
  <!-- root object of the get request -->
       <!-- child object, string description -->
         <Value>someid's description</Value>
       <!-- child object, int counter with facets -->
Does this seem like a sane way to proceed?

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