RE: [sca-c-cpp] ISSUE 54: Long Running Operations and C++

[Bryan Aupperle <aupperle@us.ibm.com>]

I may be missing a bit of history here,
but my understanding of the spec has always been that ComponentContext::getService()
returned a proxy.  From section 3.1:

The getService() member function takes as its input argument the name of the reference and returns a pointer to an object providing access to the service. The returned object will implement the abstract base class definition that is used to describe the reference.

The following shows a sample of how the ComponentContext is used in a C++ component implementation.  The getService() member function is called on the ComponentContext passing the reference name as input. The return of the getService() member function is cast to the abstract base class defined for the reference.

#include "ComponentContext.h"
#include "CustomerService.h"

using namespace oasis::sca;

void clientFunction()
{

   unsigned long customerNumber = 1234;

   ComponentContextPtr context = ComponentContext::getCurrent();

   CustomerService* service =
                   (CustomerService* )context->getService("customerService");

   short rating = service->getCreditRating(customerNumber);

}

If the object returned by ComponentContext::getService() is not a generated proxy, then what is it?

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

"David Haney" <haney@roguewave.com>

02/12/2009 07:51 PM

To	Bryan Aupperle/Raleigh/IBM@IBMUS, <sca-c-cpp@lists.oasis-open.org>
cc
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]
Sent: Friday, February 06, 2009 12:36 PM
To: sca-c-cpp@lists.oasis-open.org
Subject: [sca-c-cpp] ISSUE 54: Long Running Operations and C++
 

This is a fairly complete proposal 
The one topic that is open is how to deal with operations that have multiple
possible WSDL faults.  Do we need to define a ServiceBusinessException
class that the classes generated from a WSDL document extend?

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC 
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com