Large scale aggregation and sharing of heterogeneous components, computational nodes and mass storage/data centers powered by their integration through intelligent process management techniques has led to widespread acceptance of the grid computing paradigm. This "cluster and conquer" model of computing has simplified the processing of CPU- and memory-intensive applications.
Grid computing concepts have come a long way since they were first explored in the I-WAY experiment back in 1995. Extensive research and developments have resulted in successful implementations of grids across large bandwidth networks. A key concern, however at this point could be the design approach that an effective grid solution should adhere to. While the top down approach is more business-centric, the bottom up approach is more sensitive to implementation details and low-level realities. The latter has been the most preferred and utilized design approach for grid middleware. Let us try to examine the reasons behind the widespread use of the bottom up approach as compared to the top down approach.
Top down approach
This design paradigm has not been much preferred by the grid community, but implementations of grid middleware which have adopted this approach do exist in small numbers. The following could be some of the areas of contention:
1. Recently, grids have been envisioned as fitting rightly into the service-oriented architectural model. Thus, existing and already operational assets need to be exposed as services so as to leverage SOA in the design of grid middleware. Adopting a top down approach in such a case would narrow the reuse of existing development components and enterprise assets.
2. A key disadvantage of the top down approach is its strong adherence to application domain requirements. It isolates the business needs first and then drills down for low level realization of the same. By tying down itself to a particular application need, the resulting grid services implementation will fail to offer more generic solutions for ubiquitous access to disparate resources.
3. As we move down various layers of the grid solution, continuous analysis and re-analysis needs to be done to ensure process level and data level interoperability throughout the application design.
4. The "grid middleware" aims at disintegrating a single task across a distributed network while the user still sees the job processing as the work of a single machine. Thus we have several low-level components which, though geographically independent, work interdependently in sync. And as is often said, the finer is the granularity at the lower level, the more are the complexities of top down management. Any issue at the lower level might cascade upwards and affect the top level business services.
5. Inability to reuse existing assets and continuous evaluation of the solution to ensure interoperability at various levels make the top down approach highly cost intensive.
Bottom up approach
This design paradigm has been mostly favored in the area of grids. The following are some reasons for the popularity of the bottom up approach:
1. This approach identifies the lowest level of implementation and progressively combines the larger elements in a continued and incremental manner to form a complete grid middleware solution. The hassles in such an approach are minimal as it is easy to implement.
2. In the bottom up approach virtual clusters in a grid can not only be created, but also deployed incrementally across the network. Thus, not only are load balancing within the virtual pool and ad hoc workload management at the low-level possible, but abstraction of services at an enterprise level can also be facilitated.
3. The bottom up approach doesn't assume that the top-level business services will adhere to stringent requirements. It also ensures eased interoperability and greater reusability.
It has, however, been noted that bottom up approach quite often leads to building a lot of redundant services. This can primarily be attributed to absence of a top-level evaluation of absolute business requirements.
A key highlight in the defense of the bottom up approach was given by a principal analyst of Nemertes research, Andreas Antonpoulos who said since grids are mostly designed to be operated on an adhoc, peer-to-peer basis (especially with regard to job allocation and node addition) without employing common command-and-control schemes, the bottom up approach is more suitable.
Meet in the middle (MIM) approach
This approach calls for a suitable and diligent marriage between the two design methodologies to sift the pros of both the approaches from the cons.
The following outline some scenarios where this approach might be implemented:
1. When implementation code of the grid service already exists, but the interface exposing the service is only partially developed, taking the round trip approach to meet in the middle could be helpful.
2. In case of developing a wrapper between the application environment and the execution environment, following a top down or bottom up approach might result in a lot of rework.
3. When services need to be continuously added to the sideway of either top down or bottom up approach keeping the middleware intact.
The MIM approach should ideally provide a proper mapping between top level services and low level infrastructural elements. This would ensure a more reliable design and fine-grained control at the hardware infrastructure level, effective streamlining and flexibility of business services. The reduction in the existing friction between the two will eventually result in realizing efficient workflows, load balancing and resource management.
Thus, before either of the above approaches is adopted, a thorough analysis of existing assets as well as future changes and goals need to be carefully monitored. This would facilitate greater stability of the system so as to sustain long running, computation intensive transactions while keeping development cost in check.
