From Sockets to Distributed Objects: Integration Transports


Once upon a time, if a programmer wanted one program to talk to another across a network, the choices were limited. The most common way to accomplish this used to be communication endpoint mechanisms called sockets, sometimes called TCP sockets or BSD sockets. The metaphor is straightforward: a socket exists on each end, and you plug each end of your (virtual) communication circuit into one of the sockets, and then the two sockets talk to each other. Sockets are still one of the most efficient and frequently used communication mechanisms, and are often considered to be fairly low-level programming constructs. Most higher-level or simpler communication APIs, regardless of programming language, are built on top of sockets. This includes many Java networking APIs.

With distributed communication, as with most other engineering challenges, there is more than one way to do it. Over the last few years there has been a change in how programmers think about network communication, a shift that parallels the shift in programming methodologies from structured or imperative languages like C, Pascal, and COBOL to object-oriented languages like C++, Smalltalk, and Java. Now, network programmers are just as likely to think about "distributed objects" or "remote service interfaces" as they are to think about sockets. It is sometimes nice to be able to treat an object or service that is "somewhere out there" on the Internet as if it were part of your program, running on the same computer (if only things were truly that simple). CORBA, Java RMI, DCOM, Web services, and now P2P each provide different ways to think about distributed communication.

The hows and whys of network communication are of very real importance in integration. There are different styles of communication, each with its own set of advantages, disadvantages, and caveats. Sometimes the choice of what communication style to use will be made for you by virtue of the systems or applications that are to be integrated.

Distributed Object Protocols: Object-Oriented Communication

Distributed object protocols extend object-oriented programming ideas to network programming. With distributed objects, an object running in a process space in a remote location on a different computer across the network appears as if it were running locally. Methods or functions can be called on the remote object, treating it no differently than if it truly were local. (This is not the whole truth, as we'll discuss later in this chapter.)

The location transparency achieved with distributed objects is intended to simplify life for the network programmer. Often this is the case distributed objects represent significant "syntactic sugar" to the programmer; that is, network communication can be achieved with significantly less work on the part of the programmer. However, there is often performance overhead associated with distributed object protocols, and sometimes the infrastructure and configuration required to achieve location transparency of objects is more trouble than it's worth. We'll discuss some distributed object protocols specifically CORBA, Java RMI, DCOM, and Web services in a bit more detail later in this chapter.

Distributed object systems generally share some basic ideas. There is usually some notion of a proxy, or stub that the client of a remote object uses to invoke method calls on that object. There is also the notion of a server-side proxy, sometimes called a skeleton, that is the corresponding server-side proxy for the client. Method arguments or parameters are collected and transformed into a form suitable for sending over the wire, a process called marshalling. You can think of marshalling as a kind of "dehydrating" process. At the server side, the method arguments are "rehydrated," or demarshalled back into the proper form for handling by the remote object. In CORBA and Java RMI, the client stub is called the stub or proxy, and the server stub is called the skeleton. In DCOM, the client stub is the proxy and the server stub is the stub.

When you're building network-aware applications in Java, it's natural to consider distributed object protocols like Java RMI for communication.

Java is an object-oriented programming language, and so depending on the requirements and constraints of the application, an object-oriented communication protocol might be desirable. P2P systems built in Java are no exception.



JavaT P2P Unleashed
JavaT P2P Unleashed
ISBN: N/A
EAN: N/A
Year: 2002
Pages: 209

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net