Coherence - Back to Basics

One question that keeps cropping up is when to configure an application as a cluster member and when over *Extend? The answer has always been pretty simple - If application stability cannot be guaranteed then it cannot be considered as a cluster member. There is more to it, btw. Following questions you must ask before opting for any configuration strategy:

• If an application is written in either C++ or .NET then there is no other choice but to configure it as an *Extend client.
• If the interface to Coherence is Java (including JNI) then choices are a little deeper.

Lets talk about it in more details (The content is not a dictation to its readers but an assistance to put them on a right track).

When to configure as a cluster member?

1. Applications deployed inside a container (Like an Application server) are typically configured as storage disabled cluster members. The reason is application servers themselves being "server-side" components are considered fairly stable.
   
2. Applications demanding "extreme" performance are configured as cluster members.
   
3. *Extend introduces an additional network hop and if this additional couple of milliseconds are not acceptable then configure it as a cluster member.
4. If proxy-reconnect is an issue.

When to *Extend?
I am a big proponent of *Extend configuration because it provides us a framework that we are already so used to. With new enhancements in Coherence v3.5 and later in Proxy services and serialization mechanism, overhead on proxy has reduced considerably and this opens up a some nice architectural options.

1. If the application is a desktop application where reliability cannot be guaranteed.
2. If network over which the application is accessing Coherence resources is slow or unreliable.
3. If application is written in .NET or C++

Besides these there are some advanced considerations:

1. If application is already very TCP/IP centric. New services can be developed on top of Proxy as is demonstrated here, here and here.
   
2. If an application arbiter is needed or something like a Gatekeeper.
   
3. With *Extend proxy layer can be scaled independent of other storage nodes. *Extend configuration allows three layers of scalability - First application clients, second the proxy layer itself and the third the core storage members or non-proxy cluster members. Storage member layer is about data scalability and proxy layer is about request scalability.
4. In line with the popular Adapter pattern typically found in BPEL designs. Application specific adapters can be plugged into Coherence using Proxy's TCP/IP service making application clients even more agnostic of Coherence infrastructure beyond the Map implementation.
5. If a new component is added that introduces new features that are not available out of the box from Coherence, it is much safer to deploy it on proxy nodes. Always remember we do not have any access to either the underline protocol (TCMP) or the core coherence component layer. Any feature that simulate either of the two must be performed by proxy.
6. Anyone still remembers SOA? Even though SOA does not dictate the transport layer but it is much cleaner to have well defined services running and accessing coherence resources over *Extend. If services are deployed inside a container then revisit (1), (2) and (3).
   

Enjoy!