Having been working on the Windows build today, I agree with your summary. There might even be problems to less new users. My saviours this afternoon hav been: 1) Running the axis http server in the debugger - loading the extra sca_ws dll and setting breakpoints. 2) Checking very very carefully the env vars TUSCANY_SCACPP, TUSCANY_SDOCPP, TUSCANY_SCACPP_SYSTEM_ROOT. 3) Checking them again. 4) checking the logs in the axis logs directory - Calculator_blocking gives you what happens when the service is loaded. axis2.log tells you if the service didnt load. - I just asked the asix2c people to add some details to the log to say which dll in which path didnt load - then I think we have all bases covered.
On 27/06/06, Simon Laws <[EMAIL PROTECTED]> wrote:
I've spent a little time playing with the C++ SCA implementation. I want to replay my understanding to see if it is correct. When constructing a service that will have a web service binding you have to provide a number of things including myservice.h to define the class that is the service myservice.cpp to implement the class that is the service myservice.wsdl to describe the service interface Of course you have to provide the appropriate SCA configuration files also, e.g. sca.module, Tuscany-model.config etc, and you have to SCAGen the interface to generate proxies and wrappers. - At this point in time there is no WSDL -> C++ or C++ -> WSDL tooling Hence at present there is a requirement that you, as the developer of the service, ensure that the interface described in C++ matches the interface described in WSDL. - At this point in time there is no C++ SDO support for static types Hence interfaces to services that take SDOs will always descibe the interface in terms of DataObjects. - The web services interfaces adopt the doc/literal/wrapped pattern Hence the WSDL has to be constructed/used carefully in this respect to match the expectations of the runtime and the types that are used to describe WSDL message elements are not the types that find their way in and out of the C++ service implementation. It is the types that are themselves wrapped that find themselves presented to and returned from the service implementation. Is this understanding correct? Is there some way we can provide a helper function (or simple generator) that demonstrates how a service operation should handle the types it is presented with and produce a type for return based on the WSDL description of the interface? This could be as simple as providing a mechanism to print out a template C++ operation based on the model formed from the WSDL. Maybe this could be done with good documentation and samples but I'm not sure. I sense that there will be mistakes made in this area by new users;-) Regards Simon
