Skip to content

Microservice Communication

Jump to bottom Edit New page
vju-1011001 edited this page Aug 15, 2014 · 22 revisions

Some initial proposal

get the information model via:


curl -LH "Accept:text/turtle" http://fiteagle.org/ontology
  1. I think for now the only JMS properties that should be set are:
    1. “setStringProperty(METHOD_TYPE, TYPE)” – see attached list: Request, Create, Configure, Release, Inform, Discover
    2. “setJMSCorralationID(CORR_ID)” – to reply to a specific request (e.g. for the REST API)

This means that all services should set their filter to receive Discover messages, and e.g. east-bound services should also get Inform messages, while north-bound services (aka adapters) should also get Create, Configure and Release messages. This might lead to some needless parsing but we can optimize later on.

  • The JMS messages should be JMS TextMessages and contain the actual information as TTL serialized RDF graphs. Examples are:

---------------------
:IncomingMessage rdf:type fiteagle:Configure .
<http://url/to/our/fiteagle/installation#MyNewMotor123 motor:rpm "23" .>
---------------------

or


---------------------
:IncomingMessage rdf:type fiteagle:Create .
:MyNewMotor123 rdf:type motor:Motor ;
                       fiteagle:implementedBy <http://url/to/our/fiteagle/installation#MotorGarage1> ;
                       rdfs:label "a new motor in garage 1" .

:MyOtherNewMotor rdf:type motor:Motor ;
                       rdfs:label "a new motor to be instantiated at a resource (aka adapter) that can create motor:Motor resources" .
---------------------
  • A view from the federation point of view is given at http://federation.av.tu-berlin.de/fed4fire/lod/federation.html (also see attached screenshot). The actual data look like this ( https://github.com/open-multinet/playground-rspecs-ontology/blob/master/data/example-federation-fed4fire.ttl ) and the underlying ontology for federations is this one ( https://github.com/open-multinet/playground-rspecs-ontology/blob/master/ontologies/omn.ttl ). Next steps are the ontology for testbeds and fiteagle internal.

Q:

“all services should set their filter to receive Discover messages”. What does this mean? Micro services import and use the jms.MessageListener() to listen to all circulated messages and filter them using a local method within the class.

A:

we’ve to start with an approach (which we can optimize later on). My proposal is that all services listen to the message bus and set a very rough filter. See https://github.com/FITeagle/core/blob/master/repo/src/main/java/org/fiteagle/core/repo/dm/ResourceRepositoryMDB.java#L23 how to do this.
So the general idea is, that FITeagle2 just work on a large graph and updates (INFORM messages) are persisted in a triple store. Examples:

  • An information pushing service (e.g. OMSP northbound service or an southbound adapter ) pushes RDF updates as an INFORM message to the message bus. A receiving service listens to INFORM messages to update the graph (e.g. an RDF storage westbound service) or to push the information to external services (e.g. an OMSP eastbound service).
  • An information pulling service (e.g. REST GET method) pushes RDF queries as a REQUEST message to the message bus. A receiving service listens to REQUEST messages and pushes the according information as an INFORM message (e.g. an RDF storage westbound service) .
  • An information/resource creating service (e.g. REST PUT method) pushes a new RDF graph as a CREATE message to the message bus. A receiving service listens to CREATE messages to instantiate the resources and pushes according information as an INFORM message (e.g. a motor garage adapter)
  • An information configuration service (e.g. REST POST method) pushes a new RDF graph as a CONFIGURE message to the message bus. A receiving service listens to CONFIGURE messages to change information of an instance and pushes according updated information as an INFORM message (e.g. a motor garage adapter).
  • An information/resource deleting service (e.g. REST DELETE method) pushes a new RDF graph (probably only the URI of the instance) as a RELEASE message to the message bus. A receiving service listens to RELEASE messages to remove the resources and pushes according information as an INFORM message (e.g. a motor garage adapter).
  • An internal service push a short DISCOVER message and all deployed services should return an INFORM message that provide their RDF representation.
  • There is no “Describe” message or method. As soon as you deploy an adapter (or when an adapter receives a JMS DISCOVER TextMessage), it pushes an INFORM message to the bus. The content would look like this (might not be syntactically 100% correct):
