[PATCH] New Services architecture.

Hello.

I would like to purpose a "new" Service Architecture.

The current patch (attached file) add a ServiceInterface base class that inherit the three interfaces (DataFlow, Configuration, and Operation). The Service and ServiceRequester inherit the ServiceInterface.

No new features are implemented, it should do the same thing than before.

The patch compile, but before going further, i would like to have your opinion : is it acceptable ?

The next things i would like to do is to rename Service in ServiceProvider, ServiceInterface in Service.

Then i will try to update the transport implementation to take into account the Service base class.

Next i will try to reimplement connectTo to be able to connect ports, configurations and operations.

Could you give me some advices please ?

Paul.

AttachmentSize
0001-New-service-architecture.patch49.7 KB

[PATCH] New Services architecture.

On Sunday 21 November 2010 15:36:00 paul [dot] chavent [..] ... wrote:
> Hello.
>
> I would like to purpose a "new" Service Architecture.
>
> The current patch (attached file) add a ServiceInterface base class that
> inherit the three interfaces (DataFlow, Configuration, and Operation). The
> Service and ServiceRequester inherit the ServiceInterface.
>
> No new features are implemented, it should do the same thing than before.
>
> The patch compile, but before going further, i would like to have your
> opinion : is it acceptable ?
>
> The next things i would like to do is to rename Service in ServiceProvider,
> ServiceInterface in Service.
>
> Then i will try to update the transport implementation to take into account
> the Service base class.
>
> Next i will try to reimplement connectTo to be able to connect ports,
> configurations and operations.
>
> Could you give me some advices please ?

The first important issue is that we won't do any renames of classes in the
RTT:: namespace. It's just not an option for the next year(s). So please keep
that in mind. We can add classes though, preferably in the sub-namespaces of
'RTT'.

I've had a sneak-preview to the document you created of your use case, and it
got me worried. The amount of code we need to setup two or three components is
daunting. The whole idea should be that writing components is 'cheap' and as
such setting up an object-interface framework of implementations behind a
single component shouldn't be a thing you want to do. I'm pointing at a
problem with the RTT, not at a problem in your design. In a way, you're
reproducing in C++ what orogen is generating for you (partly, because orogen
only does data flow ports and not services!). If you already have an interface
you want to provide/require, why don't we extend one of these code generators
to generate that code for you ?

I don't claim that the current serviceprovider/requester scheme works/looks
good. I certainly welcome improvements. But this is not something we will
merge on master in the coming months.

Peter

[PATCH] New Services architecture.

Hello Peter

Peter Soetens wrote:
> On Sunday 21 November 2010 15:36:00 paul [dot] chavent [..] ... wrote:
>> Hello.
>>
>> I would like to purpose a "new" Service Architecture.
>>
>> The current patch (attached file) add a ServiceInterface base class that
>> inherit the three interfaces (DataFlow, Configuration, and Operation). The
>> Service and ServiceRequester inherit the ServiceInterface.
>>
>> No new features are implemented, it should do the same thing than before.
>>
>> The patch compile, but before going further, i would like to have your
>> opinion : is it acceptable ?
>>
>> The next things i would like to do is to rename Service in ServiceProvider,
>> ServiceInterface in Service.
>>
>> Then i will try to update the transport implementation to take into account
>> the Service base class.
>>
>> Next i will try to reimplement connectTo to be able to connect ports,
>> configurations and operations.
>>
>> Could you give me some advices please ?
>
> The first important issue is that we won't do any renames of classes in the
> RTT:: namespace. It's just not an option for the next year(s). So please keep
> that in mind. We can add classes though, preferably in the sub-namespaces of
> 'RTT'.

That's not an issue. I will keep the current naming convention.

>
> I've had a sneak-preview to the document you created of your use case, and it

Yes there has been a problem with the size of the message, so, for the document, see here http://paul.chavent.free.fr/orocos/Camera.pdf

> got me worried. The amount of code we need to setup two or three components is
> daunting. The whole idea should be that writing components is 'cheap' and as
> such setting up an object-interface framework of implementations behind a
> single component shouldn't be a thing you want to do. I'm pointing at a
> problem with the RTT, not at a problem in your design. In a way, you're
> reproducing in C++ what orogen is generating for you (partly, because orogen
> only does data flow ports and not services!).

I'am a bit afraid if you tell me that we should use orogen to generate boring code, in order to balance a lack of programming features for humans.

Orogen should avoid the programming of recurrent patterns, not allow to generate workarounds.

> If you already have an interface
> you want to provide/require, why don't we extend one of these code generators
> to generate that code for you ?

I'am not very familiar with orogen, and i don't want to use code generator for now.
But i prefer to improve the API instead of making black magic with code generation.

>
>
> I don't claim that the current serviceprovider/requester scheme works/looks
> good. I certainly welcome improvements. But this is not something we will
> merge on master in the coming months.
>

