PDO - Portable Distributed Objects

There may be many popular meanings for PDO with the most popular definition being that of Portable Distributed Objects.
Portable Distributed Objects, or PDO, is a programming API for creating object oriented code that can be executed remotely on a network of computers. It was created by NeXT Computer, Inc. using their OpenStep system, whose use of Objective-C made the package very easy to write. It was characterized by its very light weight and high speed in comparison to similar systems such as CORBA.
Versions of PDO were available for Solaris, HP-UX and all versions of the OPENSTEP system. A version that worked with Microsoft OLE was also available called D'OLE, allowing distributed code written using PDO on any platform to be presented on Microsoft systems as if they were local OLE objects.
PDO was one of a number of distributed object systems created in the early 1990s, a design model where "front end" applications on GUI-based microcomputers would call code running on mainframe and minicomputers for their processing and data storage. Microsoft was evolving OLE into the Component Object Model (COM) and a similar distributed version called DCOM,[citation needed] IBM had their System Object Model (SOM/DSOM), Sun Microsystems was promoting their Distributed Objects Everywhere, and there were a host of smaller players as well. With the exception of the limited functionality in COM, most of these systems were extremely heavyweight, tended to be very large and slow, and often were very difficult to use.
PDO, on the other hand, relied on a small number of features in the Objective C runtime to handle both portability as well as distribution. The key feature was the language's support for a "second chance" method in all classes; if a method call on an object failed because the object didn't support it (normally not allowed in most languages due to strong typing), the runtime would then bundle the message into a compact format and pass it back into the object's forwardInvocation method.
The normal behavior for forwardInvocation was to return an error, including details taken from the message (the "invocation"). PDO instead supplied a number of new objects with forwardInvocation methods that passed the invocation object to another machine on the network, with various versions to support different networks and platforms. Calling methods on remote objects was almost invisible; after some network setup (a few lines typically) PDO objects were instantiated locally and called the same way as any other object on the system. The PDO object then forwarded the invocation to the remote computer for processing and unbundled the results when they were returned.
In comparison with CORBA, PDO programs were typically 1/10th or less in size; it was common for NeXT staffers to write into magazines showing how to re-implement a multi-page CORBA article in perhaps 15 lines of code. From a programming standpoint, there was simply nothing nearly as easy to use as PDO.
However, PDO was also reliant entirely on Objective C to function. This was a price most were unwilling to pay, as at the time C++ was more widely used and the effort to shift codebases to an entirely new language and paradigm was considered too onerous. PDO never saw much use, and NeXT's emphasis shifted to its new WebObjects framework in 1995.
PDO continues to be used by Mac OS X programmers as a method for interprocess and interapplication communication, and for communication between networked applications that only need compatibility with other Mac OS X applications.
In addition to the OS X platform, there is GNUstep, which has its own implementation of Distributed Objects.
we will focus on object-oriented principles,methods, and tools that are emerging to support DOC usingC++. We plan to investigate and describe various toolsand environments that are available commercially. In addition,we will discuss detailed design and implementation problems that arise when using C++ to create DOC solutions.The field of DOC is already rather broad and is still growing rapidly.

distributed computing can improve :
 collaboration through connectivity and interworking;
 performance through parallel processing;
 reliability and availability through replication;
 scalability and portability through modularity;
 extensibility through dynamic configuration and reconfiguration;
 cost effectiveness through resource sharing and open systems.
