Developer Products - New Features in 4.1

...... Return to "Release Notes" page ......

  • Service Name Resolution
    The service name resolution feature allows load balancing across instances of a service, even if those services are on different machines. Currently, load-balancing is on a "round robin" basis, using a configurable weighted average.
    Some information which was previously contained in the .sdf service definition file is now redundant (though retained for backwards compatibility), and is now contained in a .snr service name resolution file. The existing .sdf file should be retained,and a new file, kept in the same location, should be provided. The name of the file should be "Domain_Service.snr", withcontents similar to the following:
    which would supplement an existing Domain.sdf file containing:
    For full details of the format of the .snr file, see the cpSnrData man page. Note that the DSAP Release value of REL4.0 is still applicable for 4.1.
    In the near future, it will be possible to access service name resolution data stored in an X.500 source. The code to support this is in place, but is incompletely tested at this time due to the current unavailability of an X.500 source.
    No code changes (other than the configuration file changes outlined above) are required to existing applications. Applications not using X.500 should link against the stub library libfldap.a.

  • Support for HTTP
    HTTP may be used as an underlying transport to replace DECmessageQ by specifying vendor HTTP in the service name resolution file (both as the default vendor, and as the actual vendor). Note however that this transport is not as full-featured asDECmessageQ, and some code modification may be required to use it. The most important limitations are: no secondary queues, no alternate reply-to locations, no message selection criteria, no forwarding, no guaranteed messaging (except that,since it is a connection-oriented protocol, failure to deliver will be notified immediately), no support for subscriptions or conversations. For complete details, see the cpTransport man page.
    No code changes are required to existing applications, other than to use the new feature.

  • Support for Tuxedo
    Tuxedo may be used as an underlying transport by specifying vendor TUXEDO in the service name resolution file. Note that this implementation is not as full-featured as DECmessageQ, and that some code modification may be required on the client side to use it--on the server side, code modification is definitely required, since Tuxedo's paradigm is so different fromDSAP's. The most important limitations are: no secondary queues, no forwarding, no message selection criteria, no support for subscriptions or conversations. For complete details, see the cpTransport man page.
    No code changes are required to existing applications, other than to use the new feature. Applications not using Tuxedo should link against the stub library libftux.a.

  • Instance-id as Attribute
    An instance-id may now be specified as an attribute as well as a character string, and functions in the cpMessage andcpGenericManager classes have been overloaded to reflect this. Internally, a string is converted into a string attribute withname "DSAP.instanceId".
    Minor code changes may be required to existing applications: the functions createCreateRequest, createGetRequest,createSetRequest, createDeleteRequest and createActionRequest are now overloaded, such that, if the fourth argument(instance id) is passed in as 0, it must be explicitly cast; otherwise, no code change is required.

  • cpHandle as Class
    cpHandle used to be #define'd as a void*. It is now a class. This should be transparent to most existing code, with the notable exception of servers supporting subscription. The servers need to store the handle for subsequent use--they will now have toinvoke the handle's save() function to represent it as an octet string for storing, and the restore() function prior to subsequentuse.

  • Encryption
    Data within an envelope can be encrypted, transparently to the application, by requesting encryption via the resource object.The service's public key should be provided as a publicKey entry in the .snr file (if it is not, encryption requests will be silentlyignored). The application (client or server) may supply its own public and private keys, again via the resource object; if none issupplied, defaults will be used (but note that this will not be totally secure).
    Users must purchase their own copy of the BSAFE library, from RSA Data Security, Inc., in order to use this feature. Notethat encryption is expensive, in terms of resource utilization.
    No code changes are required to existing applications, other than to use the new feature. Applications not using encryptionshould link against the stub library libfbsafe.a.

  • Mixed-message envelopes
    Message types may now be mixed within an envelope, so that, for example, an envelope may contain both a create request and a set request. Of course, requests and responses may not be mixed. When extracting messages, a new cpEnvelopemember function, nextMsgType() indicates the type of the message that will be retrieved by the next call to nextMessage() (orcpMSG_NONE, if there are none).
    Some generic manager functions are overloaded to take an additional more parameter to allow construction of the envelopes,in a manner similar to the way create requests are currently handled.
    No code changes are required to existing applications, other than to use the new feature.

...... Return to "Release Notes" page ......