sca-c-cpp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-c-cpp] NEW ISSUE: Preserving state in passivated Conversationalscopes.
- From: Andrew Borley <BORLEY@uk.ibm.com>
- To: sca-c-cpp@lists.oasis-open.org
- Date: Fri, 30 Nov 2007 13:30:14 +0000
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: borley@uk.ibm.com
Mailpoint 211, IBM (UK) Ltd, Hursley Park, Winchester, Hants, SO21 2JN
____________________________________________________________
"David Haney" <haney@roguewave.com>
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]