Skip to content

Microservice Communication

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

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.

Let me look at your example:

> :IncomingMessage rdf:type fiteagle:Describe .

Probably you mean fiteagle:Request

> :open-epc-client rdf:type rdf:resource ;
> fiteagle:targets fiteagle:resourceDatabase ;

What is “targets” and what is “resourceDatabase”?

> rdfs:label “open-epc-client deployed on a physical server” ;
> rdfs:comment “user’s name and public key are required for login” .

What should be the result of the request? Maybe the description of the OpenEPCClient? If this is the case, I suggest:

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

:Message rdf:type fiteagle:Request .
:Resource rdf:type epc:client.
========

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

:Message rdf:type fiteagle:Inform .

:ARunningEPCclient1 rdf:type epc:client ;
fiteagle:implementedBy :AnEPCClientAdapter ;
rdfs:label “New EPC Client” ;
rdfs:comment “Our EPC Client that is under the table” .

:AnOtherRunningEPCclient32 rdf:type epc:client ;
fiteagle:implementedBy :AnEPCClientAdapter ;
rdfs:label “The old EPC Client” ;
rdfs:comment “An EPC Client that is on the table” .
========

> we still need to say that this resource is a part of fuseco, I don’t know how to represent this, maybe:
>
> fiteagle:offeredBy fiteagle:testbed fuseco ;

Different possibilities. One example:
========
@prefix : <http://fiteagleinternal#> .
@prefix epc: <http://example.org/epc/ontology#> .
@prefix omn: <http://open-multinet.info/ontology#> .

:AnEPCClientAdapter rdf:type epc:ClientCreator ;
omn:partOfInfrastructure <http://fuseco.fokus.fraunhofer.de/about#infrastructure> .
========

Add a custom footer
Add a custom sidebar

Clone this wiki locally