Transparent Remote Access

Transcription

1 Abstract Transparent Remote Access Klaus Marquardt Käthe-Kollwitz-Weg 14, D Lübeck, Germany In distributed systems, the different processors communicate via network messages. Object oriented systems do not focus on these messages, but on the responsibilities each object fulfils. Between the top-level objects it should be invisible on which system an addressed object resides. The Transparent Remote Access pattern gives a recipe how the implementation of a method can defer the invocation to another processor. To support Transparent Remote Access even on small machines, a stepwise approach is introduced that allows for simplification when only a part of the functionality is needed. Pattern : Transparent Remote Access Context Problem Forces Solution An application is distributed among multiple processes or processors. It is developed using object-oriented techniques and a responsibility based approach. You are prepared to use a Protocol-Follows-Application Design [Marquardt] process. How can you hide your distribution mechanisms and message handling from both the caller and the called implementation? Domain class users must not know or see the transport facilities or depend on them. Different classes must have clearly separated responsibilities. The application evolves and may need more remotely addressed objects in the future. Development is most efficient when the desired solution is easy to understand and apply. Development of additional classes causes effort and time. Addressing functionality remotely comes with performance degradation. Implement technical objects around each object that you need to access remotely. Use Proxies [GOF] to convert a method call into a transport message; use Forwarder-Receiver [POSA] to send this message to the processor that hosts the implementation; use a Reactor [POSA2] to address the appropriate implementation. An infrastructure for message transportation, multiplexing, and interpretation is required. On this infrastructure, application specific classes are build. Each domain class is split in several classes with different responsibilities. The interface is separated from the implementation; the

2 implementation resides in one specific processor or process. For addressing this implementation remotely, this process offers a specific Receiver class that converts incoming messages into method calls of the actual implementation. Other processes access the implementation through a Proxy that packs the method call and its arguments into a message. The Proxy and the Receiver are developed together to achieve a common identification and interpretation of the message contents. For a basic functionality these classes are sufficient. Your implementation may take further steps to allow for factoring of Proxies, and for return values on remote method calls. Consequences Implementation Preparation: Infrastructure The location of execution of services is transparent to the clients. Transport facilities are hidden from domain class users. The dependency structure is well understood and defined. Each object has unique, crisp responsibilities. Further active objects can be added at any time. A recipe for implementation or even generation can be given. A lot of technical infrastructure is required, causing considerable development effort. Performance tuning and network traffic limitation is difficult as a lot of objects may issue messages. The implementation requires an infrastructure for addressing a remote system at all, and a number of steps that must be implemented for each remotely addressable object. For a basic functionality, the first two steps must be taken. For a reasonable dependency graph also take the third step, which allows you to leave all code unchanged except for the initialization code. When you need to retrieve return values somehow, you have to take also the forth step. The last step offers a direct reception of the method call results. The infrastructure consists of a Forwarder-Receiver [POSA] mechanism or channel interface that can transport messages between different nodes. When different transport mechanisms are used within the system, an Abstract Session [Pryce] can help to encapsulate them. Furthermore, base classes are needed for Proxy [GOF] and Receiver that send respectively receive messages. The messages are transported via the above channel interface, and each message has an application defined identification. Channel send(msg : Message&) receive(msg : Message&) Message Receiver <<A>> handle(ms g : Message&) : bool <<A>> getid() : int Proxy <<A>> getid() : int ReceiverRegistry register(rec : Receiver&) : void unregister(rec : Receiver&) : void dispatch(msg : Message&) : bool

3 Step 1: Interface Separation Optionally, you may add a ReceiverRegistry class that dispatches messages on one channel to different receivers. This registry can be omitted when each channel connects to a single receiver only. When the channel interface offers an Observer [GOF] interface, the registry becomes an observer for incoming messages. Define the object that you need to make available independent of the processor or process. Separate the interface by making it an abstract class (a protocol class without member attributes), and let the implementation derive from it. From now on, all clients access only the interface class. All passed arguments must be of a fundamental or serializable type, so that they can be packed into a network message. Take care that no function returns any value or takes arguments by reference. This is to ensure that the caller does not receive any immediate feedback on a method call. In case you need a direct answer, refer to the optional steps below. <<Role>> Client <<Interface>> ActiveObject <<A>> callone() : void <<A>> calltwo(arg : Serializable) : void ActiveObjectImplementation callone() : void calltwo(arg : Serializable) : void Step 2: Proxy-Receiver Definition Result: two classes specific to the remotely addressable object: an interface and a derived implementation. For the client side, derive a Proxy class that implements each call by creating a network message and forwarding it (via Forwarder-Receiver) to the server side. For the server side, create a specific receiver class that unpacks the message back into function arguments, and calls the implementation class. Here you should access only the interface object, so you can opt to cascade several proxy calls when necessary. Both classes depend merely on already existing classes and exhibit no additional public behavior, so they can be hidden from outside clients. To make this step work, you need to define several ID s. The first one identifies the addressed remote object, and the Proxy and its equivalent Receiver have to agree on it. This ID needs to be unique for each remotely accessible object. The subsequent ID s are internal to the object and identify the called function. On the server side, you need to register all Receivers by their respective IDs to forward the network message from the network listener to the correct Receiver. Your specific Proxy and Receiver share the same ID s. Together with the order in which each function call arguments are appended to the message, these ID s define your specific application level protocol part. You should maintain this pair together to avoid any protocol errors.

