AB Controls | SL Controls | PS Controls | LHC-CP | ST Controls

 

 

Minutes of the Middleware meeting 18 January 2000

Present: Nikolai, Franck, Kris, Vito, Alessandro, Marc

We discussed the content of the publish call, the content of the
subscribe call, the architecture and use of configuration services.

1. The publish call

The content of the publish call was proposed at the previous meeting.
In addition to this device name and property name should be sent with
every publication.
Date type was not judged necessary. POSIX date will be used for the time
being.
Freshness information will be included in the data quality item (from
cache, from device)

It has to be investigated how all this data have to be structured in the
MOM messages. This might influence the packing it into arguments and the
way optional data is dealt with (subclassing, tagged messages)

2. The subscription call

Content of the subscription request:
Device name, property name, timing selector (a class to be defined) and
request ID (probably object request ID - t.b.d)

Passing of the server's native item identification with the request was
dropped. Instead, the server should have the capability of resolving the
device/property to the local addressing and identity information.
This could be done as a separate (CORBA) service.

3. Architecture
The drawing in the attached paper shows in which layer this interface is
located.

Actions:
1. Kris + Nikolai will propose an IDL
2. Marc will investigate JMS message structures to see if what we
propose is compatible.
3. Vito and Alessandro will work on the pub/sub interaction diagram.
4. Vito will work with Marc (and Francesco?) on the Pub/Sub with JMS.

Open questions:

I forgot to raise this question at the meeting. The subscribe agent
knows about the type of property. The server may use a different native
type. Who does the conversion and how is the type handshaked? Different
possibilities:

1. We do not allow this. Server has to find the type out from the DB.
This would reduce the flexibility and de-coupling of servers.
2. Passing the required type with the subscription. This is what OPC
does.
3. Passing native type of the server along with the type description in
the publish data.

Next meeting

I propose to work on the action items separately and meet when there was
significant progress (in 2-3 weeks?)

Kris

Copyright CERN
Modified 06/10/00 .  For comments send email to Kris.Kostro@cern.ch