RE: [obix-xml] Issues

[Sam Yang <syang@echelon.com>]

We need to be careful when we use the term "subscription" (which normally
implies a pushed event model), since the oBIX draft has named its polling
event model "Subscription".  Maybe it would be better to use the terms
"polling model" and "push model" instead.

The XML SC moved away from using the push model because we did not want to
force oBIX clients to be servers themselves (in order to listen for pushed
events), and because it added complexity that we weren't sure we could
adequately address (especially since we wanted the XML spec to be decoupled
as much as possible from how clients and servers actually talked to each
other). 

On the other hand, if we really intend oBIX to be for enterprise-level
client applications only (and we don't care about supporting simple
lightweight oBIX clients), then we should support a push model for events
and make the best-practices recommendation described in Toby's message.

Also, if we are willing to be tightly coupled to Web Services, then we could
go the WS Resource Framework route and piggy-back off of the work of a lot
of other smart folks.  I had actually brought up WSRF as something to look
at a few months ago, but there was a lot of other stuff flying around at the
time, so it didn't get much attention (also, I didn't give is as good a
write-up as Toby).

If WSRF proves to be a good fit (and it seems like it could be), maybe the
XML SC should just confine itself to defining the XML schema for oBIX
"resources".  That would simplify our work a lot.  Of course, we would still
have to figure out how close WSRF is to becoming a standard, how widely it
will actually be used, how many platforms it will be supported on, and how
easily we could get our hands on working implementations.

Sam

-----Original Message-----
From: Considine, Toby (Facilities Technology Office)
[mailto:Toby.Considine@fac.unc.edu] 
Sent: Thursday, January 06, 2005 8:44 AM
To: 'Aaron Hansen'; Obix-Xml-Sc (E-mail)
Subject: RE: [obix-xml] Issues


3. Polling

- Since we can't add/remove points from a subscription, the likely
implementation scenario will be a subscription for every container.  This
could lead to a client with many threads polling a server.  I would like to
see the pollReq allow multiple subscription id's.

==========================
While Polling is normal in Control Apps, it is usually considered *bad* in
the wide area internet world.  I believe the preferred WS model (common to
WS-Events, WS-Eventing, and WS-Notification) is a Subscription model.  

We so not need to solve this before BuilConn, as we do not anticipate "many
points" in that time frame. 

Long term, I acknowledge that some sort of polling will be required. Perhaps
we need to suggest that best practices would be subscription based and some
sort of polling, if required, be restricted polling the overall service.

The model then would be:

"Mr. oBIX ERP:, tell me if anything noteworthy happens. By that I mean
points 1, 2, 3, 4, 5, 6, 7 ship to me every 5 minutes and tell me if points
A, B, C, D ever get outside of bounds." (A normal subscription request)

Client: "I will check of Mr. ERP is alive (one point, essentially a high-end
PING) every n minutes.  As long as he replies (or perhaps indicates good
health), then I will assume that no news is good news on the
subscription/notification events." 

I believe that such an approach will substantially expand scalability of an
oBIX solution as compared to other solutions that merely re-factor control
architectures into XML while better aligning us with best practices in Web
Services.

BTW - Each of the Subscription models has a TTL component.  We will need to
address algorithms for this, or means to parameterize/reacquire/... TTL
subscriptions before we are done.

tc