[Moims-dai] FW: Further thoughts on adapters

[david at giaretta.org]

As suggested during the meeting on Tuesday I have added numbers to the text
description to identify the corresponding arrows in the diagram.

 

1.	Each will need to buy/borrow/create their specific portion of the
adapter that depends upon its specific software design and capabilities e.g.


a.	for an InfoSource - is it a simple file server which we can
supplement with a database of RepInfo etc         [1]
b.	for an InfoRequester - can it deal with tables and/or images or is
it only for displaying documents etc               [2]

2.	They each then install the generic portion of the adapter - I think
this can be common to all.                                       [3], [4]

This generic portion does the following things:

a.	Find out about InfoSource using interface we define
b.	Register itself and the InfoSource with the Switchboard e.g. how
others can communicate with it - HTTP/port80 or HTTP/port 2678 or REST or
CORBA or RMI etc etc

This is done just once for each source (or requester)
[5], [6]

3.	During operations the requester discovers somehow that it needs some
information from an InfoSource - how this is done is not covered here. I
think lots of work has been done by others, and OAIS does not really provide
any guidance.
4.	InfoRequester generic adapter finds out from the Switchboard how to
talk to the InfoSource in order to fit into the "OAIS-IF world", and sets up
the communication [7].[8], [9]
5.	The specific adapter of InfoRequester passes on the request to the
generic adapter which passes on the request to the InformationSource generic
adapter         [10], [11]
6.	The generic adapter of the InfoSource receives the request and
passes it to the specific adapter which gets the DataObject and RepInfo (at
least the start of the RepInfoNetwork) and passes that back
[NOT SHOWN]
7.	The InfoSource generic adapter creates an PackagedInfo object and
sends that to the generic adapter of the InfoRequester  [12]
8.	The generic adapter of the InfoRequester asks the specific adapter
if this is OK. If not then the generic adapter exchanges messages with the
InfoSource generic adapter, which may need to talk to the InfoSource
specific adapter.
[13], [14], [15], [16], [17]
9.	PackagedInformation packages are send containing RepInfo until the
InfoRequester is satisfied, or else a strategy is decided to use
Transformation, if the InfoSource can do that
[18], [19], [20], [21]
10.	It may be that a Registry of RepInfo (essentially another
InformationSource) is available and known to the generic adapter, and
additional RepInfo may be obtained from that.
[22], [23]

 

 

Clearly the diagram needs some tweaks but I think this identifies the main
steps. 

 

Regards

 

..David

 

From: david at giaretta.org <david at giaretta.org> 
Sent: 22 June 2021 13:32
To: MOIMS-DAI List <moims-dai at mailman.ccsds.org>
Subject: Further thoughts on adapters

 

Dearf all

 

Thinking some more about adapters and what they need to do I have the
following suggestion, making some additions to the diagram I sent out
yesterday.

 

I think we can separate the adapter into 2 parts, (1) a part which  is very
specific to the object that is sending or receiving information, (2) a
generic part which contains much of the logic about packages and requests.
The interface between these two parts can be specified - but I only have it
in outline at the moment.

 

Taking some inspiration from Mike's PPT diagrams I think we can describe the
setup and operations as follows for a given pair of InfoRequester and
InfoSource

 

1.	Each will need to buy/borrow/create their specific portion of the
adapter that depends upon its specific software design and capabilities e.g.


a.	for an InfoSource - is it a simple file server which we can
supplement with a database of RepInfo etc
b.	for an InfoRequester - can it deal with tables and/or images or is
it only for displaying documents etc

2.	They each then install the generic portion of the adapter - I think
this can be common to all. This generic portion does the following things:

a.	Find out about InfoSource using interface we define
b.	Register itself and the InfoSource with the Switchboard e.g. how
others can communicate with it - HTTP/port80 or HTTP/port 2678 or REST or
CORBA or RMI etc etc

This is done just once for each source (or requester)

3.	During operations the requester discovers somehow that it needs some
information from an InfoSource - how this is done is not covered here. I
think lots of work has been done by others, and OAIS does not really provide
any guidance.
4.	InfoRequester generic adapter finds out from the Switchboard how to
talk to the InfoSource in order to fit into the "OAIS-IF world", and sets up
the communication
5.	The specific adapter of InfoRequester passes on the request to the
generic adapter which passes on the request to the InformationSource generic
adapter
6.	The generic adapter of the InfoSource receives the request and
passes it to the specific adapter which gets the DataObject and RepInfo (at
least the start of the RepInfoNetwork) and passes that back
7.	The InfoSource generic adapter creates an PackagedInfo object and
sends that to the generic adapter of the InfoRequester
8.	The generic adapter of the InfoRequester asks the specific adapter
if this is OK. If not then the generic adapter exchanges messages with the
InfoSource generic adapter, which may need to talk to the InfoSource
specific adapter.
9.	PackagedInformation packages are send containing RepInfo until the
InfoRequester is satisfied, or else a strategy is decided to use
Transformation, if the InfoSource can do that
10.	It may be that a Registry of RepInfo (essentially another
InformationSource) is available and known to the generic adapter, and
additional RepInfo may be obtained from that.

 

A diagram which tries to capture this is attached - an update of the diagram
sent yesterday.

 

So we need to define

A.	The interface between the generic and specific adapters
B.	The outward facing generic adapter interfaces and logic - a lot of
this is in the GB draft
C.	The OAIS-IF objects sent over the wire - most of this Steve has
defined
D.	The Switchboard is just another InfoSource, as is the Registry
E.	The  interfaces to deposit information into an InfoSource - the
Producer/Archive interface - to be done later because it is rather more
difficult to do generically

 

Hope to discuss this at the Skype meeting later today.

 

Regards

 

..David

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20210625/6810cbed/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SequenceDiagram-with-adapters-v2.jpg
Type: image/jpeg
Size: 120345 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20210625/6810cbed/attachment-0001.jpg>