On Thu, Oct 30, 2008 at 8:19 PM, Balasubramanyam, Shivakumar < [EMAIL PROTECTED]> wrote:
> Altaf, > > I looked at SCA three months ago and spend couple of weekends (night-outs > actually). > > SCA will be great solution going forward where applications that are > written in C++ needs to work in multiple environments (consumers could be > C++ or Java) and act as a container of any sorts. > > Issue is that, the current SCA-native code does not cut it. My evaluation > was below, > > Dislikes: > 1. usage of namespaces and exceptions are not supported in all embedded > platforms.[not a concern on server side] > 2. I really don't like the existing approach which requires the marshalling > of operation arguments in the Proxy/Wrapper to an intermediate > ParamterTypes. Also, the code is duplicated in DataObject > This can be achieved by using something like, > map<"datatype_stringname", void* data> that can be passed to the model to be > serialized. Even better, using boost::any will allow genericity and > I would follow the concept of pushing the service binding information > out of stub/wrapper just like the transport or RPC modules. > 3. Removing dependency on any fixed parsing technology (xml in this case) > 4. No need for dynamic type identification over the wire format [which is > actually a great feature on the luxury platforms] > 5. For C++ only environment, concept of domain, composite, components is an > overload. > 6. Also, for CPPImplementation, the wrapper code does not need to make this > intermediate conversion of types and RPC invocations (Please let me know if > I am wrong). Cuz, the real implementation already supports function > descriptions. Well, I will see if I can provide samples. > > > Likes: > 1. Best comment was the layered design of core, model and extensions. > ServiceProxy, ServiceWrappers and Operation (which is basically a generic > way of storing RPC identifiers) > > I actually got the SCA tweaked to remove the SDO and DAS and the code size > was less than 500KB. I preferred static data marshalling factory of all > types to get rid of the SDO and DAS. The wire protocol format in the service > binding should be sufficient to make it interoperable. > > Please note that, I have disliked some very nice features of SCA mainly to > make it practical in embedded world.These points may make no sense on the > server side with greater availability of memory, cpu and storage. > > My conclusion was to base the framework on WSDL + OSGi + SCA (conversations > feature is really nice and lacks in WSDL). > > I will revisit SCA after some time to see if SDO can be developed with > lower footprint (i don't need all the features of SDO like change summary). > > > > Thanks, > Shiva > > ------------------------------ > *From:* Altaf Muneer [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, October 29, 2008 11:19 PM > *To:* [email protected] > *Subject:* Re: Tuscany SCA Native > > Hi Haleh, Simon, > > Thanks for the responses and comments.. > > > Do you have a pure C/C++ environment or is this an environment where Java > and C++ components will be used in the same composite? > We have a pure C/C++ environment.. > We are planning to use Tuscany SCA native (a stripped down version if that > is possible) in an embedded environment > > > At the moment I think it's a matter of looking at how the existing > bindings work an doing similar. > Yeah, i think thats what we will try to do.. > > Thank you for your time and suggestions > > Regards, > Altaf > > On Wed, Oct 29, 2008 at 8:24 PM, haleh mahbod <[EMAIL PROTECTED]> wrote: > >> Hi Atlaf, >> >> Do you have a pure C/C++ environment or is this an environment where Java >> and C++ components will be used in the same composite? >> >> Haleh >> >> On Wed, Oct 29, 2008 at 7:25 AM, Simon Laws <[EMAIL PROTECTED]>wrote: >> >>> Hi Altaf >>> >>> Some comments in line... >>> >>> Simon >>> >>> On Wed, Oct 29, 2008 at 2:03 PM, Altaf Muneer <[EMAIL PROTECTED]>wrote: >>> >>>> Hi, >>>> >>>> I was just checking the SCA Native strain of Tuscany and I had the >>>> following questions.. >>>> >>>> Is there any ongoing work in Tuscany SCA Native? (I noticed that the >>>> last release was in May 2007) >>> >>> >>> Not a lot. I did just check in a patch that one of the community >>> contributed but other than that there hasn't been recent discussion about >>> how to move it forward. Good opportunity if you want to get involved;-) >>> >>> >>> >>>> Is there any support for C in Tuscany SCA Native? >>> >>> >>> Not yet FAIK. There is a spec for C component types ( >>> http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforC_V100.pdf?version=1) >>> but no implementation of it yet. >>> >>> >>>> Are there any resources which will help one add new bindings for Tuscany >>>> SCA native? >>> >>> >>> It looks a bit thin at the moment. At the moment I think it's a matter >>> of looking at how the existing bindings work an doing similar. >>> >>> >>>> >>>> I would be grateful if anybody can answer these questions/ point me to >>>> some resources where I can find answers to these questions. >>>> >>>> Regards, >>>> Altaf >>>> >>> >>> >> > Hi Shiva That's a good list. Thanks for taking the time to put it together. Are there any of the changes that you made that can be included in the Tuscany code base? One of the points that features in your list (items 2,3,4 & 6) and which has come up before is the lack of databinding framework in the Native SCA support. We have one in Java SCA which allows a great deal of flexibility regarding how data is represented at the service interface and how it is moved across the wire, for example, you are not forced to use SDO. However it's not made it's way into the native runtime. Is this what you were starting to build? Regards Simon
