Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » ORMF » Re: Using Riena only for the server/client connectivity
Re: Using Riena only for the server/client connectivity [message #12151] Sun, 21 September 2008 18:52 Go to next message
Joel Rosi-Schwartz is currently offline Joel Rosi-SchwartzFriend
Messages: 624
Registered: July 2009
Location: London. England
Senior Member
Hi Christian,

Thanks for all of the replies :-)

The clean separation is certainly what I expected, but best to make
sure before leaping in. I really thank you folks as you have saved ORMF
(me in particular) quite a bit of work in wiring the base server
infrastructure and remoting. I will certainly look forward to buying
the Riena team a beer at the next EclipseCon or the Summit if we can
make it this autumn.

I actually think that we will be seeing more and more projects using
OSGi servers with remoting capability. I would really encourage the
Riena team to package and "market" this as a separate "product", i.e. a
feature on the update site or packaged zip. The space is waiting to be
filled.

Btw, I am curious as to why you chose Hessian. I am quite content with
the choice, just wondering.

All the best,
Joel

On 2008-09-21 19:23:00 +0100, Christian Campo
<christian.campo@compeople.de> said:

> Hi Joel,
>
> indeed its basic requirement of Riena that you dont have to buy into
> the whole story of Riena if you just like a component of it. So just
> using Riena remote services is ok and should always work. You will only
> need a few bundles and you are ready to go.
>
> We have the same now for the UI part that you should be able to use
> Ridgets without using the navigation concept of Riena or you can embed
> Riena views into RCP applications or vica versa embed RCP views into
> Riena applications.
>
> If anything of that what I promising does not work, its certainly a bug
> and will be treated as such.
>
> let me help if I you need more info
>
> christian
>
>
>
> Joel Rosi-Schwartz schrieb:
>> Hi,
>>
>> Please allow me to introduce myself. My name is Joel and I am one of
>> the leads of the EF ORMF project <http://www.eclipse.org/ormf/>
>>
>> We are in the process of reengineering our architecture with the
>> intention of moving away from a full blow Java 5 EE server (Glassfish)
>> to a lighter weight OSGI infrastructure. Presently the communication
>> between our Eclipse client and the server is Web Services based, so I
>> think that the Riena server may be just what I am looking for in a base
>> architecture.
>>
>> What makes me a little nervous is that the scope of Riena is much
>> broader than ORMF requires. I would like to assure myself that ORMF
>> will not be required to carry a substantial amount of extra baggage is
>> we adopt Riena. So far my limited reading and explorations leads me to
>> believe that Riena is cleanly partitioned so that we should have few
>> issues. I would be very appreciate if someone from the team could
>> confirm my assumptions.
>>
>> All the best,
>> Joel


