Designing Client-Server InterfaceSource: email@example.com
Problem: CORBA, like DCOM and RMI, is a mechanism to call objects on another computer. However, designing the interface of those remote objects can be tricky.
Jacques deMolay described one way to handle this:
[About a distributed application with the GUI on the client side and the business logic on the server side, and CORBA interface in between]
The unusual design decision is that the CORBA interface implemented by the client consists of a single method called acceptRequest(). The CORBA interface implemented by the server consists only of the methods notify() and acceptReply(). Each of these methods takes a string (sometimes formatted in XML, sometimes not) as a parameter. The two frameworks are responsible for parsing this string and using factories to create the appropriate classes to handle the passed message. [...]
Andy P. Langton explained the advantages:
[...] The scenario for the reason behind this kind of thinking goes something like this:
The difficulties highlighted in this scenario are further compounded if third-party components are involved.
The choice is yours!
Robert C. Martin pointed out the drawbacks:
Sounds like you have reduced CORBA to a pair of sockets. Why pay the overhead? If you want a pair of sockets that you pitch XML packets over, then use them.
Passing XML between communicating processes is probably the most extensible mechanism you can use. If the format of the data moving between processes is very likely to change a great deal, then the XML approach is not a bad one. It does, however, reduce all errors to runtime errors; and forces you into lots of runtime checking.
If the protocol between the intercommunicating processes is not likely to change very much, then explicit interfaces are likely to be faster and more reliable.
Mark Collins-Cope put it even less mildly:
While they are at it, they could 'hide' themselves from the complexity of the GUI interface having only two methods used with the GUI: drawBitmap and getClick. They could then implement their own window system over the the existing one, and thus save themselves having to learn the interface to the GUI :-).
On a slightly more serious note, it sounds like for whatever reason they are genuinely scared of using CORBA. Perhaps they don't understand CORBA properly, and could do with some training. Something is definitely lurking behind the suggested approach - with the approach they are suggesting you might as well use Sockets directly.
I do not think what they are suggesting is a good idea. The will end up re-inventing many aspects of the CORBA wheel.
H. S. Lahman suggested another approach altogether:
[...] I believe the way to think about this problem is to raise the level of abstraction by considering the business problem alone first. The 'GUI' and 'Business' applications talk directly to one another. In so doing they send one another messages. At this level of abstraction the mechanism of message transfer is not relevant; it is a low level implementation detail that depends upon the computing environment rather than business rules. Those messages define the interface between the applications in terms of the business semantic.
When you select a specific communication mechanism you effectively insert that mechanism between the 'GUI' and 'Business' applications to transship the messages. However, that should not change the interface that 'GUI' and 'Business' use. Thus I would expect the interface to the communication mechanism to expose exactly those interfaces (i.e., the business semantic).
You have chosen a specific implementation in CORBA for the communication mechanism. The applications do not care about this and should not be affected if you decide to switch to DCOM or if CORBA provides the anticipated new services. In addition, the semantic of CORBA is entirely different than the semantic of the application messages. These considerations drive the development of 'client' and 'server' wrappers around CORBA. [...]
Patrick May described how such wrappers can be made:
[...] My approach was to create an abstract class that defines the interface for each potentially distributable class. From this class I derive an implementation class and a CORBA proxy class. I then create a CORBA implementation class that binds to the IDL interface. This class uses the first implementation class for its business logic.
For example, consider the class Foo that may be distributable. I first create an IDL interface for it and an abstract C++ class named Foo that defines the interface. I then create the class FooImpl that inherits from Foo and implements the interface (in standard C++, no CORBA datatypes) and the class FooCORBAProxy that inherits from Foo and implements the interface by calling a CORBA implementation.
The CORBA implemenation class is called FooCORBAImpl -- it implements the Foo IDL interface but passes all the method calls on to a private copy of FooImpl. This keeps the business logic in one and only one place.
Now, by using factories or, possibly more elegantly, some kind of registration scheme, I can present the applications with only the Foo interface. They never have to know if they're actually using a local FooImpl or a remote FooCORBAProxy. [...]
Douglas C. Schmidt, Overview of CORBA
Bert Bos, XML in 10 points
Vince Huston, The Proxy Design Pattern
Robert Orfali, Dan Harkey,