CommunicationPoint

CommunicationPoint defines the interface used by all communication points used by Rhapsody. If you want to implement a custom communication point for Rhapsody then all you have to do is implement this interface. AbstractCommunicationPoint is the generic partial implementations and provides sensible default implementations of many of the methods in this interface. Any class which implements this interface (either directly or by extending the abstract class mentioned above) also needs to have a constructor which takes a single CommunicationPointInfo argument. The argument contains simple information about a communication point.

Communication points are points of connection for Rhapsody to the outside world. In general a communication point is used to create connections over which messages can be sent and received by Rhapsody. So a communication point typically defines a transport protocol over which messages are sent. Common examples would be FTP or TCP/IP. Communication Points have a notion of an implementation kind. This restricts the types of modes the communication point can be used in. Below is a table which lists the possible implementation kinds of communication points a description of the kind and the corresponding modes the communication point can be used in.

Communication points have a clearly defined life cycle. It is guaranteed that a communication point will not be started (that is, have its getConnection() method called) before it is configured via its configure(CommunicationPointConfiguration) method and that configure(Configuration) will not be called while it is running. The configuration properties a communication point requires should be returned by its getPropertyList() method. For a full description of the format of the property strings that should be returned by this method see Filter.

One area of that needs special attention when implementing your communication point concerns synchronization issues. Communication points should generally be able to have more than one connection in use at any one time. This means that there are possible synchronization issues depending on how you implement your communication point. It may be possible that all the connections are completely independent from each other, but usually they are sharing some resource, even if that resource is on a remote system (such as a database table) and care must be taken that the same message is not returned by more than one connection or that two ends from different connections overwrite one another.

The good news is the communication point can only be configured while it is stopped meaning there no active connections for the communication point. So in general synchronization on member variables of the communication point shared by the connections can be removed if they are only written to during the configure method and only read by the connections. Another point to be aware of is that if the communication point is running in BIDIRECTIONAL mode there will be separate threads calling the sendMessage(Message) and receiveMessage(Message) methods of the communication point connections, so they must be either completely independent of each other (which is common) or synchronized.

If the communication point is running in INPUT,  OUTPUT or OUT_IN mode then there will only be one thread using any one connection and you only have to worry about the interaction of multiple connections. If you want to ensure that your communication point can only ever have one connection at a time you can implement the SingleConnectionCommunicationPoint interface. This interface doesn't define any methods, it simply indicates to the engine that this communication point may only be configured to use one connection at a time.

Save

Save