RE: [obix-xml] OBIX Design Considerations

Title: Message

I also 
agree the WS-* namespace is confusing.  It is also irritating the major 
vendors can't cooperate early.  Maybe its better they produce competing 
specs and toss the worst one.

 

WS-Eventing is getting a lot of press, probably because of Microsoft and 
Don Box's weblog publicizing it, and its very simple.  

 

WS-Notification http://www-106.ibm.com/developerworks/library/ws-pubsub/ has more features.  Some are interesting, 
like the idea of the topics and brokered notification.  It is not as 
simple.  

 

Sometimes what appears to be the simple solution turns out to be 
the naïve one.  There may be good uses of the advanced 
features of WS-Notification over the simplicity of WS-Eventing.  I 
think this will fall out (again) from the use  
cases.

 

Doug

  

  
  From: Sam Yang [mailto:] 
  
Sent: Tuesday, September 21, 2004 5:28 PM
To: Doug 
  Ransom; OBIX XML
Subject: RE: [obix-xml] OBIX Design 
  Considerations

  

  
I 
  agree that we should not reinvent the wheel.  It does look like there are 
  a lot of similar efforts underway that we should look at.

  
 

  
For 
  instance, OASIS has its own "WS-Notification" effort, which overlaps 
  "WS-Eventing".  IBM is a chief sponsor of WS-Notification, but in August 
  also jumped on the WS-Eventing bandwagon.  Pretty 
  confusing, but I gather that the two efforts will be merged 
  somehow.  At least both efforts are based on 
  WS-Addressing.

  
 

  
Another effort that overlaps ours is also already underway in OASIS: 
  "WS-Resource Framework".  Not only does it also rely on WS-Addressing, 
  but it is for "modeling stateful resources with web services", which sounds a 
  lot like points in a control network.

  
 

  
It 
  is indeed possible that our efforts may be fulfilled with a little bit of oBIX 
  stuff, and a lot of WS-* stuff.

  
 

  
-----Original Message-----
From: 
  Doug Ransom [mailto:] 
Sent: Tuesday, September 
  21, 2004 12:58 PM
To: OBIX XML
Subject: RE: [obix-xml] 
  OBIX Design Considerations

  
    
My main concerns 
    are: 
- we don't 
    reimplement what we can reuse 
- that our spec isn't obsolete at the time or shortly 
    after its released because we aren't compatible with ws-this and 
    ws-that.  That is a bit of a challenge for us.  If these are truly 
    orthogonal specs, mabye it is not an  issue.   
    

    
I am hoping when the use-cases 
    are flushed out, it will be clear how they are fulfilled with OBIX and 
    related (WS-* etc) stuff.  We may very well be able to simply define a 
    few interfaces for OBIX and say "compose these with whatever WS-* you want" 
    and achieve sufficient interoperability.

    
I admit that I  do not 
    understand how the design so far fits into the bigger picture of what I 
    would do with obix specifically (and how big a peice of the puzzle it 
    currently is).

    
Doug 

    
________________________________ 

    
        From: Aaron Hansen [mailto:] 
        Sent: Friday, September 17, 2004 9:37 AM 
        To: Doug Ransom; OBIX XML 
        Subject: RE: [obix-xml] OBIX Design Considerations 
    

    
        
            I liked 
    the simplicity of WS-Eventing as well.  One issue 
    mentioned 
in the 
    past was server-to-client authentication.  First of all, is 
    this 
really an 
    issue?  If so, do any of the eventing specs handle it?  
    Can 
they?  
    Fodder for our next telecon.   

    
        I appreciate what you are doing Doug, but our job isn't to 
    fend off a 
barrage of "how about WS-XYZ" requests.  Documenting why we 
    didn't use 
a spec 
    would be irrelevant to someone looking at our spec for 
    
implementation purposes.  
    We need an informed presentation about why we 
should consider WS-XYZ and the discussion 
    will be recorded in our email 
archive or meeting notes.  If we use a specification, 
    of course it will 
be documented.      

    
        There is a seperate committee for best practices and 
    guidelines.  With 
that in mind, I don't think our committee should define 
    relationships 
to 
    orthogonal specs such as UDDI, WS-Reliability, SSL...  
    

    
        I found this nice article on WS-Addressing 
    
(http://www-106.ibm.com/developerworks/library/ws-address.html 
<http://www-106.ibm.com/developerworks/library/ws-address.html> ).  It 
has me thinking we should use that spec 
    too.  Initially I thought all 
we wanted to do was provide and wsdl uri and an opague 
    name/id for the 
piece of data.  I think WS-Addressing can be that simple (does 
    anyone 
know for 
    sure?) but I guess if someone wanted to reference an 
operation, why 
    not!       

    
        Potential problem, ws-addressing is built on soap 
    1.2.  No one uses 
1.2 yet, even MS who worked on ws-addressing doesn't support 
    1.2.  When 
do we want people to start implementing oBIX?  Is this 
    a 
dead-on-arrival 
    kind of issue?   

    
        BTW, WS-Addressing is a nice small spec: 
    
http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/ 
<http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/>  

    
        I'm in agreement that we don't use XML RPC 
    semantics.  Earlier this 
year I had to implement a web service and had to decide on 
    document 
versus 
    rpc encoding.  I can't remember why I chose the path of 
    document 
encoding, but unless someone feels strongly about using RPC I'd 
    rather 
not spend 
    anymore cycles on it.    

    
        I'm not sure polling is the anti use case.  Think 
    about Rob Zivney's 
insighful comment about the future of this space.  Integrators 
    are 
going to 
    approach an enterprise and make a proposal based on the 
    
cost-savings by hooking up, for 
    example, access control to HR.  Now 
imagine this enterprise is a government 
    agency.  The number of points 
they may want to monitor could be massive (all government 
    buildings in 
a 
    city).  Is this example unrealistic?      
    

    
        Aaron