JAPC remoting extension is used to represent
middle-tier servers as virtual devices and/or parameters. Each
middle-tier server is known as a
remote or
virtual service.
All basic operations (GET/SET/SUBSCRIBE) are implemented in this
extension and can use several remoting technologies. All RPC (GET, SET,
START/STOP MONITROING calls) can be done through Java RMI (Spring), HTTP
(Spring) and JMS (Lingo, not used anymore at the moment). The updates
are sent to the clients through JMS topics.
JAPC remoting extension provides a number of configurable features
for remote services to do the basic things without a lot of complexity
but at the same time to be flexible enough to support complex systems.
As for any JAPC service the configuration is stored in a JAPC registry
(or CCDB).
2. Administrative mechanisms
After RPC START MONITORING came from the client the server
(producer) starts to publish updates through JMS, so all the interested
clients (consumers) receive them. In case of JAPC remoting extension the
producers and the consumers are in different processes. Therefore the
publishing server never knows if a single client is still running and
interested in the published updates. Moreover after the server is
rebooted it should somehow restart all the parameter update publications
(subscriptions) which were active before the rebooting since the clients
are still "subscribed" and expect to receive the updates. There are 2
ways to solve this problem:
- Unmanageable subscription. Server always publishes the
updates for the parameters this server represents. In this case RPC
START/STOP MONITORING are not even propagated to the server (or can be
ignored by the server). A new client just listens to a certain JMS
topic while it is interested in updates for a certain parameters.
Server should not know if there are clients or not. If the server is
rebooted it automatically starts all the subscriptions. This way of
working is common for concentrators: quite light servers which
represent a little number of parameters having the values as a result
of some computation from other parameter's values. But for complex
servers with a big number of virtual parameters this way is not
acceptable because of an overhead of publishing a lot of useless data.
- Manageable subscription. For complex servers with a big
number of virtual parameters there should be a way to find out that no
clients are interested in certain parameters updates anymore and the
corresponding subscriptions can be stopped. Another mechanism is
required to restart all the active subscriptions after the server is
rebooted. There are 2 administrative services designed for these
purposes:
- Leasing mechanism: this mechanism is used to find the
subscriptions which can be stopped. It works in the following manner:
there is a dedicated leasing JMS queue. The server and all the clients
are subscribed to this queue with a little difference: the priority of
clients is much higher than the server's priority. From time to time
the server sends to the leasing queue a message for each active
subscription saying basically "is there anyone interested in updates
from the certain server for the certain parameter and with certain
cycle selector" (JMS selectors are used for this). If there is at
least one active client it consumes the message (JMS guarantees that
the message is delivered to a consumer with higher priority). If for a
subscription there is no active client then the message will be
consumed by the server itself. Those subscriptions can be stopped.
- Subscription confirmation mechanism: this mechanism is
used after the server is rebooted to find the subscriptions which are
currently active. It works in the following manner: there is a
dedicated confirmation JMS topic. After the server has been rebooted
it sends a message to this topic with the ID of the server and waits
for the answers from the clients. For all the answers the
corresponding subscriptions are started.
3. Technical description and configuration
parameters for remote services
There is a number of parameters which should be configured for the
remote services. The configuration is stored in JAPC registry (or CCDB).
Parameters affect all the aspects of behavior of a remote service. For
example, as it is said above, the parameter updates are published to the
clients through JMS topics. The topic names are build following certain
rules and depending on the configuration parameter. The general format
of a topic name used to publish updates is:
jmsTopicPrefix.serverId.deviceName[.SEL.selector]
The different parts of a topic name are described below.
Some of the parameters are
optional and have a default
value. Others are
required and must be specified either in the
service configuration or at run-time. Some parameters can be overwritten
or set at run-time but some can't.
serviceName
First of all each remote service (as well as any JAPC service) has a
name. This parameter is
required and can not be set or
overwritten at run-time.
protocol
The
protocol which is not so important for local JAPC services
becomes quite important for remote services: it specifies a technology
which is used for RPC. This parameter is
required and can not be
overwritten. JAPC supports the following remoting protocols:
- no: no RPC calls are foreseen for the service.
Basically used for concentrators
- rmi: Java RMI is used for RPCs (GET, SET, START/STOP
MONITORING), Spring based
- http: HTTP is used for RPCs, Spring based
- jms: JMS is used for RPCs, Lingo based, we are going to
abandon this option
serverId
Each service has its identifier to be easily distinguished from other
services. If this parameter is defined in the configuration it can not
be overwritten at run-time. However if it is not defined in the
configuration it can be set on both client and server side with VM
argument "serverId".
jmsBrokerList
Remote services can publish the updates through different JMS brokers.
jmsBrokerList
specifies the URL of a JMS broker to work with. If this parameter is
defined in the configuration it can not be overwritten at run-time.
However if it is not defined in the configuration it can be set on both
client and server side with VM argument "japc.remote.jms.brokerlist". If
this parameter is not specified neither in configuration nor with VM
argument then the default JMS broker will be used.
topicPrefix
Each service publishes the parameter updates into topics with the names
built according to some rules. One of the rules is that each topic for a
remote service is prefixed with some common beginning (ex.
"CERN.CNGS.PROD"), to easily separate messages of different remote
services. If this parameter is defined in the configuration it can not
be overwritten at run-time. However if it is not defined in the
configuration it can be set on both client and server side with VM
argument "japc.remote.jms.topic.prefix". If this parameter is not
specified neither in configuration nor with VM argument then the default
JMS topic prefix will be used ("CERN.DEFAULT_JMS_TOPIC_PREFIX").
administrationEnabled
This parameter specifies if the service is using administrative
mechanisms (see above) or not. This parameter is optional and the
default value is "false".
selectorAware
If a service is
selectorAware then the selector name is
also included to a topic name used to publish updates. This is used to
split updates coming for different cycles/users. This parameter is
optional and the default value is "false". In case when this option is
enabled the selector is normally taken from the JAPC value header (in
case of a parameter update) or from ParameterException (in case of
problems). The servers (publishers) can also use
RemoteServerFactory.getPublisherPvl(Selector)
or
RemoteServerFactory.getPublisher(String, Selector) to
create a publisher with particular selector which then will be used. A
client just subscribes to a selector it needs.
firstUpdate
A service can be configured to use different first-update policy.
- no means the first-update is not supported by the virtual service (default)
- client means that the client side should fetch the value when the subscription
is started and use this value as the first-update value
- server means that the server should sent the first-update once it detects a new client
This parameter is optional and the default value is "no".