RE: [obix-req] Firewall traversal use cases

Title: Message

This isn't exactly a requirements issue, but I 
just recalled WS-Addressing handles firewall traversal.  

 

http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/

 

Standard enterprise middleware (xml routers etc.) should be able to deal with these issues.  If we carefully write OBIX service/message specs 
such that we are not bound to a protocol specifically (i.e. HTTP Request/Response), 
this becomes a non-obix issue.  

 

Doug Ransom 
Energy Analytics Domain 
Expert 
Power Measurement 
2195 Keating Cross 
Road 
Saanichton, BC, Canada  V8M 2A5 

Tel: (250) 652-7100  ext. 7558 

Fax: (250) 652-0411 
E-Mail: mailto: 
Website: http://www.pwrm.com 

  
ION®  smart energy everywhere™ 

 

  

  
  From: Watson, Charles D 
  [mailto:] 
Sent: Monday, September 27, 2004 
  9:01 AM
To: 
Subject: RE: 
  [obix-req] Firewall traversal use cases

  

  

  
This question depends 
  on where OBIX fits in the system scheme. If my understanding of the OBIX 
  scope from the last conference call is correct, we don’t need to concern 
  ourselves with firewall traversal. 

  
 

  
However, I don’t 
  agree with the limited OBIX scope that was suggested on the conference call. I 
  believe we need to go lower in the system which means we may require 
  communication between remotely located devices communicating over the internet 
  traversing firewalls. We don’t need to layout the exact method of 
  communication at this time because this standard has not even been 100% 
  defined by the IT (MS and others) powers concerned. But I believe we can 
  layout some high-end standards for data formats and minimum data content so 
  that hardware and system manufactures have something to guide 
  them.

  
 

  
Let me explain for 
  the people who were not on the latest phone conference and to be clear I 
  understood what was discussed on the phone. We had a short discussion 
  pertaining to the different levels in a system and where OBIX should spend its 
  time and resources.  The levels assigned here are my words, not what was 
  discussed on the phone but I believe the group needs to formally define these 
  levels.

  
 

  
Level 
  1: Communicating hardware devices: electrical meters, security and fire 
  alarm system components, HVAC components, etc.

  
 

  
Level 2: The 
  communicating gateway:  This device normally communicates with the level 
  1 devices, packages/transforms the data, and communicates it up to a central 
  data logging system.

  
 

  
Level 3: Central 
  logging and alarming system: Collects, monitors, alarms, and logs the data from the Level 2 
  systems and occasionally communicates with high-end level one systems 
  directly. This level is usually the HMI or visual process control level of the 
  system. The direct users of this system are still technical users who have 
  some understanding of the underlying hardware systems. These users are usually 
  concerned with how well and efficiently the system (HVAC, electrical, etc.) 
  operates from a technical perspective. They communicate with the system in 
  real time, know what is happening right now through direct interaction with 
  the system and the lower levels of the system.

  
 

  
Level 4: Enterprise 
  systems.  This is where the accountants, building managers, and general 
  management interact with the system. These users usually have little 
  understanding of the lower level components and usually are concerned only 
  with how much it costs, not how it technically works. At this level, the 
  communication is usually via reports or 
  some real time viewer (dashboards) but not direct 
  interaction.

  
 

  
Some of these levels 
  are combined in one device or system but a single device rarely constitutes 
  the entire system. So the format of communications between levels needs to be 
  defined.  This is where OBIX needs to define the XML standards/guidelines 
  in my opinion. During the phone call, it was stated that OBIX should only be 
  concerned with the transfer of data at the higher end of this scheme: 
  between levels 3 and 4. I don’t agree.

  
 

  
Although we don't 
  want to meticulously define the data interchange format between hardware 
  devices (level 1) and the level 2 & 3 systems, we do want to define 
  some standard of data content and some idea of its format. Otherwise, we will 
  get to the level 3 systems and the data may require complex transformation to 
  get the data into an acceptable format for the level 4 systems.  There could even be data pieces 
  missing. If we start laying some data transfer standards/formats lower in the 
  system, the data will already be practically in an acceptable format for the 
  next level with minimal transformation

  
 

  
In summary, if you 
  want high-quality data at the top, you need to collect high-quality, comprehensive data at the bottom. This 
  means the rights pieces of data in the right format at the right time. The exact method 
  of data transfer can be determined 
  later.

  
 
Thanks, 
  
  
Charles Watson (Chuck) CEM CMVP
tel: 724-779-5937 
  
http://www.eatonelectrical.com 
  

  
    

    
-----Original Message-----
From: Doug Ransom 
    [mailto:] 
Sent: Friday, September 24, 2004 
    6:38 PM
To: 
Subject: 
    [obix-req] Firewall traversal use cases

    
We have not had any use cases involving firewall 
    traversal.  Is this an issue. 

    
Doug Ransom 
Energy Analytics Domain Expert 
Power Measurement 
2195 Keating Cross Road 
Saanichton, BC, Canada  V8M 2A5 
Tel: (250) 652-7100  ext. 7558 
Fax: (250) 652-0411 
E-Mail: 
    mailto: 
Website: 
    http://www.pwrm.com 
  
ION®  
    smart energy everywhere™