Re: [sca-c-cpp] NEW ISSUE: Preserving state in passivated Conversationalscopes.

This issue has been assigned id CCPP-25
in the Jira system. 

See http://www.osoa.org/jira/browse/CCPP-25

Andrew

____________________________________________________________

Andrew Borley

Websphere ESB Development

Tel: 245393 Ext: +44 (0) 1962 815393 Mob: +44 (0) 7971 805547

E-mail: 

Mailpoint 211, IBM (UK) Ltd, Hursley Park, Winchester, Hants, SO21 2JN

____________________________________________________________

"David Haney" <>
wrote on 29/11/2007 16:55:23:

> This seemed like it was complex enough that we should probably deal
with

> it as a separate issue from the conformance statement review.

> 

> 

> 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.

> 

> Thanks.

> 

> David.

> 

> -- David Haney

> -- Chief Architect, Hydra Products

> -- Rogue Wave Software

> -- http://www.roguewave.com/ 

> 

> 

> 

> ---------------------------------------------------------------------

> To unsubscribe from this mail list, you must leave the OASIS TC that

> generates this mail.  You may a link to this group and all your
TCs in OASIS

> at:

> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

> 

Unless stated otherwise above:

IBM United Kingdom Limited - Registered in England and Wales with number
741598. 

Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU