celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
Subject Re: Remote service transport system
Date Tue, 28 May 2013 05:31:16 GMT

> >
> 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.

In the past I started some work on this. If you could give me some time I
can look it up and share. It is not finished, but could give a good
starting point.

> 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.

I am not sure anymore what/how I solved it. But this sounds good.

> 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?

Stopping isn't needed I think, however.. If I am correct, the spec says
that all endpoints are removed if a RSA is stopped. So if stopping implies
this then yes. But if stopping means stopping a bundle then no.

> 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?

Again, I think the spec should be leading here. As far as I know it is
possible to have multiple endpoints for one remote service (based on
configuration types), so asking for a new TS probably doesn't make sense.
If there are multiple ts that can handle the configuration there are
probably already multiple endpoints.

Maybe it is a good idea to see a RSA TS and RS combination conceptually as
one thing. If any of the three is gone, the others might need to "stop" as
well. Stopping in this case is for a TS to remove the endpoints and for the
RS to remove the broker.

This gives:
RSA gone: remove all endpoints and brokers created by that RSA. (there can
be multiple RSA's).

RS gone:
Remove endpoints dependant on the RS. The broker is already gone as it is
part of the RS.

TS gone:
Do nothing. The endpoints are already gone as part of the TS. The broker
might as well be used by another TS, and the RSA might as well have
exported different configuration  types.

Having said that, is a RS only needed if there is a broker? And is the TS
used for other cases? Eg when a new Tcp socket is used for each service? Or
is the RS a service factory for those cases? If so, when the TS is gone,
then the service created by the factory (for the endpoints of the TS)
should be removed as well.

> Regards,
> Erik Jansman

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message