Throughout the study of the DOC architecture, we have touched the middleware paradigm with OO model. In today's DOC middleware, the distribution layer middleware has been maturated, while some small modification is still taking place. The common middleware services layer middleware is currently under research, while some has reached practise. The domain-specific services layer middleware may be more concentrated in the future, however, may also be replaced by some other direction.
Taking CORBA, RMI, and DCOM, there seems a continuous trend from Sun to implement RMI towards CORBA, and eventually, RMI may be a fully functional CORBA implementation from some point of view. There is also a competition between CORBA and DCOM, both try to include the other by providing interfaces or IDLs. However, since DCOM requires COM support, it is almost impossible to truly merge the two, and we expect them to co-exist in the future. As Windows platform is still the most popular OS, DCOM is holding a big share on current market, although RMI is probably the most feasible middleware available for many Java developers.
We have seen middleware design from its architecture aspect. However, the modularity of the architecture of middleware is starting to disintegrate and to become complicated due to the interaction of too many orthogonal concerns imposed from a wide range of application requirements. Zhang and Jacobsen have targeted on this problem using different approaches [11] [12] [13]. They proposed a method of refactoring middleware with aspects taking the Aspect-oriented Programming (AoP) approach. AoP is an alternative paradigm for software development aiming to achieve a high degree of separation of concerns. Later, they introduced the principles of Horizontal Decomposition (HD) providing a mixed-paradigm middleware architecture. The evaluation of the HD principles focus on refactoring major middleware functionalities into aspects in order to modularize and isolate them from the core architecture. Their implementation process and comparison results are available in publications. We do not get into details of their methods in this survey, because most of the contexts belong to software engineering topic. But rather, the problem explored here is that the middleware design and implementation evolve many considerations, and need intensive efforts.
Another big challenge in middleware design is QoS demands. As a middleware system always means an integration of different computing components, the QoS information becomes important to outline the system's requirements and assess whether the requirements are being met. QoS requirements also become more complicated as different components evolved. Individual component QoS requirements and end-to-end QoS requirements need to be considered under the whole strategy. Different users running the same application may have different QoS requirements. Middleware, in certain sense, is designed to meet the end-to-end QoS requirements, which can hardly be delivered by any other distributed environments. However, to meet those requirements in middleware design is still a tough job under most situations, and becomes an important assessment to understand middleware's reliability and usability.