1,490
In my previous post I wrote about two patterns for using a GigaSpaces cluster to solve some of the issues involved in managing distributed applications:
- Using the space as a scalable alternative to a directory service. With this approach each service publishes itself to the space directory service and a JMX proxy acts as a wrapper that virtualizes the different managed services from the client accessing them.
- Using the
space as a management repository aggregating management data.
Steve Colwill from PSJ published a second post on this topic titled Data
Aggregation via JMX and the Grid that covers the second
option outlined above. In summary, Steve suggests that each managed agent will report its aggregate statistics to the space. A JMX fa??ade is used to expose the statistics through a standard JMX API.
If you think about it, this is yet another proof of the old aphorism by Butler Lampson that “All problems in computer science can be solved by another level of indirection”.
The thing about indirection though is that it basically moves the problem from one layer (the application layer or management layer in our specific case) to another layer (infrastructure layer). Now if that infrastructure layer is not in place, we have to create it ourselves, which makes Butler’s statement kind of empty. This is where Space-Based Architecture becomes handy. It serves as a general purpose infrastructure layer that provides a means for solving data distribution, high availability and scalability.
In this case we applied the abstraction principle as a way to expose the
generic space capabilities through a specific set of APIs (JMX in this case). The combination of the two creates what I often refer to as a middleware
virtualization layer. We use the same API, but the implementation of this API is virtualized. In this specific case, our JMX API doesn’t point to a physical JMX server, instead it points to a virtualized cloud of
servers.
Quoting Steve:
One of the reasons I’m a fan of GigaSpaces and space-based architectures is that a number of architectural choices that are traditionally hard-wired:
transactional/non-transactional, sync or async replication can be changed
through configuration only. This enables common design patterns (and therefore
components) to be applied to a wide range of application problems, by enabling
the data integrity/performance equation to be tweaked at a late stage of
application assembly.
Summary
The main benefit of this approach compared to the one described in the previous post is that it decouples the client and the managed services. A client doesn’t need to maintain direct a connection to the managed service. Most of the logic is kept server-side. In this way
we can keep the client-side — which acts as the management fa??ade — stateless and
thin.
Because the space acts as a distributed data-store, it is easier to build aggregated statistics, as all the statistics are placed in
one logical entity – the space.
Decoupling enables us to easily add new services/policies to our
system without changing the management service. For example, we can add SLA monitors that can listen to the statistics in the space and take action once a certain threshold is breached. This capability makes the space an ideal solution for those looking to build their next-generation management and monitoring application.
Cloud management frameworks (for Infrastructure-as-a-Service) are ideal candidates for this, as they have the need for proximity of the management information and application behavior. The management layer acts as a loopback mechanism that can tell the application how it is actually behaving. The application can use this information to adjust itself to meet a given SLA without human intervention.
Having said all that, it is also important to note that the two options presented in Steve’s posts are not
necessarily mutually exclusive. I could easily see how one could use
the approach presented in this post for maintaining the managed dashboard
information, and the approach in the previous post to invoke specific operations on a managed
service, in case you want to drill down to the managed service level. Having one underlying technology
that can be used to serve the invocation, virtualization and data virtualization
is yet another benefit of using the space.
