ABLE 2.0.0 07/02/2003 10:25:01

com.ibm.able.conversation
Interface ConversationPolicyHandler

All Known Implementing Classes:
AbstractCPH

public interface ConversationPolicyHandler

This is the ultimate basis for all conversation policy execution modules.

OLD VERSION -- TO BE DELETED Replaced by com.ibm.conversation.ConversationPolicyHandler.


Method Summary
 void addPropertyChangeListener(java.beans.PropertyChangeListener newListener)
           
 void addPropertyChangeListener(java.lang.String property, java.beans.PropertyChangeListener newListener)
           
 java.util.Collection getDecisionPoints()
          Returns the set of all names that might be used in decision-requests, for any role.
 MessageForm getMessageForm(java.lang.String messageKey)
          Returns the MessageForm object associated with the given transition, as identified by message key.
 java.util.Collection getMessageKeys()
          Returns the set of message-keys of the decision names for all decision points.
 java.util.Collection getMessageKeys(java.lang.String decisionPoint)
          Returns the set of all message-keys (names of send-message transitions) for outgoing transitions from the given decision point.
 java.lang.String getPolicyName()
          Identifies the policy we're handling.
 java.lang.String getRole()
          Returns the role we've assumed, or null if we haven't assumed one.
 java.util.Collection getRoleSet()
          Returns the set of possible roles, as defined by the policy we're handling.
 java.lang.String getStateName()
          Identifies the current "state" of the CP.
 void process(ConversationEvent input, ConversationEventSequence outputs)
          Attempts to process the given input event.
 void process(ConversationEventSequence inputs, ConversationEventSequence outputs)
          This attempts to process the given sequence of events in "batch mode".
 void removePropertyChangeListener(java.beans.PropertyChangeListener oldListener)
           
 void removePropertyChangeListener(java.lang.String property, java.beans.PropertyChangeListener oldListener)
           
 void reset()
          Puts the CP into a start state without changing the role.
 void reset(java.lang.String newRole)
          Puts the CP into a start state and sets the role.
 void setRole(java.lang.String newRole)
          Sets the current role.
 

Method Detail

getPolicyName

public java.lang.String getPolicyName()
Identifies the policy we're handling.

getStateName

public java.lang.String getStateName()
Identifies the current "state" of the CP. For CPHs that aren't based on state-machines (e.g., for rule-based CPHs), this may be a problem. This presumes that the "state" of a CP can be usefully represented by a string. True for state-machine CPs, less so for other architectures.

getRoleSet

public java.util.Collection getRoleSet()
Returns the set of possible roles, as defined by the policy we're handling.

getRole

public java.lang.String getRole()
Returns the role we've assumed, or null if we haven't assumed one.

setRole

public void setRole(java.lang.String newRole)
Sets the current role. Tests to see whether newRole is in the role set. If not, does nothing. reset() should always be called after changing the role. Do not use this. use reset(newRole) instead. TO DO: get rid of this.

getDecisionPoints

public java.util.Collection getDecisionPoints()
Returns the set of all names that might be used in decision-requests, for any role. In any CP, each decision-point is assumed to have a unique name. Usually the decision- point name is the same as the state name. Q: rename "decision point" --> "state name"?

getMessageKeys

public java.util.Collection getMessageKeys()
Returns the set of message-keys of the decision names for all decision points. These usually correspond to the names of send-message transitions. In any CP, each send-message transition is assumed to have a unique message-key. Q: rename "message key" -> "decision name"? Q: return all possible decision names (even if not for send-message transitions)?

getMessageKeys

public java.util.Collection getMessageKeys(java.lang.String decisionPoint)
Returns the set of all message-keys (names of send-message transitions) for outgoing transitions from the given decision point.

getMessageForm

public MessageForm getMessageForm(java.lang.String messageKey)
Returns the MessageForm object associated with the given transition, as identified by message key.

reset

public void reset()
Puts the CP into a start state without changing the role. Role should be set before the first time this is called.

reset

public void reset(java.lang.String newRole)
Puts the CP into a start state and sets the role.

process

public void process(ConversationEvent input,
                    ConversationEventSequence outputs)
Attempts to process the given input event. Returns the output event, if there is one, or null if not. Only certain types of ConversationEvent make sense as inputs to a CPH: --MessageEvent, type=INBOUND only, from messaging system --DecisionEvent, type=DECISION only, from decision logic --CPDoneEvent, passed up from child CP, for child-return transitions --ProtocolErrorEvent passed up from child, for contextual error-handling --TimerEvent, type=TIMER_EXPIRED only, for timeout expiration Similarly, only certain types make sense as outputs: --MessageEvent, type=OUTBOUND only --DecisionEvent, type=DECISION_REQUEST --CPDoneEvent --ProtocolErrorEvent --LoadCPEvent --TimerEvent, type=SET_TIMER, for setting a timer --ContextEvent More than output may be triggered by a single input (e.g., a decision to say goodbye might trigger outbound message & CPDone). TO DO? We could return a newly created output sequence, rather than appending outputs to a sequence supplied by the user. This would be conceptually cleaner, though slower. There's a performance hit caused by allocating all whole new sequence object, just to put 1 event in it.

process

public void process(ConversationEventSequence inputs,
                    ConversationEventSequence outputs)
This attempts to process the given sequence of events in "batch mode". Beware, however: if any of the inputs causes the CP to go off track, the outputs can get nonsensical very fast. This also makes no sense if outputs of a CPH ever feed back into that CPH as inputs. I haven't found any instance where that happens, though. TO DO? Return a newly created output sequence, as discussed above. TO DO? Get rid of this. It's not useful.

addPropertyChangeListener

public void addPropertyChangeListener(java.beans.PropertyChangeListener newListener)

addPropertyChangeListener

public void addPropertyChangeListener(java.lang.String property,
                                      java.beans.PropertyChangeListener newListener)

removePropertyChangeListener

public void removePropertyChangeListener(java.beans.PropertyChangeListener oldListener)

removePropertyChangeListener

public void removePropertyChangeListener(java.lang.String property,
                                         java.beans.PropertyChangeListener oldListener)

ABLE 2.0.0 07/02/2003 10:25:01

(C) Copyright IBM Corporation 1999, 2003