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?
Pretty much spot on there. 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;-)
Clearly we could do with some code gen capability and we should start thinking about what this should involve. Until then, and for the first Milestone release, we will have to make do with documentation. Perhaps you would like to make a start on this as you have a good grasp of the problem? ;-) Cheers, -- Pete