========================================
@prefix fiteagle: <http:/fiteagle.org/ontology#> .
@prefix motor: <http://example.org/motor/ontology#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix : <http://fiteagleinternal#> .

:Message rdf:type fiteagle:Inform .

:ADeployedMotorAdapter1 rdf:type motor:MotorGarage ;
                      rdfs:label "A motor in garage 1" .

:ARunningMotor rdf:type motor:Motor ;
                      fiteagle:implementedBy :ADeployedMotorAdapter;
                      rdfs:label "a new motor in garage 1" ;
		      motor:isDynamic true;
                      motor:rpm 23 .
========================================

This tells the message bus that:

  1. there is a resource of type “http://example.org/motor/ontology#MotorGarage” with the URI http://fiteagleinternal#ADeployedMotorAdapter1 (i.e. the deployed motor adapter)
  2. there is a resource of type “http://example.org/motor/ontology#Motor” with the URI http://fiteagleinternal#ARunningMotor that is controlled by http://fiteagleinternal#ADeployedMotorAdapter1 (i.e. the motor adapter has created a motor)

Now we could send a configuration message from the north like this:

========================================
@prefix fiteagle: <http:/fiteagle.org/ontology#> .
@prefix motor: <http://example.org/motor/ontology#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix : <http://fiteagleinternal#> .

:Message rdf:type fiteagle:Configure .

:ARunningMotor rdf:type motor:Motor ;
			   motor:rpm 23 .

========================================

Now every service that listens to CONFIGURE messages (e.g. adapters) has to check whether it can do anything with the URI http://fiteagleinternal#ARunningMotor – most probably only the adapter http://fiteagleinternal#ADeployedMotorAdapter1 will handle this message. Yes, it might be more efficient to have a orchestrator instead that forwards the message to the correct adapter.
Now http://fiteagleinternal#ADeployedMotorAdapter1 will update the information in the instance and pushes an INFORM message to the bus:

========================================
@prefix fiteagle: <http:/fiteagle.org/ontology#> .
@prefix motor: <http://example.org/motor/ontology#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix : <http://fiteagleinternal#> .

:Message rdf:type fiteagle:Inform .

:ARunningMotor rdf:type motor:Motor ;
			   motor:rpm 23 .
========================================

Now service that listens to INFORM messages will parse this information. E.g. the RDF storage will be updated.

Q:

I think it is a lot more effective to work with correlation IDs instead of sending INFORM messages to everyone producing a lot of traffic.

A:

  1. The CorrelationID should be set to allow a mapping to synchronous calls in e.g. REST APIs. See for example https://github.com/FITeagle/core/blob/master/repo/src/main/java/org/fiteagle/core/repo/dm/ResourceRepositoryREST.java#L135
  1. Not all services receive INFORM messages (e.g. an adapter should not care about theses messages). Also filters could be optimized to include messages that have no correlation ID.
  1. In is intended to have a point-to-multipoint communication (e.g. the logger should in parallel receive this information)
  1. To have a more efficient architecture, a new topic should be created for each resource (this is what FRCP does). But this makes the architecture more complicated and I first want to get it working – doesn’t have to be that performant.

Q:

When sends a RA an INFORM message? Only once implemented and integrated, periodically, or once Discover message is circulated?

A:

It depends. It should send an INFORM message when:

  1. it gets deployed (since the adapter creates an instance of its own at startup)
  2. it receives a monitoring information that it wants to forward
  3. it receives a DISCOVER message
  1. You’ve to distinguish between an instance of an adapter (e.g. MotorGarage instance) and an instance of a resource that can be created by an adapter (e.g. Motor instance). But at the end all are resources that might can instantiate other resources.

Q:

in case the resource adapter that sends the inform message has already created several resources that are running, shall the inform message list all of them (as in your example, the inform message includes two informative messages, a MotorGarage is to be deployed and a Motor is running, both by the RA sending the inform message)?

A:

It depends. I think after a DISCOVER message it should return all the information. After a other messages only the new/updated information.

Q:

In your example, are the MotorGarage and Motor the same or two different ones?

A:

There was one MotorGarage (aka as motor adapter) that created two Motors (aka as motor resource).

Add a custom footer
Add a custom sidebar
Clone this wiki locally