Middleware Wrapper

MiddlewareWrapper is a pattern described in DesignPatternsForDistributedObjects. This page is currently a discussion page and will become more formalised over time.

Intent

To avoid dependence on a particular middleware, write classes which adapt between how you would like to write your code and how the middleware forces you to.

---

If you want to create a common abstraction to enable portability across products, then you'll have to deal with the "IntersectionOfFeatures? vs UnionOfFeatures?" decision:

The "IntersectionOfFeatures?" approach is to use only those features that all vendor products support. If one vendor can't do "X," then you avoid doing "X," and you don't provide it in your abstraction. (This is often incorrectly referred to as the "LeastCommonDenominator?" approach.)

The "UnionOfFeatures?" approach is to support all features provided by any vendor product. One tries to emulate missing features, if possible.

In practice, one can compromise by combining the two options above, and/or writing vendor-specific conditional logic in client code. -- JeffGrigg

---

I HaveThisPattern. (One more vote, and you'll have a legitimate pattern! ;-) -- JeffGrigg

The sentence ending "delegating to an instance of the local interface" (near the end of the Description section) seems to assume you're on the client side. When you're responsible for both sides of the client/server interface, you'll have to implement TWO classes -- an application proxy and an application stub. Both have the same responsibilities, but the delegation between local and remote interfaces is reversed.

Servers must always catch and translate exceptions. On clients, exception translation is optional (I never do it.), but translating COM HRESULT codes to exceptions should be required. -- JeffGrigg

You don't translate exceptions on the client? So your clients know that they are talking to CORBA? That would worry me. -- JohnFarrell

Catching and translating exceptions to a vendor-neutral format makes a lot of sense if...

• Client code is catching and doing interesting processing of selected exceptions.
• Interface code is to be highly reusable "library" code, to be used across projects.
• Exceptions are caught and processed in a large number of places in the client code.

But it can make sense to have a variety of vendor- / product- / platform-dependent exceptions percolating through the code if...

• You have much more (hand written) interface code than exception catching and processing code.

Perhaps my view is slanted because I do more middle-tier ("business logic") than client work (...and lots of refactoring of other people's work that is completely out of control). I often find myself catching all possible exceptions in one central location that controls transaction processing, logging the error, and doing high level recovery there. I think your approach is more general and cleaner. -- JeffGrigg

I write library code, so I do as much as I know how to make the interface simple and not dependent on anything in particular. I always suppose that the user will want to replace my implementation with something better that comes along, so I try to make that easy. I suppose I don't even understand what the forces are for other types of code. --JohnFarrell

---

Caution: Inexperienced developers may get confused about the concept of a "proxy," being unable to distinguish between the proxy they read about in the CORBA documentation and the application proxy you're writing (from the DesignPatterns book, for example). -- JeffGrigg

Inexperienced developers are welcome to be confused about the distinction between CORBA proxies and DesignPatterns proxies. On page 208 of the GangOfFour book, point 1 in Applicability suggests that the GangOfFour is confused too :-). -- JohnFarrell

---

''In a remote invocation, the caller and the callee are never in the same thread. Hence stack traces are almost useless for explaining context, and it's harder to debug unexpected situations. ''

As far as I know, all the commercial distributed Smalltalk systems change the debuggers so that when the debugger hits a stack context that originated from a distributed call, the debugger will follow the call back to the originator and pick up the stack trace on the client's side. It is not that big a deal, and I would be surprised if systems like Forte didn't do it, too. I think you really should say that debuggers need to be made aware of your distributed object system, and if they aren't then you lose. Maybe none of the Java systems do it currently, but that will change.

The real problem with debugging distributed systems is that distributed systems are almost always concurrent systems, and concurrent systems are hard to debug. Using Smalltalk doesn't change that. -- RalphJohnson