Hi Yang I guess we are incrementally assessing how possible it is to allow our model processing support both levels of spec. In my mind the jury's still out but we have potential solutions to the problems we've found so far. Nothing we have done to date prevents the model processing from being limited to one level of the spec if we do get stuck.
More comments in-line snip.. > > However, I do understand the potential difficulty to enable both OSOA and > OASIS. . > > One solution comes to my mind is if our virtual "SCA Domain" can have two > domain instances one supporting OSOA , the other supporting OASIS, then > potentially the "domain" instance can use different set of libraries(of > course they can also share the same if the shared code can take care of both > spec level). > I think we have to decide whether we consider composites, written to different spec levels, will be in the same domain or not. I think our default solution is to follow what you say here IIUC. I.e. what was SCADomain is now called a Node and I see that it would be practical to have individual nodes support a single version of the SCA specification. In this scenario the virtual domain, what we now call the domain manager, would still have to deal with composites of all types. In particular when calculating the wiring across the domain we need a consistent model of references, services, policies etc. It may be possible that we can do this through an API that provides service lookup and policy matching features rather than assuming a completely merged model. Having such an API may also help with supporting endpoint resolution from Nodes. The implication of this API based train of thought is that we would, IMHO, be on the "Running and interacting in the same domain" track from (http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Backward+Compatibility) rather than the "Full integration V1.1 reusing V1.0 composite" track. I.e. we could have multiple types of composite in the domain, we would like them to interact with one another over binding.sca but a V1.1 composite couldn't reuse a V1.0 composite. Horizontal but not vertical compatibility if you like. > One other scenario comes to my mind is if we can make OSOA applications as > one implementation type , so we use the SCA way to reuse an OSOA > applications. This way if customer does not want to do a migration, they can > just define OASIS composite definitions to reuse their OSOA application > logics... similar as JEE integration to reuse JEE applications... > Do you mean implementation.osoa here? Certainly a possibility and adds an element of the vertical compatibility missing from above. Would this be the only point of integration? We would have to decide what to do about policy processing if nothing else. Simon
