[Moims-dai] Discussion of options for the switchboard

[david at giaretta.org]

Dear all

 

At the last meeting Paul suggested that we could use the HTTP HEAD request
to obtain information about what the server would respond to, rather than
rely on the Switchboard.

 

I guess the OPTIONS request ( https://www.rfc-editor.org/rfc/rfc9110#OPTIONS
) would be more applicable. 

 

OPTIONS is part of HTTP and so a HTTP/REST server would of course respond to
the OPTIONS request without needing any special mechanism. However the
response would need to be created that is specific to the system. I guess
web servers have these things built in

If we specify that only HTTP/REST should be used then this would be OK, but
if we want to allow the use of MAL etc also, then this could require a
MAL-based server to support both REST as well as MAL.

 

The RFC does not specify what attributes OPTIONS returns, but the GB
provides the following list of information needed, for which the BB has a
Switchboard interface.

*	DESCRIPTION OF ARCHIVE
*	URL/PORT
*	AUTHENTICATION METHOD FOR COMMS
*	SERIALISATION (JSON at this time) including VERSION
*	COMMUNICATION PROTOCOL (REST at this time but in future others may
be possible such as Space Link or ..)
*	QUERY LANGUAGE to use and QUERY PARAMETERS - to allow queries to be
constructed

 

 

DISCUSSION of possibilities

 

IN what follows I discuss 2 options - keep the Switchboard as if, or use an
OPTIONS approach i.e. ask the service for the info.

 

1.	Continue to use SWITCHBOARD 

The reason I had adopted the Switchboard approach was to accommodate the
idea that we should not be restricted to a specific protocol i.e. HTTP/REST.

On the other hand, Microservice architectures often have a Discovery service
such as NetFlix Eureka, which Spring Boot supports. However, use of this
service seems more than we need, and more useful for Microservices - and
could be used if the BB is implemented as such, but we would not need to
specify it in the BB.

 

If we go back to an earlier version of the layer diagram:



 

This shows that the Switchboard, and RRORI communicate using REST.

This allows both resources to be shared between many generic adapters. In
principle there could be a single Switchboard and a single RRORI used by all
generic adapters.

 

The single Switchboard would act as a discovery service/OPTIONS request
server, without being specific to, for example, an archive.

 

However, in earlier discussions we decided to avoid needing to have a
central resource.

 

PROs:

*	A local discovery service which would allow us to deal with multiple
communications protocols in future and to search for specific
services/archives by description.
*	No need for a central service
*	The services which are to be used can be tailored i.e. I only want
to deal with a specific set of services/archives and here is the list.  In
principle a Switchboard could communicate with a central service for updates
and extra services/archives.

CONs:

*	the Switchboard would need to be set up and kept up to date - the
mechanism to do this is not specified in the BB, MB or GB - but as noted
above a central service is not forbidden.

 

2.	Use OPTIONS i.e., request the "switchboard" type information from
the server concerned

 

This has the advantage that we do not need centralized knowledge of the
capabilities of each, for example, archive. It would be easier if we forget
about using MAL in this BB.

Instead of specifying the HTTP/OPTIONS explicitly we can simple transfer
most of the Switchboard interface methods to the Generic Adapter. Each
Generic Adapter could have the required information in, for example, a
properties file. 

 

PROs:

*	No need to maintain a list of services with details as above

CONS:

*	No ability to search for useful sources of information i.e., a
discovery service.
*	Don't know what port to use.

 

PROPOSALS:

 

1.	Move the methods to access the following pieces of info to the
Generic Adapter so that the GA responds when contacted. We should specify
the JSON for the response encoding.

*	AUTHENTICATION METHOD FOR COMMS
*	SERIALISATION (JSON at this time) including VERSION
*	COMMUNICATION PROTOCOL (REST at this time but in future others may
be possible such as Space Link or ..)
*	QUERY LANGUAGE to use and QUERY PARAMETERS - to allow queries to be
constructed

.

 

Also keep a minimal Switchboard to provide:

*	DESCRIPTION OF ARCHIVE
*	URL/PORT

The alternative is to get rid of the Switchboard and simply rely on
"external" sources of information not specified in the BB.

 

 

Any thoughts?

 

..David 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20231016/c253a51b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 86065 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/moims-dai/attachments/20231016/c253a51b/attachment-0001.png>