OK. So, i will use my patch for personal use and inform you of its evolution (and there will certainly...).

> Peter

Thank you for your review.

Paul.

[PATCH] New Services architecture.

On Mon, 22 Nov 2010, Paul Chavent wrote:

> Hello Peter
>
> Peter Soetens wrote:
>> On Sunday 21 November 2010 15:36:00 paul [dot] chavent [..] ... wrote:
>>> Hello.
>>>
>>> I would like to purpose a "new" Service Architecture.
>>>
>>> The current patch (attached file) add a ServiceInterface base class that
>>> inherit the three interfaces (DataFlow, Configuration, and Operation). The
>>> Service and ServiceRequester inherit the ServiceInterface.
>>>
>>> No new features are implemented, it should do the same thing than before.
>>>
>>> The patch compile, but before going further, i would like to have your
>>> opinion : is it acceptable ?
>>>
>>> The next things i would like to do is to rename Service in ServiceProvider,
>>> ServiceInterface in Service.
>>>
>>> Then i will try to update the transport implementation to take into account
>>> the Service base class.
>>>
>>> Next i will try to reimplement connectTo to be able to connect ports,
>>> configurations and operations.
>>>
>>> Could you give me some advices please ?
>>
>> The first important issue is that we won't do any renames of classes in the
>> RTT:: namespace. It's just not an option for the next year(s). So please keep
>> that in mind. We can add classes though, preferably in the sub-namespaces of
>> 'RTT'.
>
> That's not an issue. I will keep the current naming convention.
>
>>
>> I've had a sneak-preview to the document you created of your use case, and it
>
> Yes there has been a problem with the size of the message, so, for the document, see here http://paul.chavent.free.fr/orocos/Camera.pdf
>
>> got me worried. The amount of code we need to setup two or three components is
>> daunting. The whole idea should be that writing components is 'cheap' and as
>> such setting up an object-interface framework of implementations behind a
>> single component shouldn't be a thing you want to do. I'm pointing at a
>> problem with the RTT, not at a problem in your design. In a way, you're
>> reproducing in C++ what orogen is generating for you (partly, because orogen
>> only does data flow ports and not services!).
>
> I'am a bit afraid if you tell me that we should use orogen to generate boring code, in order to balance a lack of programming features for humans.
>
> Orogen should avoid the programming of recurrent patterns, not allow to generate workarounds.
>
>> If you already have an interface
>> you want to provide/require, why don't we extend one of these code generators
>> to generate that code for you ?
>
> I'am not very familiar with orogen, and i don't want to use code generator for now.
> But i prefer to improve the API instead of making black magic with code generation.
>
There is no reason why code generation should be "black magic"... On the
contrary: if there is a well-defined and understood "model" to generate the
code from, code generation can be a dream to have.

>> I don't claim that the current serviceprovider/requester scheme works/looks
>> good. I certainly welcome improvements. But this is not something we will
>> merge on master in the coming months.
>
> OK. So, i will use my patch for personal use and inform you of its
> evolution (and there will certainly...).

Good luck!

>> Peter
>
> Thank you for your review.
>
> Paul.

Herman

[PATCH] New Services

Quote:
There is no reason why code generation should be "black magic"... On the
contrary: if there is a well-defined and understood "model" to generate the
code from, code generation can be a dream to have.

I agree with that. I agree with Peter that tell me to use code generation for my use case.

But i don't know how to implement my model with the current API. So i don't know which code orogen could generate for doing the job.

Quote:
Good luck!

Thank you :)

[PATCH] New Services architecture.

Quote:
There is no reason why code generation should be "black magic"... On the contrary: if there is a well-defined and understood "model" to generate the code from, code generation can be a dream to have.

I agree with that. I agree with Peter that tell me to use code generation for my use case.

But i don't know how to implement my model with the current API. So i don't know which code orogen could generate for doing the job.

Quote:
Good luck!

Thank you :)

[PATCH] New Services

On Tue, 23 Nov 2010, paul [dot] chavent [..] ... wrote:

>

Quote:
There is no reason why code generation should be "black magic"... On the
> contrary: if there is a well-defined and understood "model" to generate the
> code from, code generation can be a dream to have.

>
> I agree with that. I agree with Peter that tell me to use code generation for my use case.
>
> But i don't know how to implement my model with the current API.

You are putting your finger on one of the weak points of our current code
base: it is not yet ready to support code generation :-( The first steps in
this direction are being set:
- definition of a "component model", that separates Computation,
Communication, Configuration and Coordination, such that appropriate
models and APIs can be refactored to better support code generation.
- making "Eclipse ecore" models for all of the above, in the hope that
we can profit from the large efforts around code generation (and other
useful tools) that the Eclipse ecosystem is providing.

Both efforts are significantly supported by the BRICS project, but will
take another six months or so before we can expect the first visible
results.

> So i don't know which code orogen could generate for doing the job.
>
>

Quote:
Good luck!

>
> Thank you :)

