[OASIS Issue Tracker] Created: (SCACANDCPP-1) Preserving state in passivated Conversational scopes

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

Preserving state in passivated Conversational scopes
----------------------------------------------------

                 Key: SCACANDCPP-1
                 URL: http://tools.oasis-open.org/issues/browse/SCACANDCPP-1
             Project: OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC
          Issue Type: Bug
            Reporter: Bryan Aupperle


Originally CCPP-25

TARGET: C++ C&I Spec

DESCRIPTION: Section 2.3.4 of the C++ spec discusses the possibility of
passivating a service implementation instance in a long-running
conversation, however it doesn't define how implementation state should
be preserved.

PROPOSAL:

The following is an initial take at replacing/clarifying the last
sentence of the first paragraph of section 2.3.4:

"If this occurs, the runtime MUST provide a mechanism for preserving
instance state information. An SCA runtime MUST NOT passivate an
implementation instance if it cannot preserve implementation state."

Does that help to clarify the expected behavior? This still leaves us
with the responsibility for writing conformance tests for this scenario,
which may be difficult.

An alternative might be to wash our hands of passivating implementation
instances (replacing the last two sentences).

"This specification does not define a mechanism for passivating
long-running conversational implementation instances. An implementation
MAY provide a mechanism for passivating implementation instances."

A third option might be to define in the C++ API a mechanism to allow
users to preserve state. One approach would be to provide a simple API
that a service implementor could derive from and implement in order to
provide persistence/restoration capabilities on their implementations.

class PersistableService {
  virtual ~PersistableService();

  /**
   * Returns a string containing the serialized state associated
   * with this service.
   */
  virtual std::string persistState(void) = 0;

  /**
   * Reads the state information for this service from the
   * serialized state information in \a state.
   */
  virtual void restoreState(const std::string& state) = 0;
};

Alternatively we could add additional annotations to allow the user to
identify their own persist/restore methods (we'd still probably need to
specify the return type/parameters of the methods).

This would restrict how a runtime could support passivating a service
(by requiring this mechanism), but it will also ensure that there's a
portable mechanism for persisting user state across runtime
implementations.


Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200711/msg00025.html

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira