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). 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 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.

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 Coherence Products in Oracle Fusion Middleware Licensing Information User Manual.

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:

• Java – See Creating Java Extend Clients for details on using the API and refer to Java API Reference for Oracle Coherence for detailed API documentation.

• C++ – See Creating C++ Extend Clients for details on using the API and refer to C++ API Reference for Oracle Coherence for detailed API documentation.

• .NET – See Creating .NET Extend Clients for details on using the API and refer to .NET API Reference for Oracle Coherence for detailed API documentation.

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 Using Portable Object Format in 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.

Extend client configuration 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 Cache Configuration Elements in Developing Applications with Oracle Coherence.

  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 Specifying a Cache Configuration File in Developing Applications with Oracle Coherence.

• 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 POF User Type Configuration Elements in Developing Applications with Oracle Coherence.

  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 Specifying a POF Configuration File in Developing Applications with Oracle Coherence.

• 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 Operational Configuration Elements in Developing Applications with Oracle Coherence.

  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 Using the Default Operational Override File in Developing Applications with Oracle Coherence.

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.

This section includes the following topics:

• REST Client Support
  
• Memcached Client Support