Home » Archived » Riena » How does Riena cope will remote interface version differences
| How does Riena cope will remote interface version differences [message #14051] |
Wed, 08 October 2008 09:53  |
|
Hi,
This may be an unfair question to ask here as the ultimate answer lies
in the underlying remoting technology, which in this case is Hessian.
But I will give it try anyway in the hopes that even if you are not
able to address it, you can point me to resources that will enlighten
me.
Versioning of remote interfaces always become an issue when one has
client and servers that may be of differing versions. Does
Riena/Hessian provide a flexible way to cope with this?
Thanks,
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: How does Riena cope will remote interface version differences [message #14085 is a reply to message #14051] |
Wed, 08 October 2008 12:28  |
 Christian Campo
Messages: 597
Registered: July 2009 |
Senior Member |
|
|
Hi,
we have been building client server apps for some years now and always felt that different versions on client and server
dont work well. You not only would have to sync the interfaces but also all parameters and return values. So for our use
cases we force the people to upgrade their client if the server has a new version.
Hessian itself is pretty robust for changes. While Java Serialization dependends on some SerialId which can change
pretty quickly (unless you specify it explicitly), Hessian is happy if it can set all the field values in the target object.
But if, as an example, you add a field to the return value on the server, the Hessian deserializer will be quite
surprised (->exception) if that field does not exist there. I am not aware anyway of a good strategy for cases where
value objects (objects in parameters or returnvalues) change their structure.
What would you expect to happen if a field is added ? Do you know concepts with a better strategy ?
christian
Joel Rosi-Schwartz schrieb:
> Hi,
>
> This may be an unfair question to ask here as the ultimate answer lies
> in the underlying remoting technology, which in this case is Hessian.
> But I will give it try anyway in the hopes that even if you are not able
> to address it, you can point me to resources that will enlighten me.
>
> Versioning of remote interfaces always become an issue when one has
> client and servers that may be of differing versions. Does Riena/Hessian
> provide a flexible way to cope with this?
>
> Thanks,
> Joel
|
|
|
| Re: How does Riena cope will remote interface version differences [message #14119 is a reply to message #14085] |
Wed, 08 October 2008 13:09 |
|
On 2008-10-08 13:28:39 +0100, Christian Campo
<christian.campo@compeople.de> said:
> Hi,
>
> we have been building client server apps for some years now and always
> felt that different versions on client and server dont work well. You
> not only would have to sync the interfaces but also all parameters and
> return values. So for our use cases we force the people to upgrade
> their client if the server has a new version.
So have I, that's why I ask the question :-) I agree that in an ideal
world the simple solution is to dictate a release match. In practice
for ORMF this is overly restrictive and not realistic if the framework
is to be successful. Think something like CVS, HTTP, SMTP, NNP, etc.
Would it be acceptable to require an explicit client/server match up?
As soon as one of the CVS servers I use upgraded I would have to
upgrade my client and loose the ability to connect to all of the others
:-(
> Hessian itself is pretty robust for changes. While Java Serialization
> dependends on some SerialId which can change pretty quickly (unless you
> specify it explicitly), Hessian is happy if it can set all the field
> values in the target object.
That's good. So I imagine that since the actual service is not known
nor instantiated on the client side the serialisation problem does not
come into play. Note I only use simple types and XML for my parameters
and return types.
> But if, as an example, you add a field to the return value on the
> server, the Hessian deserializer will be quite surprised (->exception)
> if that field does not exist there. I am not aware anyway of a good
> strategy for cases where value objects (objects in parameters or
> returnvalues) change their structure.
>
> What would you expect to happen if a field is added ? Do you know
> concepts with a better strategy ?
That is not necessarily an issue for us as long as we can ADD new
methods to the interface. I shield the interface by passing xml (as
strings) for those parameters that tend to change. This insulates the
older client. The server has to be prepared to be backwards compatible.
Handling newer clients on old server is trickier as the client has to
be wired to adapt (sometimes) when talking to older servers. This all
takes forethought and planning.
The point is that as long as Hessian is liberal about the addition of
new methods to interface, i.e. that the number of methods do not always
match between the server and client, with the caveat, of course, that
whatever method is called by client actually exists with the same
parameters and return type, then the rest is my problem.
Thanks,
Joel
>
> christian
>
> Joel Rosi-Schwartz schrieb:
>> Hi,
>>
>> This may be an unfair question to ask here as the ultimate answer lies
>> in the underlying remoting technology, which in this case is Hessian.
>> But I will give it try anyway in the hopes that even if you are not
>> able to address it, you can point me to resources that will enlighten
>> me.
>>
>> Versioning of remote interfaces always become an issue when one has
>> client and servers that may be of differing versions. Does
>> Riena/Hessian provide a flexible way to cope with this?
>>
>> Thanks,
>> 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: How does Riena cope will remote interface version differences [message #14136 is a reply to message #14119] |
Wed, 08 October 2008 16:35 |
Christian Campo
Messages: 597
Registered: July 2009 |
Senior Member |
|
|
Joel,
so that should work for you. One word of caution: Remote Services in general I believe and Hessian specifically does not
work with multiple methods with the same name but different parameter types. At least that used to be a problem when
tried to to have 2 methods with the same name, same number of parameters but slightly different type. That does not work
that well with remoting. Not sure if that has changed (since I use Hessian now for over 4 years) but in general I
recommend that you keep method names for an interface unique by itself.
Adding methods is no problem. Hessian gets through the wire a method name and searches for it by Reflection. It doesnt
matter how many methods the interface has....
christian
Joel Rosi-Schwartz schrieb:
> On 2008-10-08 13:28:39 +0100, Christian Campo
> <christian.campo@compeople.de> said:
>
>> Hi,
>>
>> we have been building client server apps for some years now and always
>> felt that different versions on client and server dont work well. You
>> not only would have to sync the interfaces but also all parameters and
>> return values. So for our use cases we force the people to upgrade
>> their client if the server has a new version.
>
> So have I, that's why I ask the question :-) I agree that in an ideal
> world the simple solution is to dictate a release match. In practice for
> ORMF this is overly restrictive and not realistic if the framework is to
> be successful. Think something like CVS, HTTP, SMTP, NNP, etc. Would it
> be acceptable to require an explicit client/server match up? As soon as
> one of the CVS servers I use upgraded I would have to upgrade my client
> and loose the ability to connect to all of the others :-(
>
>> Hessian itself is pretty robust for changes. While Java Serialization
>> dependends on some SerialId which can change pretty quickly (unless
>> you specify it explicitly), Hessian is happy if it can set all the
>> field values in the target object.
>
> That's good. So I imagine that since the actual service is not known nor
> instantiated on the client side the serialisation problem does not come
> into play. Note I only use simple types and XML for my parameters and
> return types.
>
>> But if, as an example, you add a field to the return value on the
>> server, the Hessian deserializer will be quite surprised (->exception)
>> if that field does not exist there. I am not aware anyway of a good
>> strategy for cases where value objects (objects in parameters or
>> returnvalues) change their structure.
>>
>> What would you expect to happen if a field is added ? Do you know
>> concepts with a better strategy ?
>
> That is not necessarily an issue for us as long as we can ADD new
> methods to the interface. I shield the interface by passing xml (as
> strings) for those parameters that tend to change. This insulates the
> older client. The server has to be prepared to be backwards compatible.
> Handling newer clients on old server is trickier as the client has to be
> wired to adapt (sometimes) when talking to older servers. This all takes
> forethought and planning.
>
> The point is that as long as Hessian is liberal about the addition of
> new methods to interface, i.e. that the number of methods do not always
> match between the server and client, with the caveat, of course, that
> whatever method is called by client actually exists with the same
> parameters and return type, then the rest is my problem.
>
> Thanks,
> Joel
>
>>
>> christian
>>
>> Joel Rosi-Schwartz schrieb:
>>> Hi,
>>>
>>> This may be an unfair question to ask here as the ultimate answer
>>> lies in the underlying remoting technology, which in this case is
>>> Hessian. But I will give it try anyway in the hopes that even if you
>>> are not able to address it, you can point me to resources that will
>>> enlighten me.
>>>
>>> Versioning of remote interfaces always become an issue when one has
>>> client and servers that may be of differing versions. Does
>>> Riena/Hessian provide a flexible way to cope with this?
>>>
>>> Thanks,
>>> Joel
>
>
|
|
|
| Re: How does Riena cope will remote interface version differences [message #14153 is a reply to message #14136] |
Wed, 08 October 2008 17:25 |
|
Thanks for mentioning that on duplicate methods. I know that is true
for JAX-WS but I have not got far enough to worry about that with
Hessian. It is an annoyance, but manageable.
Have a good night :-)
Joel
On 2008-10-08 17:35:39 +0100, Christian Campo
<christian.campo@compeople.de> said:
> Joel,
>
> so that should work for you. One word of caution: Remote Services in
> general I believe and Hessian specifically does not work with multiple
> methods with the same name but different parameter types. At least that
> used to be a problem when tried to to have 2 methods with the same
> name, same number of parameters but slightly different type. That does
> not work that well with remoting. Not sure if that has changed (since I
> use Hessian now for over 4 years) but in general I recommend that you
> keep method names for an interface unique by itself.
>
> Adding methods is no problem. Hessian gets through the wire a method
> name and searches for it by Reflection. It doesnt matter how many
> methods the interface has....
>
> christian
>
>
> Joel Rosi-Schwartz schrieb:
>> On 2008-10-08 13:28:39 +0100, Christian Campo
>> <christian.campo@compeople.de> said:
>>
>>> Hi,
>>>
>>> we have been building client server apps for some years now and always
>>> felt that different versions on client and server dont work well. You
>>> not only would have to sync the interfaces but also all parameters and
>>> return values. So for our use cases we force the people to upgrade
>>> their client if the server has a new version.
>>
>> So have I, that's why I ask the question :-) I agree that in an ideal
>> world the simple solution is to dictate a release match. In practice
>> for ORMF this is overly restrictive and not realistic if the framework
>> is to be successful. Think something like CVS, HTTP, SMTP, NNP, etc.
>> Would it be acceptable to require an explicit client/server match up?
>> As soon as one of the CVS servers I use upgraded I would have to
>> upgrade my client and loose the ability to connect to all of the others
>> :-(
>>
>>> Hessian itself is pretty robust for changes. While Java Serialization
>>> dependends on some SerialId which can change pretty quickly (unless you
>>> specify it explicitly), Hessian is happy if it can set all the field
>>> values in the target object.
>>
>> That's good. So I imagine that since the actual service is not known
>> nor instantiated on the client side the serialisation problem does not
>> come into play. Note I only use simple types and XML for my parameters
>> and return types.
>>
>>> But if, as an example, you add a field to the return value on the
>>> server, the Hessian deserializer will be quite surprised (->exception)
>>> if that field does not exist there. I am not aware anyway of a good
>>> strategy for cases where value objects (objects in parameters or
>>> returnvalues) change their structure.
>>>
>>> What would you expect to happen if a field is added ? Do you know
>>> concepts with a better strategy ?
>>
>> That is not necessarily an issue for us as long as we can ADD new
>> methods to the interface. I shield the interface by passing xml (as
>> strings) for those parameters that tend to change. This insulates the
>> older client. The server has to be prepared to be backwards compatible.
>> Handling newer clients on old server is trickier as the client has to
>> be wired to adapt (sometimes) when talking to older servers. This all
>> takes forethought and planning.
>>
>> The point is that as long as Hessian is liberal about the addition of
>> new methods to interface, i.e. that the number of methods do not always
>> match between the server and client, with the caveat, of course, that
>> whatever method is called by client actually exists with the same
>> parameters and return type, then the rest is my problem.
>>
>> Thanks,
>> Joel
>>
>>>
>>> christian
>>>
>>> Joel Rosi-Schwartz schrieb:
>>>> Hi,
>>>>
>>>> This may be an unfair question to ask here as the ultimate answer lies
>>>> in the underlying remoting technology, which in this case is Hessian.
>>>> But I will give it try anyway in the hopes that even if you are not
>>>> able to address it, you can point me to resources that will enlighten
>>>> me.
>>>>
>>>> Versioning of remote interfaces always become an issue when one has
>>>> client and servers that may be of differing versions. Does
>>>> Riena/Hessian provide a flexible way to cope with this?
>>>>
>>>> Thanks,
>>>> 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: How does Riena cope will remote interface version differences [message #575942 is a reply to message #14051] |
Wed, 08 October 2008 12:28 |
Christian Campo
Messages: 597
Registered: July 2009 |
Senior Member |
|
|
Hi,
we have been building client server apps for some years now and always felt that different versions on client and server
dont work well. You not only would have to sync the interfaces but also all parameters and return values. So for our use
cases we force the people to upgrade their client if the server has a new version.
Hessian itself is pretty robust for changes. While Java Serialization dependends on some SerialId which can change
pretty quickly (unless you specify it explicitly), Hessian is happy if it can set all the field values in the target object.
But if, as an example, you add a field to the return value on the server, the Hessian deserializer will be quite
surprised (->exception) if that field does not exist there. I am not aware anyway of a good strategy for cases where
value objects (objects in parameters or returnvalues) change their structure.
What would you expect to happen if a field is added ? Do you know concepts with a better strategy ?
christian
Joel Rosi-Schwartz schrieb:
> Hi,
>
> This may be an unfair question to ask here as the ultimate answer lies
> in the underlying remoting technology, which in this case is Hessian.
> But I will give it try anyway in the hopes that even if you are not able
> to address it, you can point me to resources that will enlighten me.
>
> Versioning of remote interfaces always become an issue when one has
> client and servers that may be of differing versions. Does Riena/Hessian
> provide a flexible way to cope with this?
>
> Thanks,
> Joel
|
|
|
| Re: How does Riena cope will remote interface version differences [message #576004 is a reply to message #14085] |
Wed, 08 October 2008 13:09 |
|
On 2008-10-08 13:28:39 +0100, Christian Campo
<christian.campo@compeople.de> said:
> Hi,
>
> we have been building client server apps for some years now and always
> felt that different versions on client and server dont work well. You
> not only would have to sync the interfaces but also all parameters and
> return values. So for our use cases we force the people to upgrade
> their client if the server has a new version.
So have I, that's why I ask the question :-) I agree that in an ideal
world the simple solution is to dictate a release match. In practice
for ORMF this is overly restrictive and not realistic if the framework
is to be successful. Think something like CVS, HTTP, SMTP, NNP, etc.
Would it be acceptable to require an explicit client/server match up?
As soon as one of the CVS servers I use upgraded I would have to
upgrade my client and loose the ability to connect to all of the others
:-(
> Hessian itself is pretty robust for changes. While Java Serialization
> dependends on some SerialId which can change pretty quickly (unless you
> specify it explicitly), Hessian is happy if it can set all the field
> values in the target object.
That's good. So I imagine that since the actual service is not known
nor instantiated on the client side the serialisation problem does not
come into play. Note I only use simple types and XML for my parameters
and return types.
> But if, as an example, you add a field to the return value on the
> server, the Hessian deserializer will be quite surprised (->exception)
> if that field does not exist there. I am not aware anyway of a good
> strategy for cases where value objects (objects in parameters or
> returnvalues) change their structure.
>
> What would you expect to happen if a field is added ? Do you know
> concepts with a better strategy ?
That is not necessarily an issue for us as long as we can ADD new
methods to the interface. I shield the interface by passing xml (as
strings) for those parameters that tend to change. This insulates the
older client. The server has to be prepared to be backwards compatible.
Handling newer clients on old server is trickier as the client has to
be wired to adapt (sometimes) when talking to older servers. This all
takes forethought and planning.
The point is that as long as Hessian is liberal about the addition of
new methods to interface, i.e. that the number of methods do not always
match between the server and client, with the caveat, of course, that
whatever method is called by client actually exists with the same
parameters and return type, then the rest is my problem.
Thanks,
Joel
>
> christian
>
> Joel Rosi-Schwartz schrieb:
>> Hi,
>>
>> This may be an unfair question to ask here as the ultimate answer lies
>> in the underlying remoting technology, which in this case is Hessian.
>> But I will give it try anyway in the hopes that even if you are not
>> able to address it, you can point me to resources that will enlighten
>> me.
>>
>> Versioning of remote interfaces always become an issue when one has
>> client and servers that may be of differing versions. Does
>> Riena/Hessian provide a flexible way to cope with this?
>>
>> Thanks,
>> 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: How does Riena cope will remote interface version differences [message #576031 is a reply to message #14119] |
Wed, 08 October 2008 16:35 |
Christian Campo
Messages: 597
Registered: July 2009 |
Senior Member |
|
|
Joel,
so that should work for you. One word of caution: Remote Services in general I believe and Hessian specifically does not
work with multiple methods with the same name but different parameter types. At least that used to be a problem when
tried to to have 2 methods with the same name, same number of parameters but slightly different type. That does not work
that well with remoting. Not sure if that has changed (since I use Hessian now for over 4 years) but in general I
recommend that you keep method names for an interface unique by itself.
Adding methods is no problem. Hessian gets through the wire a method name and searches for it by Reflection. It doesnt
matter how many methods the interface has....
christian
Joel Rosi-Schwartz schrieb:
> On 2008-10-08 13:28:39 +0100, Christian Campo
> <christian.campo@compeople.de> said:
>
>> Hi,
>>
>> we have been building client server apps for some years now and always
>> felt that different versions on client and server dont work well. You
>> not only would have to sync the interfaces but also all parameters and
>> return values. So for our use cases we force the people to upgrade
>> their client if the server has a new version.
>
> So have I, that's why I ask the question :-) I agree that in an ideal
> world the simple solution is to dictate a release match. In practice for
> ORMF this is overly restrictive and not realistic if the framework is to
> be successful. Think something like CVS, HTTP, SMTP, NNP, etc. Would it
> be acceptable to require an explicit client/server match up? As soon as
> one of the CVS servers I use upgraded I would have to upgrade my client
> and loose the ability to connect to all of the others :-(
>
>> Hessian itself is pretty robust for changes. While Java Serialization
>> dependends on some SerialId which can change pretty quickly (unless
>> you specify it explicitly), Hessian is happy if it can set all the
>> field values in the target object.
>
> That's good. So I imagine that since the actual service is not known nor
> instantiated on the client side the serialisation problem does not come
> into play. Note I only use simple types and XML for my parameters and
> return types.
>
>> But if, as an example, you add a field to the return value on the
>> server, the Hessian deserializer will be quite surprised (->exception)
>> if that field does not exist there. I am not aware anyway of a good
>> strategy for cases where value objects (objects in parameters or
>> returnvalues) change their structure.
>>
>> What would you expect to happen if a field is added ? Do you know
>> concepts with a better strategy ?
>
> That is not necessarily an issue for us as long as we can ADD new
> methods to the interface. I shield the interface by passing xml (as
> strings) for those parameters that tend to change. This insulates the
> older client. The server has to be prepared to be backwards compatible.
> Handling newer clients on old server is trickier as the client has to be
> wired to adapt (sometimes) when talking to older servers. This all takes
> forethought and planning.
>
> The point is that as long as Hessian is liberal about the addition of
> new methods to interface, i.e. that the number of methods do not always
> match between the server and client, with the caveat, of course, that
> whatever method is called by client actually exists with the same
> parameters and return type, then the rest is my problem.
>
> Thanks,
> Joel
>
>>
>> christian
>>
>> Joel Rosi-Schwartz schrieb:
>>> Hi,
>>>
>>> This may be an unfair question to ask here as the ultimate answer
>>> lies in the underlying remoting technology, which in this case is
>>> Hessian. But I will give it try anyway in the hopes that even if you
>>> are not able to address it, you can point me to resources that will
>>> enlighten me.
>>>
>>> Versioning of remote interfaces always become an issue when one has
>>> client and servers that may be of differing versions. Does
>>> Riena/Hessian provide a flexible way to cope with this?
>>>
>>> Thanks,
>>> Joel
>
>
|
|
|
| Re: How does Riena cope will remote interface version differences [message #576051 is a reply to message #14136] |
Wed, 08 October 2008 17:25 |
|
Thanks for mentioning that on duplicate methods. I know that is true
for JAX-WS but I have not got far enough to worry about that with
Hessian. It is an annoyance, but manageable.
Have a good night :-)
Joel
On 2008-10-08 17:35:39 +0100, Christian Campo
<christian.campo@compeople.de> said:
> Joel,
>
> so that should work for you. One word of caution: Remote Services in
> general I believe and Hessian specifically does not work with multiple
> methods with the same name but different parameter types. At least that
> used to be a problem when tried to to have 2 methods with the same
> name, same number of parameters but slightly different type. That does
> not work that well with remoting. Not sure if that has changed (since I
> use Hessian now for over 4 years) but in general I recommend that you
> keep method names for an interface unique by itself.
>
> Adding methods is no problem. Hessian gets through the wire a method
> name and searches for it by Reflection. It doesnt matter how many
> methods the interface has....
>
> christian
>
>
> Joel Rosi-Schwartz schrieb:
>> On 2008-10-08 13:28:39 +0100, Christian Campo
>> <christian.campo@compeople.de> said:
>>
>>> Hi,
>>>
>>> we have been building client server apps for some years now and always
>>> felt that different versions on client and server dont work well. You
>>> not only would have to sync the interfaces but also all parameters and
>>> return values. So for our use cases we force the people to upgrade
>>> their client if the server has a new version.
>>
>> So have I, that's why I ask the question :-) I agree that in an ideal
>> world the simple solution is to dictate a release match. In practice
>> for ORMF this is overly restrictive and not realistic if the framework
>> is to be successful. Think something like CVS, HTTP, SMTP, NNP, etc.
>> Would it be acceptable to require an explicit client/server match up?
>> As soon as one of the CVS servers I use upgraded I would have to
>> upgrade my client and loose the ability to connect to all of the others
>> :-(
>>
>>> Hessian itself is pretty robust for changes. While Java Serialization
>>> dependends on some SerialId which can change pretty quickly (unless you
>>> specify it explicitly), Hessian is happy if it can set all the field
>>> values in the target object.
>>
>> That's good. So I imagine that since the actual service is not known
>> nor instantiated on the client side the serialisation problem does not
>> come into play. Note I only use simple types and XML for my parameters
>> and return types.
>>
>>> But if, as an example, you add a field to the return value on the
>>> server, the Hessian deserializer will be quite surprised (->exception)
>>> if that field does not exist there. I am not aware anyway of a good
>>> strategy for cases where value objects (objects in parameters or
>>> returnvalues) change their structure.
>>>
>>> What would you expect to happen if a field is added ? Do you know
>>> concepts with a better strategy ?
>>
>> That is not necessarily an issue for us as long as we can ADD new
>> methods to the interface. I shield the interface by passing xml (as
>> strings) for those parameters that tend to change. This insulates the
>> older client. The server has to be prepared to be backwards compatible.
>> Handling newer clients on old server is trickier as the client has to
>> be wired to adapt (sometimes) when talking to older servers. This all
>> takes forethought and planning.
>>
>> The point is that as long as Hessian is liberal about the addition of
>> new methods to interface, i.e. that the number of methods do not always
>> match between the server and client, with the caveat, of course, that
>> whatever method is called by client actually exists with the same
>> parameters and return type, then the rest is my problem.
>>
>> Thanks,
>> Joel
>>
>>>
>>> christian
>>>
>>> Joel Rosi-Schwartz schrieb:
>>>> Hi,
>>>>
>>>> This may be an unfair question to ask here as the ultimate answer lies
>>>> in the underlying remoting technology, which in this case is Hessian.
>>>> But I will give it try anyway in the hopes that even if you are not
>>>> able to address it, you can point me to resources that will enlighten
>>>> me.
>>>>
>>>> Versioning of remote interfaces always become an issue when one has
>>>> client and servers that may be of differing versions. Does
>>>> Riena/Hessian provide a flexible way to cope with this?
>>>>
>>>> Thanks,
>>>> 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/]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
Goto Forum:
Current Time: Sat Nov 09 01:39:58 GMT 2024
Powered by FUDForum. Page generated in 0.03948 seconds |
] 
Search
Help
Register
Login
Home