4 <<Interface>> ActiveObject ActiveObjec timplementation call via interface ActiveObjectProxy getid() : int callone() : void calltwo(arg : Serializable) : void ActiveObjectReceiver getid() : int handle(msg : Message&) : bool unpac kcallone(msg : Message&) : void unpac kcalltwo(msg : Message&) : void Proxy (from Transport) ReceiverRegistry (from Transport) Rec eiver (from Transport) Result: One specific Proxy class derived from the interface, one specific Receiver class that addresses the interface. One or two header files defining the ID s. Optional Step 3: Proxy-Receiver Creation Optional Step 4: Results in Distinct Object Optional Step 5: Direct Result Create a Factory [GOF] for the client side that creates the Proxy and returns an Interface. On the server side, make sure that an instance of both the Receiver and the Implementation is created, that the receiver is registered and has access to an Implementation object (e.g. via a Factory [GOF] or Trader [Bäumer+]). These creational classes depend only on the previously available classes. Your need to ensure that your application creates all objects that is potentially addressed remotely through this Factory. Result: You can now call functions at an object that may be anywhere in the system, and you only need to know about the base class. The only precondition is that during initialization you have to access a transport channel and call a Factory. To receive return values from such a server object, define a second remotely addressable object. Now the client server roles are exchanged. The initial server object answers to a distinct object that is represented here as a Proxy to a Server Answer object whose implementation resides on the clients' side. Result: You have a triangle of classes. The client processor gets an answer, but to a different object than you originally addressed. A natural signature of objects is a direct return of a function result. To achieve this behaviour you can combine both interfaces of the previous step to a single one. The combined interface resides on the clients side, maintains instances of the Question Proxy and the Answer Implementation, and keeps track of copying data and references and the timing constraints. You need to decide for an either synchronous or asynchronous call policy. Synchronous calls may cause your application to block for a long time, whereas for an asynchronous call you to define a thread or task context that waits for the answer and informs your application.

5 Example Result: You achieved a natural way of accessing remote objects transparently, at the cost of adding about a dozen technical objects. An application collects all significant events from different processes in a common LogBook. To ensure consistency and avoid locking conflicts, only one process writes new LogEntries to the LogBook while the other processes access it remotely. For all application code the actual location of the LogBook is transparent. class LogEntry : public Serializable { LogEntry( int severity, int sourceid, const string& text); int severity() const; int sourceid() const; string text() const; // inherited: virtual void pack( Message& msg) const; virtual void unpack( Message& msg); // [...] // Separated interface class class LogBook { virtual void addentry( const LogEntry& theentry) = 0; // Implementation, resides in a dedicated process - omitted // Proxy class, forwarding the request to the appropriate process class LogBookProxy : public Proxy { LogBookProxy( Channel& achannel ) : Proxy( achannel) { void addentry( const LogEntry& anentry) { m_message.reset(); m_message.setid( LOG_BOOK, ADD_ENTRY); m_message << anentry; send( m_message); } // [...] // Receiver, evaluates the message // and addresses the appropriate implementation class LogBookReceiver : public Receiver { LogBookReceiver( LogBook& theimpl) : Receiver( LOG_BOOK), m_impl( theimpl) { void handle( Message& msg) { /*...*/ // dispatches to a specific function private: LogBook& m_impl; // reference to the implementation void addentry( Message& msg) { LogEntry myentry; msg >> myentry; m_impl.addentry( myentry); // [...]

6 Known Uses Related Patterns CORBA implementations generate similar code from an IDL definition. [Martin] gives a textbook example of several important aspects. Transparent Remote Access employs these patterns: Proxy, Forwarder- Receiver. and Reactor. The protocol between the processes is defined in the specific Proxy-Receiver implementation and thus not centrally defined, which corresponds to Protocol-Follows-Application Design. Conclusion The Transparent Remote Access pattern provides a recipe to create distributed applications in heterogeneous or restricted environments. Developers can create their own powerful mechanism for remote object access. This is most useful in environments like embedded systems, where ready-to-use products for object distribution such as like CORBA or DCOM are not available. The related development effort and the gained convenience is scaleable through several optional steps. Acknowledgements Many thanks are due to Manfred Lange, the EuroPLoP 2000 shepherd of this paper, for his detailed and timely comments. References Bäumer+ GOF Martin Marquardt POSA POSA2 Pryce Dirk Bäumer, Dirk Riehle: Product Trader. In: Pattern Language of Program Design, Volume 3, Addison-Wesley 1998 Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Design Patterns, Addison-Wesley 1995 Robert Martin: Designing Object Oriented Applications Using the Booch Method, Prentice Hall 1996 Klaus Marquardt: How to Define a Protocol for Object Transportation. In: Proceedings of the 5 th European Conference on Pattern Languages of Programs, 2000 Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal: Pattern-Oriented Software Architecture. A System of Patterns, Wiley 1996 Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann: Pattern- Oriented Software Architecture Volume 2. Patterns for Concurrent and Networked Objects, Wiley 2000 Nat Pryce: Abstract Session. In: Pattern Language of Program Design, Volume 4, Addison-Wesley 2000