This chapter includes the following sections:
Parent topic: Getting Started
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
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:
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. See Using Coherence REST.
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. See Using Memcached Clients with Oracle Coherence in Integrating Oracle Coherence.