[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-c-cpp] ISSUE 54: Long Running Operations and C++
An issue came up when revising this document
to take an IOU/Future approach to the asynchronous interface. With the
introduction of the asynchronous functions, we’ve also introduced the
concept of a service proxy class, which I don’t think has been mentioned
before. This appears to be a code generated class, based on either the
WSDL or C++ interface for the service, and it looks like it will be this class
that is returned from the ComponentContext::getService() and presumably the ExternalContext::getService().
This seems like a relatively significant change from what we’ve discussed
before, and may have wider reaching implications than just the asynchronous
API. For example, if we’re now requiring code generation of a proxy
class for all services, then we no longer have a requirement that the
ComponentContext::getService() method return a type without a base class. We
could require that all generated proxy classes derive from some sort of base
Proxy class. This would allow us to provide a type safe mechanism for
accessing the proxies, instead of the unsafe mechanism we have today: oasis::sca::ComponentContextPtr context =
oasis::sca::ComponentContext::getCurrent(); MyServiceProxy* proxy = dynamic_cast<MyServiceProxy*>(context->getService(“MyService”)); proxy will be null if the service we get
back isn’t a MyServiceProxy. This only works though if all proxies
(and all services returned from MyService) inherit from a common base class. If we are introducing the generation of a
proxy concept, we also probably need to expand the current WSDL mapping rules
and clarify how we map from a WSDL to a generated proxy. Thanks. David. From: Bryan Aupperle
[mailto:aupperle@us.ibm.com]
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]