OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix-req message

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


Subject: 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:doug.ransom@pwrm.com
Website: http://www.pwrm.com
 
IONģ  smart energy everywhereô


 


From: Watson, Charles D [mailto:CharlesDWatson@eaton.com]
Sent: Monday, September 27, 2004 9:01 AM
To: obix-req@lists.oasis-open.org
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:Doug.Ransom@pwrm.com]
Sent: Friday, September 24, 2004 6:38 PM
To: obix-req@lists.oasis-open.org
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:doug.ransom@pwrm.com
Website: http://www.pwrm.com
 
IONģ  smart energy everywhereô






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