Gregg Wonderly wrote:
> Mark Baker wrote:
>>
>> On 11/21/06, Anil John <[EMAIL PROTECTED] <mailto:aniltj%40gmail.com>> wrote:
>>  > Won't happen (..until something better comes along. And no, it has not
>>  > yet). Because however true the problems with WS-* are, it is "good
>>  > enough" given the current state of technology, and better than what
>>  > existed previously.
>>
>> No, it's not better at all, it's significantly worse than at least one
>> alternative.
>>
>> Part of the problem is that most people don't consider the Web to be
>> part of "what existed previously". While WS-* may have advantages
>> over the likes of CORBA, DCOM, and RMI, it is demonstrably inferior to
>> the Web as a platform for network based services (for many of the
>> reasons we've been over before here, in particular loose coupling).
> 
> I really find it interesting that people continue to bash RMI as something to 
> put in the same space as CORBA and DCOM.  Clearly people have used RMI in 
> much 
> different/worse systems than I.  Based on some of the arguments we've had 
> here, 
> it seems that the biggest problems people have had with RMI are based on 
> misunderstandings of the technology and hence misuse of the features.  A lot 
> of 
> people seem to have just made every object extends UnicastRemoteObject, or 
> used 
> that class to export everything, instead of looking closer and granularity.  
> The 
> other falling off point is serialVersionUID and versioning overall.
> 

There's one other issue which is that RMI, in many circles translates to
RMI-IIOP _not_ RMI-JRMP.

These leads to all sorts of confusion given that RMI-IIOP is horribly
botched typically with no code-downloading support etc.

Basically, most people who _think_ they've been using RMI have been
using the hobbled, offspring of original RMI (JRMP).

> One of the key things about the RMI programming model is that version #1, had 
> many limitations.  Version #2 is present in the Jini platform, created by the 
> engineers who were part of the CORBA system design and development as well as 
> RMI. So, they know all of the issues that people waved in their faces over 
> the 
> years.
> 
> The predominate arguments against RMI are always based on "granularity".  
> With 
> RMI programming, you can design systems that pass big objects, no objects, 
> small 
> objects, lots of text, or whatever you want.  What Jini gives you in an RMI 
> programming model, is the ability to (with published specs and standards), 
> plug 
> in any endpoint or invocation technology that you need.  Thus, you can take 
> advantage of all the features of the Jini platform while still providing 
> outward 
> interfaces using other technologies such as the web or WS-*.
> 
> CORBA is a invocation layer technology.  DCOM is an operating system specific 
> invocation layer technology.  RMI might be considered an invocation layer 
> technology.  But, it is actually a programming model which includes something 
> much larger and that's mobile code. Jini expands the RMI programming model 
> with 
> more features and provides services that use the underlying technologies to 
> really expand the possibilities.
> 
> Lumping RMI in with CORBA and DCOM, I think, really hides the power of what 
> is 
> available in that programming model.  In particular versioning is greatly 
> easier 
> to deal with when you can exploit mobile code to allow clients to continue to 
> see an old version of the interface while the implementation is actually much 
> different.  Providing this level of flexibility is what makes it possible to 
> grow a service with more features and still maintain backward compatibility.
> 
> Google-Maps is a great example of the use of mobile code for version control. 
>  I 
> have old google-maps which use old versions of their interface.  I haven't 
> had 
> to convert those to the new system because I download mobile javascript code 
> that manages that issue for me.
> 
> At some point, they might retire that support and I'll have to switch.  But, 
> the 
> point is that there's not an instantaneous moment where I have to be 
> compatible 
> just so that they can move on to create a better system.  They can do it 
> continuously.
> 
> Gregg Wonderly
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
> 
> 


Reply via email to