1 Introduction to Coherence*Extend

This chapter describes Coherence*Extend and includes information about native Coherence clients (Java, C++, and .NET) and non-native Coherence clients (REST and Memcached).

This chapter includes the following sections:

1.1 Overview of Coherence*Extend

Coherence*Extend "extends" the reach of the core Coherence TCMP cluster to a wider range of consumers, including desktops, remote servers, and computers located across WAN connections. Typical uses of Coherence*Extend include providing desktop applications with access to Coherence caches (including support for Near Cache and Continuous Query) and linking multiple Coherence clusters connected through a high-latency, unreliable WAN.

Coherence*Extend consists of two basic components: an extend client running outside the cluster and an extend proxy service running in the cluster hosted by one or more cache servers (DefaultCacheServer) that are storage disabled. The client APIs include implementations of both the CacheService and InvocationService interfaces which route all requests to the proxy. The proxy responds to client requests by delegating to an actual Coherence clustered services (for example, a partitioned or replicated cache service or an invocation service).

Coherence*Extend uses the Extend-TCP transport binding (a low-level messaging protocol) to communicate between the client and the cluster. The protocol is a high performance, scalable TCP/IP-based communication layer. The transport binding is configuration-driven and is completely transparent to the client application that uses Coherence*Extend.

Figure 1-1 provides a conceptual view of the Coherence*Extend components and shows an extend client connecting to an extend proxy service using Extend-TCP.

Figure 1-1 Conceptual View of Coherence*Extend Components

Description of Figure 1-1 follows
Description of "Figure 1-1 Conceptual View of Coherence*Extend Components"

Like cache clients, an extend client retrieves Coherence clustered service using a cache factory. After a service is obtained, a client uses the service in the same way as if it were part of the Coherence cluster. The fact that operations are being sent to a remote cluster node is transparent to the client application.

1.2 Extend Clients

Extend clients (also referred to as real-time clients) can be created for the Java, .NET, and C++ platforms and have access to the same API as the standard Coherence API without being full data members of the cluster. Typically, client applications are granted only read access to cluster data, although it is possible to enable direct read/write access. Extend clients provide:

  • Key-based cache access through the NamedCache interface

  • Attribute-based cache access using filters

  • Custom processing and aggregation of cluster side entries using the InvocableMap interface

  • In-Process caching through LocalCache

  • Remote invocation of custom tasks in the cluster through the Invocation Service

  • Event Notifications using the standard Coherence event model. Data changes that occur within the cluster are visible to the client application. Only events that a client application registers for are delivered over the wire. This model results in efficient use of network bandwidth and client processing.

  • Near Caching and Continuous Query Caching to maintain cache data locally. If the server to which the client application is attached happens to fail, the connection is automatically reestablished to another server, and any locally cached data is re-synchronized with the cluster.

For a complete list of real-time client features, see Oracle Fusion Middleware Licensing Information.

1.3 Extend Client APIs

Java, C++, and .NET (C#) native libraries are available for building extend clients. Each API is delivered in its own distribution and must be installed separately. Extend clients use their respective APIs to perform cache operations such as access, modify, and query data that is in a cluster. The C++ and C# APIs follow the Java API as close as possible to provide a consistent experience between platforms.

As an example, a Java client gets a NamedCache instance using the CacheFactory.getCache method as follows:

NamedCache cache = CacheFactory.getCache("dist-extend");

For C++, the API is as follows:

NamedCache::Handle hCache = CacheFactory::getCache("dist-extend");

For C#, the API is as follows:

INamedCache cache = CacheFactory.GetCache("dist-extend");

This and many other API features are discussed throughout this guide:

1.4 POF Serialization

Like cache clients, extend clients must serialize objects that are to be stored in the cluster. C++ and C# clients use Coherence's Portable Object Format (POF), which is a language agnostic binary format. Java extend clients typically use POF for serialization as well; however, there are several other options for serializing Java objects, such as Java native serialization and custom serialization routines. See Developing Applications with Oracle Coherence for details.

Clients that serialize objects into the cluster can perform get and put based operations on the objects. However, features such as queries and entry processors require Java-based cache servers to interact with the data object, rather then simply holding onto a serialized representation of it. To interact with the object and access its properties, a Java version of the object must be made available to the cache servers.

See Developing Applications with Oracle Coherence for detailed information on using POF with Java. For more information on using POF with C++ and C#, see Building Integration Objects (C++), and Building Integration Objects (.NET), respectively.

1.5 Understanding Extend Client Configuration Files

Extend clients are configured using several configurations files. The configuration files are the same as the cluster configuration files. However, client configuration files are deployed with the client. The files include:

  • Cache Configuration Deployment Descriptor – This file is used to define client-side cache services and invocation services and must provide the address and port of the cluster-side extend proxy service to which the client connects. The schema for this file is the coherence-cache-config.xsd file for Java and C++ clients and the cache-config.xsd file for .NET clients. See Developing Applications with Oracle Coherence for a complete reference of the elements in this file.

    At run time, the first cache configuration file that is found on the classpath is used. The coherence.cacheconfig system property can also be used to explicitly specify a cache configuration file. The file can also be set programmatically. See Developing Applications with Oracle Coherence for general information about the cache configuration deployment descriptor.

  • POF Configuration Deployment Descriptor – This file is used to specify custom data types when using POF to serialize objects. The schema for this file is the coherence-pof-config.xsd file for Java and C++ clients and the pof-config.xsd file for .NETclients. See Developing Applications with Oracle Coherence for a complete reference of the elements in this file.

    At run time, the first POF configuration file that is found on the classpath is used. The coherence.pof.config system property can also be used to explicitly specify a POF configuration file. When using POF, a client application uses a Coherence-specific POF configuration file and a POF configuration file that is specific to the user types used in the client. See Developing Applications with Oracle Coherence for general information about the POF configuration deployment descriptor.

  • Operational Override File – This file is used to override the operational deployment descriptor, which is used to specify the operational and run-time settings that are used to create, configure and maintain clustering, communication, and data management services. For extend clients, this file is typically used to override member identity, logging, security, and licensing. The schema for this file is the coherence-operational-config.xsd file for Java and C++ clients and the coherence.xsd file for .NET clients. See Developing Applications with Oracle Coherence for a complete reference of the elements in this file.

    At run time, the first operational override file (tangosol-coherence-override.xml) that is found on the classpath is used. The coherence.override system property can also be used to explicitly specify an operational override file. The file can also be set programmatically. See Developing Applications with Oracle Coherence for general information about the operational override file,

1.6 Non-Native Client Support

Coherence provides remote access to caches from REST-based or Memcached-based clients. As with Coherence*Extend clients, non-native clients use the resources of a cluster without becoming cluster members. Both REST and Memcached client APIs are available for many popular programming languages, allowing Coherence to be used in heterogeneous environments. Non-native clients can also be used to ease the migration to a Coherence solution that uses the native Coherence client APIs.

1.6.1 REST Client Support

Coherence provides a REST implementation that provides access to cache operations over the HTTP protocol. Any REST client API can use Coherence caching. REST support is provided either through an embedded HTTP server that is configured as an extend-like acceptor on a proxy server, or through deployment to any Java EE-based application server. For details about using Coherence REST, see Using Coherence REST

1.6.2 Memcached Client Support

Coherence can be used as a drop-in replacement for memcached servers. Any memcached client API that supports the memcached binary protocol can use Coherence distributed caching. Memcached support is provided through a memcached adaptor that is implemented as an extend-like acceptor that runs on a proxy server. For details about configuring Coherence to accept memcached client connections, see Integrating Oracle Coherence.