ok, I'll propose a WSDL API similar to Celtix. On 9/5/06, Jim Marino <[EMAIL PROTECTED]> wrote:
On Sep 5, 2006, at 11:22 AM, Yang ZHONG wrote: > > I've proposed hosting the registry dircetly under tuscany/java: > distribution > *registry* > sdo > spec > sca > The rational is we are dealing with generic issues beyond just sca > and sdo > anyway, > especially I know some SDO implementations are using registry for > types (and > elements). > There's one thing I don't even have preference myself at all: where > to host > the tailoring for sca. > It can either be > tuscany/java/registry/sca > or > tuscany/java/sca/registry Can we first try and solve the specific issue of WSDL loading and then see if we can make something generic? It feels as if a "one-size- fits-all" approach is going to introduce complexity we don't need in the SCA runtime. Also, doing this potentially introduces dependencies between the projects which was what we just eliminated and which I would not want to reintroduce. >> >> > - It also seems a lot of inner interfaces are used. I think things >> >> could be simplified by not using inner interfaces at all, possibly >> >> segregating classes using subpackages if necessary. >> > >> > >> > Some people find inner interface helpful and better readable, >> > I think the Java spec wouldn't include it if it's a absolute >> evil :-) >> <rant>I think statics on interfaces like .INSTANCE are evil. >> Thankfully, they are not widely used in Java technologies I am aware >> of (outside SDO and EMF) as they cause so many problems in managed >> environments where classloader isolation is important. ;-) I honestly >> don't understand how this pattern is easier to use as there are >> simple alternatives Java developers are familiar with such as IoC and >> factories. </rant> > > > The above paragraph was talking about inner interface, *not* > singleton. > I understand singleton causes management difficulties although it > makes > simplest/easiest Programming Model. > There's no singleton in API and WSDL API already. > I don't see you say inner interfaces are evil, however I can guess > they're > not your preference and I sure will replace them in API and SPI. > Sorry to be so adamant but static references to implementation classes on interfaces have caused me a lot of grief in the past. On the "inner" interface issue I think it is more common to use Java packages, so thanks for accommodating this. > > > Brilliant idea! Using the WSDL API as example, we can offer > definition/message/portType/binding/service Registry > directly to SCA contained component exactly the way you mentioned, > and offer scope aware WSDLRegistries to non SCA-contained or low/ > system > level programming. > I think we can simplify this even further: we just offer a WSDL registry that is held in the DeploymentContext and thrown away after the deployment process. We don't need the registry to manage any scoping as that is done by the runtime. Jeremy suggested this a while back, I believe. In this case, we would have a loader that would process <import.wsdl> and create the registry if needed, putting it in the DeploymentContext. Subsequent requests would key off that. At the end of the deployment process, the DeploymentContext is thrown away so we don't have to worry about the cache managing references to classloaders or having to implement complex scoping algorithms. >> 3-3. message/portType/binding/service may not necessarily reside in >> > current >> > Definition, they may be available from included/delegated >> Definitions. >> > Without direct API to query message/portType/binding/service, >> > users >> > have to query current Definition first, >> > then manually and recursively query all included/delegated >> > Definitions, >> > which is quite error-prone.. >> Could we provide a utility method or just modify the api to do this? >> Jervis or Dan, how does Celtix handle this? >> > >> As a way to move forward, do you think we could assume for the time >> being the runtime can handle resolving the correct registry instance >> and we take the Celtix API and merge it with the API you are >> proposing? > > > Are you fine/satisfied with the Celtix (WSDL) API? If so, I can put > a hold > on my efforts since I guess the Celtix (WSDL) API has an > implementation > already. > I remember someone mentioned a SCDL registry before. If you think > SCDL could > use a registry too, I can keep on the registry efforts. > Please let me know. I don't think we need a SCDL registry but I definitely think you should keep working on the WSDL registry since we do need one. I took Celtix as an example since it seemed intuitive. Perhaps a good way forward is to look at their API and make some of the modifications you suggested? Then, once we are satisfied with the API, we look at how to best implement it. I would start with the assumption that we just need a WSDL registry since I can't think of other model artifacts that need to be cached right now (there may be in the future but then we will have more use cases to work from). I'd also start with the assumption that scoping will be handled by the runtime, in this case the deployment context, and that model artifacts are thrown away after deployment and not used during invocation processing. Does this work? Jim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Yang ZHONG
