Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <116c992e564e351edd0bc5160ae1a115.squirrel@46.19.35.7>
In-Reply-To: 
 <CAPhv5g_X3+0w_0U0_bav0iDOQnGAh0MpwABrhO7KH+4enWA6cQ@mail.gmail.com>
References: <9b2b2807bfd920c20a3bf53d3edd967c.squirrel@46.19.35.7>
    <519FDC5B.9000502@gmail.com>
    <CAPhv5g98ZL116ZpWLayHJeYx6P3dG2H2b1Yq+hwO+vgq_Vku_Q@mail.gmail.com>
    <158DB510-A927-43C3-ADEC-0B2D0501ADB6@luminis.nl>
    <CAPhv5g_X3+0w_0U0_bav0iDOQnGAh0MpwABrhO7KH+4enWA6cQ@mail.gmail.com>
Date: Mon, 27 May 2013 15:28:48 +0200
Subject: Re: Remote service transport system
From: erik@jansman.eu
To: celix-dev@incubator.apache.org
User-Agent: SquirrelMail/1.4.22
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

First of all everyone thank you for the input.

>
>> On May 26, 2013, at 13:04 PM, Pepijn Noltes <pepijnnoltes@gmail.com>
>> wrote:
>>

>>
>
> Thanks Marcel. Then I think creating a  ZeroMQ RSA/transport bundle open
> source project on a different location and keeping Mongoose as default is
> the best solution.
>
This sounds like a logical think to do. I'll just have to figure out how
to move mongoose from the Remote service admin to a new service. I guess
this should be the first step and after having done that add ZeroMQ from
an open-source project.

When making a new service with mongoose I would like to change the remote
service admin to do less. As far as i can see the RSA now handles
everything from creating the endpoint to receiving and processing the
callback from mongoose. I would like to change this to the RSA requesting
a transport service to create a endpoint from an endpoint description if
possible.

The flow of the RSA,a transport service (TS), and a remote service (RS)
would then be:
1: The RSA starts and listens for TS and RS
2: The TS starts. The RSA now knows about the transport service
3: The RS starts, Asks the RSA for an endpoint based on supplied endpoint
description.
4: RSA asks known TS if they are capable of setting up an endpoint with
supplied endpoint description.
5: RSA asks one of the capable TS for an endpoint.
6: TS sets up endpoint.
7: RSA returns to RS with a status if the endpoint is created or not.
8: The TS now listens for incoming requests and calls the callback
function supplied by the endpoint description and thus directly the RS.
9: RS handles the function call and returns to the TS.

I think this is a logical way to handle the transport with remote
services. I do have some questions on what to do when the RSA stops.
1: Should all the TS and RS stop as well or can they stay online?
2: What should happen to an RS if the TS it uses stops? Stop the TS as
well or ask the RSA for a new TS if possible?

Regards,

Erik Jansman