Maybe we can try to do something together to reduce our dependency on luck :-)
I mean, if you have some ideas how we should proceed towards this goal,
please feel free to post them for discussion on this list... The effort
will not lead to usable results within less than six months or so.

Herman

[PATCH] New Services

bruyninc wrote:

The first steps in
this direction are being set:
- definition of a "component model", that separates Computation,
Communication, Configuration and Coordination, such that appropriate
models and APIs can be refactored to better support code generation.
- making "Eclipse ecore" models for all of the above, in the hope that
we can profit from the large efforts around code generation (and other
useful tools) that the Eclipse ecosystem is providing.
...
Both efforts are significantly supported by the BRICS project

You seems to have some lenght of advance on this topic. I will try to read some documentation.

bruyninc wrote:

Maybe we can try to do something together to reduce our dependency on luck :-)
I mean, if you have some ideas how we should proceed towards this goal,
please feel free to post them for discussion on this list... The effort
will not lead to usable results within less than six months or so.

I'am not hurry.

I would like to be involved in the debate of the definition of a "component model".

So... we will meet again ! Ha Ha Ha Ha Ha :)

Re: [PATCH] New Services

bruyninc wrote:
The first steps in this direction are being set: - definition of a "component model", that separates Computation,
   Communication, Configuration and Coordination, such that appropriate
   models and APIs can be refactored to better support code generation.
- making "Eclipse ecore" models for all of the above, in the hope that
   we can profit from the large efforts around code generation (and other
   useful tools) that the Eclipse ecosystem is providing.
... Both efforts are significantly supported by the BRICS project

You seems to have some lenght of advance on this topic. I will try to read some documentation.

bruyninc wrote:
Maybe we can try to do something together to reduce our dependency on luck :-) I mean, if you have some ideas how we should proceed towards this goal, please feel free to post them for discussion on this list... The effort will not lead to usable results within less than six months or so.

I'am not hurry.

I would like to be involved in the debate of the definition of a "component model".

So... we will meet again ! Ha Ha Ha Ha Ha :)

[PATCH] New Services

Hello Paul,

>

bruyninc wrote:

> The first steps in
> this direction are being set:
> - definition of a "component model", that separates Computation,
> Communication, Configuration and Coordination, such that appropriate
> models and APIs can be refactored to better support code generation.
> - making "Eclipse ecore" models for all of the above, in the hope that
> we can profit from the large efforts around code generation (and other
> useful tools) that the Eclipse ecosystem is providing.
> ...
> Both efforts are significantly supported by the BRICS project
>

>
> You seems to have some lenght of advance on this topic. I will try to read some documentation.
>
>
bruyninc wrote:

> Maybe we can try to do something together to reduce our dependency on luck :-)
> I mean, if you have some ideas how we should proceed towards this goal,
> please feel free to post them for discussion on this list... The effort
> will not lead to usable results within less than six months or so.
>

>
> I'am not hurry.
>
> I would like to be involved in the debate of the definition of a "component model".

During the last months we had some very intensive discussions on
that topic. One outcome is the decision to separate the structural
and behavioral part of components also on the "model level".

The current model includes basically an explicit representation of
Components, Composites, Connections, Services, and Properties.

Those primitives are used to achieve the separation of concerns which
Herman mentioned (e.g. separation of the Configuration through
properties), and are found in other well-known component-based frameworks.

It will take more time to materialize the ideas into running code. But,
we should be very soon ready to publish the core ideas in a more
elaborated manner. Stay tuned!

Nico

>
> So... we will meet again ! Ha Ha Ha Ha Ha :)
>

[PATCH] New Services

On Tue, 23 Nov 2010, Nico Hochgeschwender wrote:

>
>
> Hello Paul,
>
>>

bruyninc wrote:

>> The first steps in
>> this direction are being set:
>> - definition of a "component model", that separates Computation,
>> Communication, Configuration and Coordination, such that appropriate
>> models and APIs can be refactored to better support code generation.
>> - making "Eclipse ecore" models for all of the above, in the hope that
>> we can profit from the large efforts around code generation (and other
>> useful tools) that the Eclipse ecosystem is providing.
>> ...
>> Both efforts are significantly supported by the BRICS project
>>

>>
>> You seems to have some lenght of advance on this topic. I will try to read some documentation.
>>
>>
bruyninc wrote:

>> Maybe we can try to do something together to reduce our dependency on luck :-)
>> I mean, if you have some ideas how we should proceed towards this goal,
>> please feel free to post them for discussion on this list... The effort
>> will not lead to usable results within less than six months or so.
>>

