newbie to Distributed computing

[vianyrajnish rajnish]

hi all,

I am a newbie to distributed computing ... I am very passionate about learning this technology.

I know command over core java , with concepts like inheritance, threads, exceptions, jdbc . Also know the concepts of servlets and jsp to an extent.

But i want to learn about distributed computing concepts like rmi, SOAP
or CORBA...

please anybody suggest me the some books and online materials (ebooks), to learn on my own....

Thanks in advance,
vinay rajnish

[Peter Chase]

For CORBA, we like the book Pure CORBA by Bolton. Amazon sell it - search for "Pure CORBA". It's not 100% Java - there's C++ too - but perhaps this is a good thing, as a large part of the appeal of CORBA is that it's not pinned to one language or O/S.

[William Brogden]

You may find this site helpful in exploring Java distributed computing.

Bill

[Pat Farrell]

Once you get up to speed, you can ask what parts of these complex protocols do you really need.

Corba was very popular in the 1993 timeframe, it has fallen from favor in part because of its complexity and difficulty in scaling.

SOAP once upon a time stood for Simple Object Access Protocol, they changed the name, because it is not at all Simple.

RMI used to be fairly heavily used, but I haven't seen it in practice this century expect for specialised uses.

In many cases, the design model of Corba/RMI and similar patterns has been replaced. They use a 'remote invocation' model, where you execute code on a distributed processor as if it was in your JVM. It is simpler, and scales better to use a message passing architecture. Rather than calling a remote object or a method of a remote object, you just pass a message (usually XML) to a remote service, and get the answer back.

Design your message with version numbers, and you can significantly decrease coupling between the local and remote process.

[Peter Chase]

That's rather harsh on the "remote invocation" styles of distributed computing: CORBA and RMI.

Certainly, neither CORBA nor RMI are a good idea for the very "now" applications where large numbers of different types of machine and network interact. Web Services, utilising a well-known data type like XML, are excellent for these applications. They have additional advantages like rarely being troubled by firewalls (as their traffic looks like ordinary Web use).

But not all applications are like that, and people working on the new trendy stuff tend to forget this. If you've got a few or a whole load of machines, on a network that's yours to configure as you like, then RMI (if everything's Java) or CORBA (if not) can still be the right choice. In particular, XML is often a very long-winded way to send data, compared to CORBA/RMIs terseness (born of older, slower networks). This can still matter today.

[Pat Farrell]

Originally posted by Peter Chase:
That's rather harsh on the "remote invocation" styles of distributed computing: CORBA and RMI.

Actually, I held back. I really dislike them. CORBA's big failure IMHO was the lack of location, you had to know where to find stuff, or know how to find the location services.

RMI was easier to use, but it still has the failing of tightly binding your code to the object's versions.

[Yohan Liyanage]

You may also refer to these books:

Java Network Programming and Distributed Computing by David Reilly, Michael Reilly (Addison Wesley) - Good Introductory Text

Once you got a hold of basic Distributed Computing in Java, then you may proceed to learning specific technologies such as Jini, JXTA etc. Following books are suitable for this purpose.

Foundations of Jini 2 Programming - Jan Newmarch (apress)
Java P2P Unleashed (JXTA, Web Services, XML, Jini, Javaspaces and J2EE)- Robert Flenner et al. (Sams)

Good Luck !

[Mr. C Lamont Gilbert]

Originally posted by Pat Farrell:
In many cases, the design model of Corba/RMI and similar patterns has been replaced. They use a 'remote invocation' model, where you execute code on a distributed processor as if it was in your JVM. It is simpler, and scales better to use a message passing architecture. Rather than calling a remote object or a method of a remote object, you just pass a message (usually XML) to a remote service, and get the answer back.

Design your message with version numbers, and you can significantly decrease coupling between the local and remote process.

I do not at all agree with this assessment. Furthermore, what is the difference between passing a message and getting a reply vs. calling a method which returns some data?

[Peter Chase]

The difference is that the Web services method uses cool words like "Web", sometimes in combination with "2.0", and "XML". This alone is clearly worth taking kilobytes to do what could be done in a few bytes

[Pat Farrell]

Originally posted by Mr. C Lamont Gilbert:


I do not at all agree with this assessment. Furthermore, what is the difference between passing a message and getting a reply vs. calling a method which returns some data?

OK, some folks can disagree.

My problem with calling methods is primarily about coupling. Adding a field/parameter happens constantly, and with RMI and most other remote invocation processes, this requires recompilation of the stub code. This makes changing code difficult once you've deployed.

Obviously, with version numbers on messges, it doesn't make it trivial, you can't require fields that are not sent in earlier releases, but at least you can code to make it upward compatible.

I tend to want two versions of upward compatibility and one version of downward compatibility. I never could make that happen with Corba or RMI.

[Peter Chase]

We have CORBA APIs that provide a high degree of backwards compatibility, while mostly still using CORBA style data structures. Care in API design and evolution is required.

If you need to ensure compatible data formats, regardless of the version of the interface on each side of the link, you can use key-value pairs for everything. Unfortunately, that's turning your CORBA or RMI into virtual XML!

Of course, while key-value pair (hierarchical or not) data can always be read at the low level on both sides, you still have to design what happens when data is missing or unexpected. Equally true of XML.

[Pat Farrell]

Originally posted by Peter Chase:
Care in API design and evolution is required.
Of course, while key-value pair (hierarchical or not) data can always be read at the low level on both sides, you still have to design what happens when data is missing or unexpected. Equally true of XML.

I agree completely now. XML and simple Java Properties (aka key-value pairs) have their own issues, and care is required.

I guess in retrospect, my problem with Corba was that is was grossly oversold as the solution to all problems. Its not, as you say, care is required. There is No Silver Bullet.

I'm curious now if the design decisions for binary data transfer still hold up as justified. Sure sending four bytes of binary for an integer is less data across the line than the 11 digits it takes as ASCII digits, but for most communications, setting up the link takes far more time than the data transfer, so three times the internal data is lost in the noise. With binary, you need all the marshalling and unmarshalling, big and little endian worries, etc. I haven't tested it, but it seems to me that it was premature optimization.

[Bougnon Kipre]

To add to what has already been said, Borland also has a version of commercial CORBA, called Visibroker, which is a set of APIs built on top of Sun CORBA. This gives you more flexibility and better performance via scalability and a number of configuration schemes based on your application.

It also offers a number of option in its architecture, including client code and server being on different machines, to clustering, etc..
[ September 13, 2007: Message edited by: Bougnon Kipre ]

[Pat Farrell]

Originally posted by Bougnon Kipre:
To add to what has already been said, Borland also has a version of commercial CORBA, called Visibroker, which is a set of APIs built on top of Sun CORBA.

That's cool. The original Corba had problems. Of course, as someone posted up thread, to be really cool, you have to use Web 2.0 and XML (as words) to spin it properly. That no one can define what Web 2.0 really means is a minor detail. And XML is way too flexible to mean much, I've written lots of XML that is non-standard.

Someone wiser than me said "thats the great thing about standards, there are so many to chose from".

[168Feng]

I am greens about distributed computering