Fusion Middleware Documentation
Advanced Search


Developing Remote Clients for Oracle Coherence
Close Window

Table of Contents

Show All | Collapse

1 Introduction to Coherence*Extend

This chapter describes Coherence*Extend and includes information about supported Coherence clients (Java, C++, and .NET).

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 Types Of Clients

Extend clients can be created for the Java, .NET, and C++ platforms and have access to the same rich 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. There are two categories of clients: Data Clients and Real Time Extend Clients.

1.2.1 Data Clients

Data clients are extend clients that are able to access (put, get, query) data in the cluster and also make invocation service requests using standard Coherence APIs. In particular, data 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

For a complete list of Data Client features, see Oracle Fusion Middleware Licensing Information.

Note:

Data clients cannot be notified of changes to data in a cluster. Further, data clients do not have the ability to use Near Caches or Continuous Query caches, as those capabilities also rely on the ability to receive notifications of data changes from the cluster. For these capabilities, real-time clients must be used.

1.2.2 Real Time Clients

Real Time Clients (Extend-TCP) provides the same capabilities associated with data clients; but, unlike data clients, a real-time client also supports:

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

  • Local Caches – While the client application can directly access the caches managed by the cluster, that may be inefficient depending on the network infrastructure. For efficiency, a real-time client can use both 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 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 Chapter 10, "Building Integration Objects (C++)," and Chapter 17, "Building Integration Objects (.NET)," respectively.

1.5 Understanding 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 tangosol.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 tangosol.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 tangosol.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,