>>
>> I'am not hurry.
>>
>> I would like to be involved in the debate of the definition of a "component model".
>
> During the last months we had some very intensive discussions on
> that topic. One outcome is the decision to separate the structural
> and behavioral part of components also on the "model level".
>
> The current model includes basically an explicit representation of
> Components, Composites, Connections, Services, and Properties.

Which is the "SCA" model mentioned in my previous post.

> Those primitives are used to achieve the separation of concerns which
> Herman mentioned (e.g. separation of the Configuration through
> properties), and are found in other well-known component-based frameworks.
>
> It will take more time to materialize the ideas into running code. But,
> we should be very soon ready to publish the core ideas in a more
> elaborated manner. Stay tuned!
>
> Nico
>
>>
>> So... we will meet again ! Ha Ha Ha Ha Ha :)

FYI: Nico is the "task force leader" of this activity in the BRICS project.

Herman

[PATCH] New Services

On Tue, 23 Nov 2010, paul [dot] chavent [..] ... wrote:

>

bruyninc wrote:

> The first steps in
> this direction are being set:
> - definition of a "component model", that separates Computation,
> Communication, Configuration and Coordination, such that appropriate
> models and APIs can be refactored to better support code generation.
> - making "Eclipse ecore" models for all of the above, in the hope that
> we can profit from the large efforts around code generation (and other
> useful tools) that the Eclipse ecosystem is providing.
> ...
> Both efforts are significantly supported by the BRICS project
>

>
> You seems to have some lenght of advance on this topic. I will try to
> read some documentation.

Don't let appearance fool you! I have learned most of the _problems_ and
_challenges_ of code generation, but not yet really useful _solutions_ :-(

>

bruyninc wrote:

> Maybe we can try to do something together to reduce our dependency on luck :-)
> I mean, if you have some ideas how we should proceed towards this goal,
> please feel free to post them for discussion on this list... The effort
> will not lead to usable results within less than six months or so.
>

>
> I'am not hurry.
>
> I would like to be involved in the debate of the definition of a "component model".
Our current views on the "component model" are:
- there is a _structural_ part, for which SCA
<http://en.wikipedia.org/wiki/Service_component_architecture>
seems to be a good candidate
- there is a _communication_ part, for which we still have not a perfect
solution, but SmartSoft <http://smart-robotics.sourceforge.net/> is going
in the right direction.
- there are two _behavioural_ parts, a _discrete_ one (modelled by finite
state machines), and a _continuous_ one (modelled, e.g., by Modelica).
We are now trying to find out how to best interconnect all these things, in
a simple but complete way :-) In the same time, this would lead to a
refactoring of RTT.

>
> So... we will meet again ! Ha Ha Ha Ha Ha :)

Herman

[PATCH] New Services architecture.

On Sun, 21 Nov 2010, paul [dot] chavent [..] ... wrote:

> Hello.
>
> I would like to purpose a "new" Service Architecture.
>
> The current patch (attached file) add a ServiceInterface base class that inherit the three interfaces (DataFlow, Configuration, and Operation).
> The Service and ServiceRequester inherit the ServiceInterface.
>
> No new features are implemented, it should do the same thing than before.
>
> The patch compile, but before going further, i would like to have your opinion : is it acceptable ?
>
> The next things i would like to do is to rename Service in ServiceProvider, ServiceInterface in Service.
>
> Then i will try to update the transport implementation to take into account the Service base class.
>
> Next i will try to reimplement connectTo to be able to connect ports, configurations and operations.
>
> Could you give me some advices please ?
>
> Paul.

Thanks for your efforts! I think they are targeting a useful goal, but what
I currently miss is an overview of the reasons _why_ you make the
suggestions that you make. What exactly are the advantages that you are
providing for developers, for users? I know that earlier postings in this
thread contained already bits and pieces of the overview, but having it all
together as one document would help me a lot in evaluating the strategic
value of the contribution.

Best regards,

Herman

Hi Herman.I wrote a draft

Hi Herman.

I wrote a draft that explain what are my intentions (i join the pdf).

I have implemented this design in RTT1.X but it was not very easy to write and maintain. So I try to suggest what it could be under 2.X.

I'm open to comments and discussions.

Thanks for your reading.

Paul.

[PATCH] New Services architecture.

Hello.

I would like to purpose a "new" Service Architecture.

The current patch (attached file) add a ServiceInterface base class that inherit the three interfaces (DataFlow, Configuration, and Operation).
The Service and ServiceRequester inherit the ServiceInterface.

No new features are implemented, it should do the same thing than before.

The patch compile, but before going further, i would like to have your opinion : is it acceptable ?

The next things i would like to do is to rename Service in ServiceProvider, ServiceInterface in Service.

Then i will try to update the transport implementation to take into account the Service base class.

Next i will try to reimplement connectTo to be able to connect ports, configurations and operations.

Could you give me some advices please ?

Paul.