On 22/01/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Pete Robbins wrote: > On 22/01/07, Simon Laws <[EMAIL PROTECTED]> wrote: >> >> On 1/21/07, Pete Robbins <[EMAIL PROTECTED]> wrote: >> > >> > Simon, >> > >> > this code is in the extension that handles C++ components so we expect >> the >> > implementation to be C++. This is not the "default" proxy. This code >> will >> > be >> > invoked because the definition of the component is an >> implementation.cpp >> . >> > There is similar code in e.g. the ruby RubyServiceProxy that will >> handle >> > implementation.rb. >> > >> > Hope this helps. >> > >> > Cheers, >> > >> > >> > On 21/01/07, Simon Laws <[EMAIL PROTECTED]> wrote: >> > > >> > > The default C++ proxy currently seems to assume that its always >> trying >> > to >> > > talk to a C++ service. Line 104 of CPPServiceProxy looks like >> > > >> > > // If we got here we have a CPP implementation >> > > CPPImplementation* impl = (CPPImplementation >> > > *)componentType; >> > > >> > > Did I understand this correctly? If so why is this the case? >> > > >> > > Regards >> > > >> > > Simon >> > > >> > > >> > >> > >> > -- >> > Pete >> > >> > Thanks for the reply Pete. I'm still not sure I understand this. >> What is >> the role of the CPPServiceProxy intended to be. I would guess, just >> going >> on >> the name, that it is intended to be the CPP proxy for services as >> opposed >> to >> a proxy for CPP services. But I guess I'm missing something. >> >> The reason I'm asking the question is that I wanted to set up a local >> CPP >> client for my PHP component. I couldn't get SCA to do this directly, >> i.e. >> >> CPP Client --> PHP Component >> >> I had to put a CPP component in the way to make it work >> >> CPP Client --> CPP Component --> PHP Component >> >> Which struck me as a little strange. I expect my error lies in the way >> that >> I get hold of the context, locate the service or something else. Clearly >> there is a proxy somewhere that is able to talk to my PHP component from >> CPP. How do I get an instance of this one in the CPP client? >> >> Regards >> >> Simon >> >> > Ah. I see. The client interface using CompositeContext is not great. It > feels to me like a hack to allow non-SCA code to be logically part of a > composite. It is only for accessing a C++ component from a client. For a > component implementation the proxies are generated for each reference and > wrappers are generated for each service (using scagen) and are > compiled in > to the component implementation. For a c++ client this is not possible > so a > proxy is generated for each service and this becomes part of the > component > implementation. This is why the client has to get a C++ proxy from the > component implementation... which means it has to be a C++ implementation > first! > > Maybe we can re-think this and find a way to return a service proxy for a > non-C++ component via CompositeContext (the proxy itself will still > have to > be a generate C++ proxy and we do not want to have to link this with the > client code so where will it live?) > > Something to think about but for now you will have to have you CPP > Component > as the entry point from the CPP client. > > Cheers, > Connecting the C++ ServiceProxy to a ServiceWrapper wrappering a non-C++ component implementation is easy, but the real issue is that the SCA C++ C&I spec does not define an attribute to specify which DLL contains the (generated) C++ proxy outside of of a <implementation.cpp>, which you don't have when your component is not written in C++. I suggest to raise an SCA spec issue for this, and in the meantime, package these proxies in a library with a name derived from the name of the composite or the name of the target component, or as Pete suggested continue to use an intermediate C++ component as an entry point from the C++ client. -- Jean-Sebastien
I do not think this is a spec isue. The spec does not mention proxies/wrappers, that is just our Tuscany implementation. I never liked the client story in the SCA specs, it seems like a hack, but we followed the Java model. To me a more logical client interface would have been to define a service in the composite with a binding.cpp to be the entry point in to SCA from a C++ client, similar to how we expose a service as a ws binding. Cheers, -- Pete