--
Joel Rosi-Schwartz
Etish Limited [http://www.etish.org]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^...^
/ o,o \ The proud parents of Useme & ORMF
|) ::: (| Open Requirements Management Framework
====w=w==== [http://www.eclipse.org/ormf/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Using Riena only for the server/client connectivity [message #12162 is a reply to message #12151] Mon, 22 September 2008 08:43 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
Registered: July 2009
Senior Member
Hi Joel,

I am glad you like the result. Indeed remote OSGi Services is a growing topic for everyone. Maybe its a good idea to
start to think in of components rather than bundles that are prepackaged. I will give it a thought. Maybe have a
separate feature for each distinct component in Riena. So that people can decide what feature of Riena to use and which
not. I certainly will not only make the complete target platform but also the .zip with the Riena only components
available in M5. (actually I found the M4 version of that zip....I currently uploading it and let you know where it is,
so you can tell me whether that is something you want to have)

In order to start that marketing piece we need to come out of incubator which will hopefully happen end of year. As you
probably know there is also ECF marketing remote services as their piece. So we see how that is going to develop.

We have choosen Hessian quit some time ago (4 years ago) when we needed a fast transport for Java to Java Webservice
calls and where quite dissatisfied with what SOAP could offer. SOAP is universal but overkill if you dont need that
language independant feature that SOAP is good at. Also SOAP is bloated (protocol wise) and damn slow compared to a
binary alternative like Hessian.
Now in the past 4 years I became quite familiar with Hessian and all its internals. So now I know exactly which screw to
turn for any feature that I want to have. So know you can actually transfer large bytes chunks with Remote Services (say
20 MB or more), you can monitor remote service calls as they are going on (literally shows the bytes as they are sent
and received) with the Remote Progress Monitor and I have many more ideas like "server ticks" (showing progress in the
server components to the client even if no data is sent currently), displaying results as they are coming (say you can
show the first line in a table even if the rest is still in the wire).

So I like Hessian and I know my way around and its relativly configuration free (for serializers). Now we just added a
feature to add your own serializer with Extensions if you have to. But normally that is not the case.

lets keep in touch and let us know how you progress
christian


Joel Rosi-Schwartz schrieb:
> Hi Christian,
>
> Thanks for all of the replies :-)
>
> The clean separation is certainly what I expected, but best to make sure
> before leaping in. I really thank you folks as you have saved ORMF (me
> in particular) quite a bit of work in wiring the base server
> infrastructure and remoting. I will certainly look forward to buying the
> Riena team a beer at the next EclipseCon or the Summit if we can make it
> this autumn.
>
> I actually think that we will be seeing more and more projects using
> OSGi servers with remoting capability. I would really encourage the
> Riena team to package and "market" this as a separate "product", i.e. a
> feature on the update site or packaged zip. The space is waiting to be
> filled.
>
> Btw, I am curious as to why you chose Hessian. I am quite content with
> the choice, just wondering.
>
> All the best,
> Joel
>
> On 2008-09-21 19:23:00 +0100, Christian Campo
> <christian.campo@compeople.de> said:
>
>> Hi Joel,
>>
>> indeed its basic requirement of Riena that you dont have to buy into
>> the whole story of Riena if you just like a component of it. So just
>> using Riena remote services is ok and should always work. You will
>> only need a few bundles and you are ready to go.
>>
>> We have the same now for the UI part that you should be able to use
>> Ridgets without using the navigation concept of Riena or you can embed
>> Riena views into RCP applications or vica versa embed RCP views into
>> Riena applications.
>>
>> If anything of that what I promising does not work, its certainly a
>> bug and will be treated as such.
>>
>> let me help if I you need more info
>>
>> christian
>>
>>
>>
>> Joel Rosi-Schwartz schrieb:
>>> Hi,
>>>
>>> Please allow me to introduce myself. My name is Joel and I am one of
>>> the leads of the EF ORMF project <http://www.eclipse.org/ormf/>
>>>
>>> We are in the process of reengineering our architecture with the
>>> intention of moving away from a full blow Java 5 EE server
>>> (Glassfish) to a lighter weight OSGI infrastructure. Presently the
>>> communication between our Eclipse client and the server is Web
>>> Services based, so I think that the Riena server may be just what I
>>> am looking for in a base architecture.
>>>
>>> What makes me a little nervous is that the scope of Riena is much
>>> broader than ORMF requires. I would like to assure myself that ORMF
>>> will not be required to carry a substantial amount of extra baggage
>>> is we adopt Riena. So far my limited reading and explorations leads
>>> me to believe that Riena is cleanly partitioned so that we should
>>> have few issues. I would be very appreciate if someone from the team
>>> could confirm my assumptions.
>>>
>>> All the best,
>>> Joel
>
>
Re: Using Riena only for the server/client connectivity [message #564211 is a reply to message #12151] Mon, 22 September 2008 08:43 Go to previous message
Christian Campo is currently offline Christian CampoFriend
Messages: 590
Registered: July 2009
Senior Member
Hi Joel,

I am glad you like the result. Indeed remote OSGi Services is a growing topic for everyone. Maybe its a good idea to
start to think in of components rather than bundles that are prepackaged. I will give it a thought. Maybe have a
separate feature for each distinct component in Riena. So that people can decide what feature of Riena to use and which
not. I certainly will not only make the complete target platform but also the .zip with the Riena only components
available in M5. (actually I found the M4 version of that zip....I currently uploading it and let you know where it is,
so you can tell me whether that is something you want to have)

In order to start that marketing piece we need to come out of incubator which will hopefully happen end of year. As you
probably know there is also ECF marketing remote services as their piece. So we see how that is going to develop.

We have choosen Hessian quit some time ago (4 years ago) when we needed a fast transport for Java to Java Webservice
calls and where quite dissatisfied with what SOAP could offer. SOAP is universal but overkill if you dont need that
language independant feature that SOAP is good at. Also SOAP is bloated (protocol wise) and damn slow compared to a
binary alternative like Hessian.
Now in the past 4 years I became quite familiar with Hessian and all its internals. So now I know exactly which screw to
turn for any feature that I want to have. So know you can actually transfer large bytes chunks with Remote Services (say
20 MB or more), you can monitor remote service calls as they are going on (literally shows the bytes as they are sent
and received) with the Remote Progress Monitor and I have many more ideas like "server ticks" (showing progress in the
server components to the client even if no data is sent currently), displaying results as they are coming (say you can
show the first line in a table even if the rest is still in the wire).

So I like Hessian and I know my way around and its relativly configuration free (for serializers). Now we just added a
feature to add your own serializer with Extensions if you have to. But normally that is not the case.

lets keep in touch and let us know how you progress
christian


Joel Rosi-Schwartz schrieb:
> Hi Christian,
>
> Thanks for all of the replies :-)
>
> The clean separation is certainly what I expected, but best to make sure
> before leaping in. I really thank you folks as you have saved ORMF (me
> in particular) quite a bit of work in wiring the base server
> infrastructure and remoting. I will certainly look forward to buying the
> Riena team a beer at the next EclipseCon or the Summit if we can make it
> this autumn.
>
> I actually think that we will be seeing more and more projects using
> OSGi servers with remoting capability. I would really encourage the
> Riena team to package and "market" this as a separate "product", i.e. a
> feature on the update site or packaged zip. The space is waiting to be
> filled.
>
> Btw, I am curious as to why you chose Hessian. I am quite content with
> the choice, just wondering.
>
> All the best,
> Joel
>
> On 2008-09-21 19:23:00 +0100, Christian Campo
> <christian.campo@compeople.de> said:
>
>> Hi Joel,
>>
>> indeed its basic requirement of Riena that you dont have to buy into
>> the whole story of Riena if you just like a component of it. So just
>> using Riena remote services is ok and should always work. You will
>> only need a few bundles and you are ready to go.
>>
>> We have the same now for the UI part that you should be able to use
>> Ridgets without using the navigation concept of Riena or you can embed
>> Riena views into RCP applications or vica versa embed RCP views into
>> Riena applications.
>>
>> If anything of that what I promising does not work, its certainly a
>> bug and will be treated as such.
>>
>> let me help if I you need more info
>>
>> christian
>>
>>
>>
>> Joel Rosi-Schwartz schrieb:
>>> Hi,
>>>
>>> Please allow me to introduce myself. My name is Joel and I am one of
>>> the leads of the EF ORMF project <http://www.eclipse.org/ormf/>
>>>
>>> We are in the process of reengineering our architecture with the
>>> intention of moving away from a full blow Java 5 EE server
>>> (Glassfish) to a lighter weight OSGI infrastructure. Presently the
>>> communication between our Eclipse client and the server is Web
>>> Services based, so I think that the Riena server may be just what I
>>> am looking for in a base architecture.
>>>
>>> What makes me a little nervous is that the scope of Riena is much
>>> broader than ORMF requires. I would like to assure myself that ORMF
>>> will not be required to carry a substantial amount of extra baggage
>>> is we adopt Riena. So far my limited reading and explorations leads
>>> me to believe that Riena is cleanly partitioned so that we should
>>> have few issues. I would be very appreciate if someone from the team
>>> could confirm my assumptions.
>>>
>>> All the best,
>>> Joel
>
>
Previous Topic:Re: Using Riena only for the server/client connectivity
Next Topic:How to use ECF for conference calls
Goto Forum:
  


Current Time: Sun Nov 23 09:04:47 GMT 2014

Powered by FUDForum. Page generated in 0.02287 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software