# 
# Mon 25 July 2005
#
# Objective: discuss coordination of instrument interfaces for SIAM and LOOKING
#
# Attending: O'Reilly, Gomes, Graybeal, Matthew Arrot (LOOKING)
#


IEEE 1451 is a great spec, it talks about all the concerns, provides a framework for talking about these things.

Standard is only 6 yrs old, so OK that it's not adopted yet.

How/If to use 1451, all, part, use as discussion framework, level of compliance

Tightly/loosely coupled systems

Where are interfaces?

Differing architectural models (SIAM uses distributed component (RMI) vis a vis "flow control" model (messaging) )

RoadNET/SIAM/PUCKS/LOOKING - how do they fit together

WSDL (WS description language), WSRF (WS resource framework), 

Governance: security, Authentication, Accounting, Authorization (AAA)

Instrument proxy separate from instrument service; proxies may represent real time intrument behavior as well as archived data streams. Proxy can be deployed in different places based on available bandwidth and computing resources.

# 1451
network interface, transducer interface
network interfaces chain together
Transducer Blocks: functional components
NCAP: Network Capable Application Processor

Dimensions: analog, discrete, digital
Scalar, Vector
Static, Variable
Application-specific functional blocks
1451.1: Common Object Model : how 
1451.0: TEDS and common functionality

Arrot seeking to capture/define common behavior in a standard way

blocks, components and services

shims: 1451, SIAM (can these be the same, i.e., make SIAM 1451 compliant), RoadNET/Antelope

block: code component; can be started, stopped, reset?

an NCAP can aggregate a cluster of instruments

* How to extend NCAP to a specific instrument
* it would be good to get Jeff Burch to show an example (Seabird) of how this done
* does the 1451 behavior expand, restrict SIAM capabilities? How does SIAM map into 1451?

# overall strategy
meshing differing architectures
Home Object, Remote Object
 Enterprise Stakeholder view
  information model
   functional components
    how to distribute these (distributed component model, flow composition model (messaging))

J2SE,CORBA: framework incorporates communications layer, presumes that remote and home are working in the same domains. requires that technologies are the same on both sides (COM,CCM,EJB). further presumes that remote side will execute home code on its behalf. -> tightly coupled. Where does governance go? it has to go deep in the application on the remote side. Federating is diffult, because governance has to account for context differences between the remote and many home nodes. Aspect Oriented Programming (AOP)

Web Services: flow composition (messaging model) (SOAP,ebXML,JMS)

make interfaces discoverable and define behaviors and communication requirements. service stub on remote side implements governance and policy as well as acting as proxy for remote side.
channel: highest level negotiating semantics etc. create path to negotiate lower and lower levels.

rather than hiding communications, externalize yourself  on your own boundary so that anyone on the outside can commnunicate with you.

corba does this pretty much, but it's hard to use and requires buying a corba implementation.

Binding Framework: RM-ODP, CommerceNet

There are lots of things in the WS approach that haven't been defined and will change; it will break things and appear brittle. Don't think of it as the end point, but as an opening to loosely coupled systems.

Have to be careful when choosing technologies not to get into proprietary technologies.

# CIMA/SIAM NSF Proposal: not likely to be funded
WSRF : notification, properties are part of WSRF, but not WS. 
CIMA web service (Ian) includes SIAM proxy

SIAM, antelope two most important to Arrot.

TEDS in puck?
Automation of WS code generation? best way may be to build the yellow box (CIMA web service).

does 1451 include geographical location as part of standard?
SensorML is another alternative - 1451 and lots more? these probably go together, one on top of the other.

SensorML: informational view
IEEE 1451: computational view