Our experiences and the experiences of others have shown that distributed computing can indeed offer these benefits when applied properly. However, developing distributed applications whose components collaborate efficiently, reliably, transparently, and scalably is a complex task. Much of this complexity arises from limitations with conventional tools and techniques used to develop distributed application software. Many standard network programming mechanisms (such as BSD sockets and Windows NT named pipes) and reusable component libraries (such as Sun RPC) lack typesafe, portable, reentrant, and extensible interfaces. For example, both sockets and named pipes identify endpoints of communication using weakly-typed I/O handles. These handles increase the potential for subtle run-time errors since compilers can’t detect type mismatches at compile-time.
Another source of development complexity arises from the widespread use of functional decomposition. Many distributed applications are developed using functional decomposition techniques that result in non-extensible system architectures. This problem is exacerbated by the fact that the source code examples in popular network programming textbooks are based on functional-oriented design and implementation techniques.
So, in this world full of hollow buzzwords and slick marketing hype, it is natural to ask the question “what does object-oriented technology contribute to the domain of distributed computing?” The short answer to this question is that object-oriented technology provides distributed computing with many of the same benefits (such as encapsulation, reuse, portability, and extensibility) as it does for nondistributed computing.
In fact, it is often more natural to utilize object-oriented techniques in the domain of distributed computing than it is for non-distributed computing. This is due to the inherently decentralized nature of distributed computing. In conventional non-distributed applications, there is often a temptation to sacrifice abstraction and modularity for a perceived increase in performance. For example, many programmers use global variables or access fields in structures directly to avoid the overhead of passing parameters and calling functions, respectively.
In distributed computing, however, performance optimizations based on direct access to global resources are extremely difficult to develop and scale. Research and development on operating system support for distributed shared memory, for example, is not yet ready for large-scale system deployment. Therefore, most distributed applications interoperate by passing messages. There are many variations on this message passing theme (e.g., RPC, remote event queues, bytestream communication, etc.). However, it doesn’t require much of a stretch of the imagination to recognize that message passing in distributed computing is very similar to method invocation on an object in object-oriented programming. With this observation in mind, let’s discuss several of the key features of DOC:
Providing many of the same enhancements to procedural RPC toolkits that object-oriented languages provide to conventional procedural programming languages:
Distributed object computing frameworks enhance procedural RPC toolkits (such as Sun RPC and the OSF DCE) by supporting object-oriented language features. These features include encapsulation, interface inheritance, parameterized types, and object-based exception handling. Encapsulation promotes the separation of interface from implementation. This separation is crucial for developing highly extensible architectures that decouple reusable application-independent mechanisms from application-specific policies. Interface inheritance and parameterized types promote reuse and emphasize commonality in a design. Object-based exception handling often simplifies program logic by decoupling error-handling code from normal application processing.
Enabling interworking between applications at higher levels of abstraction:
Distributed applications have traditionally been developed using relatively low-level mechanisms. Common mechanisms include the TCP/IP protocol, the socket transport layer programming interface, and the select event demultiplexing system call. These lowlevel mechanisms provide applications with reliable, untyped, point-to-point bytestream services. In general, these services are optimized for performance, rather than ease of programming, reliability, portability, flexibility, or extensibility. A primary objective of DOC is to enable developers to program distributed applications using familiar techniques such as method calls on objects. Ideally, accessing the services of a remote object should be as simple as calling a method on that object. For example, consider an object obj that provides a service op with arguments arg1, arg2, and arg3 and a return value of type reply. We’d like our client applications to invoke op, pass it arguments, and obtain a reply by simply writing reply r = obj->op (arg1,arg2, arg3).A surprisingly large number of fairly complicated componentsmust be developed to support remote method invocation on objects transparently. These components include directory name servers, object request brokers (ORBs), interface definition language compilers, object location and startup facilities, multi-threading facilities, and security mechanisms. In subsequent columns, we will define these terms and illustrate how they work together to solve realworld problems.
Providing a foundation for building higher-level mechanisms that facilitate the collaboration among services in distributed applications:
Supporting transparent remote object method invocation is only the first step in the long journey into the realm of distributed object computing. An increasing number of distributed applications require more sophisticated collaboration mechanisms. These mechanisms include common object services such as global naming, event filtering, object migration, reliable group communication, transactional messaging, and quality of service facilities. More advanced tools will support electronic mail, visualization, collaborative work, and concurrent engineering. When all these provisions of DOC are realized and standardized, we may very well finally see the long-awaited arrival of “plug and play” software components and “Software ICs.” Object vendors will be able to market various implementations of industry-standard interfaces, and users will be able to mix and match those components, investing in the ones that they believe best fulfill their needs. Until that time, however, there is still quite a bit of work to do. Only recently have the very lowest levels of support for DOC, such as object request brokers, become commonplace in the market.
But What About C++?

So far, we’ve barely evenmentioned C++. In future columns, we’ll discuss ways in which C++ may be used to simplify distributed object computing. We believe that when used properly, C++ is well suited for the construction of both distributed object support systems and the object components themselves. C++ combines high-level abstractions with the efficiency of a low-level language like C. Many of the emerging frameworks and environments for distributed object computing are based on C++, due to its widespread availability and appeal. For example, commercial tools such as several CORBA ORBs, HP OODCE, and Network OLE, as well as freely-available software toolkits such as ILU from Xerox PARC and the ADAPTIVE Communication Environment (ACE), support object-based distributed programming using C++. Certain C++ features are well-suited for programming distributed objects. For example, abstract base classes, pure virtual inheritance, virtual functions, and exception handling help to separate object interfaces from object implementations. However, the lack of other features in C++ increases the complexity of developing robust and concise distributed applications. For instance, support for garbage collection would greatly reduce memory management complexity. Likewise, before and after methods would enable greater control over the marshaling and demarshaling of parameters passed to remote method calls. In the coming months, we will discuss C++ language idioms that have been successfully used in practice to address certain C++ limitations.

Source : TechSolution.in