Re: Registry proposal, was: Delivery Status Notification (Failure)
Thank Jim for such a detailed response. I'll brief update first, then address Jim's concerns inline. A Reference Implementation of WSDL is now available at http://issues.apache.org/jira/secure/attachment/12341187/registry5.zip for JIRA http://issues.apache.org/jira/browse/TUSCANY-677 Please try the live demo at impl/SCA/WSDL/src/test/java/org/apache/tuscany/registry/sca/wsdl/test For your convenience, here's the live demo (helloworld.wsdl): WSDLManager MANAGER = ... (SCA Programming Model) WSDLRegistries WSDL = MANAGER.getWSDLRegistries(null); Definition myDefinition = WSDL.getDefinition(myNameSpace); RegistryMessage messages = WSDL.getMessageRegistry(); Message myMessage = messages.get(myNameSpace, getGreetingsRequest); RegistryPortType interfaces = WSDL.getInterfaceRegistry(); PortType myInterface = interfaces.get(myNameSpace, HelloWorldServiceImpl); RegistryBinding bindings = WSDL.getBindingRegistry(); Binding myBinding = bindings.get(myNameSpace, helloworldSoapBinding); RegistryService services = WSDL.getServiceRegistry(); Service myService = services.get(myNameSpace, HelloWorldServiceImplService); TODOs (impl/SCA/WSDL/src/main/java/org/apache/tuscany/registry/sca/wsdl): CompositeScoping.java, any volunteer to complete the skeleton please? NameSpaceLocator.java, any volunteer to complete the skeleton to locate file from CompositeComponent please? RegistryLoader.java, any volunteer to change to the WSDLReader being used by SCA please? WSDLRegistries.java, any volunteer to compute the context CompositeComponent please? Jim proposed direct providing RegistryMessage||PortType||Binding||Service so that users don't have to WSDL.getXxxRegistry(); any volunteer to support that from SCA please? And any volunteer to make component files for impl/API and impl/SCA/WSDL please? I'm addressing Jim's concerns inline: On 9/19/06, Jim Marino [EMAIL PROTECTED] wrote: Hi Yang, Looking at the implementation, I think there may be a rather large disconnect in our views of what needs to be accomplished. So, I will start by describing what I thought we are and are not trying to do... I thought we were trying to provide a registry which would resolve *WSDL* artifacts to be used by binding (or other) extensions during the build phase as an assembly is processed. These artifacts would be used by the extensions to create appropriate runtime artifacts. The goals of this WSDL registry would be primarily to provide a mechanism where WSDL artifacts could be resolved and processed using a variety of extensible strategies and, secondarily, as a way to cache them (although whether caching produces significant performance gains given typical runtime uses cases is debatable). From an implementation perspective, the registry would rely on the runtime to provide the proper visibility constraints which would alleviate the former from having to provide scoping behavior such as keying on classloader. Tuscany has a DeploymentContext that could be used to hold the registry and maintain proper isolation between composites. Thanks a lot for so concrete requirement. What I thought we were *not* trying to accomplish is to provide a generic registry that caches a variety of artifacts and provides built-in scoping for a number of host environments (e.g. Tuscany, Scoping are not really built-in; a SPI (org.apache.tuscany.registry.spi.Scoping) is required implemented. The Reference Implementation provides the ClassLoader one *just* for Java users' convenience. some tool, etc.). Based on the implementation and things like the package structure (e.g. org.apache.tuscany.registry), I suspect you may disagree with this. From a project perspective, one of my concerns here is that we should not be expanding the charter of Tuscany to include an additional technology category at this point (a generic registry). From a technology perspective, I have the following concerns: - The majority of the implementation appears to offer features not required by the runtime (e.g util, scoping, all of the stuff related to multiple keys in SPI and API) Yes, the Reference Implementation (RI) does provide much more functions than you expected. However, it's better than nothing. At least folks can start to use WSDL Registry whose API is *not* bound to the RI at all. The RI does *not* prevent us from implementing the WSDL Registry API from scratch as you suggested. While folks are able to use the WSDL Registry, we can go for other implementation(s) in parallel. On the other hand, Frank and I talked about the registry the other day and we both think it might be something useful for SDO Type registry (and Global Property registry). And Fuhwei's team needs a registry too. SCA and SDO as one Tuscany team don't have to duplicate similar effort. If it ends up used by no one, and we have a new implementation for the WSDL Registry API already, we can easily throw the RI away and I don't see
Re: Registry proposal, was: Delivery Status Notification (Failure)
Jim, I don't think it should be checked into SDO for the same reasons you mentioned below. SDO needs a Type and (global) Property registry. It would be nice if we could have a simple generic design that could be used for that and also for SCA/WSDL, but maybe that's not possible. Frank. Jim Marino [EMAIL PROTECTED] wrote on 09/20/2006 01:08:56 PM: Comments inline. Frank, in case you miss it below, could you comment on if perhaps Yang's generic registry is something that is more appropriate for checking into SDO? Jim On Sep 20, 2006, at 2:30 AM, Yang ZHONG wrote: Looking at the implementation, I think there may be a rather large disconnect in our views of what needs to be accomplished. So, I will start by describing what I thought we are and are not trying to do... I thought we were trying to provide a registry which would resolve *WSDL* artifacts to be used by binding (or other) extensions during the build phase as an assembly is processed. These artifacts would be used by the extensions to create appropriate runtime artifacts. The goals of this WSDL registry would be primarily to provide a mechanism where WSDL artifacts could be resolved and processed using a variety of extensible strategies and, secondarily, as a way to cache them (although whether caching produces significant performance gains given typical runtime uses cases is debatable). From an implementation perspective, the registry would rely on the runtime to provide the proper visibility constraints which would alleviate the former from having to provide scoping behavior such as keying on classloader. Tuscany has a DeploymentContext that could be used to hold the registry and maintain proper isolation between composites. Thanks a lot for so concrete requirement. What I thought we were *not* trying to accomplish is to provide a generic registry that caches a variety of artifacts and provides built-in scoping for a number of host environments (e.g. Tuscany, Scoping are not really built-in; a SPI (org.apache.tuscany.registry.spi.Scoping) is required implemented. The Reference Implementation provides the ClassLoader one *just* for Java users' convenience. some tool, etc.). Based on the implementation and things like the package structure (e.g. org.apache.tuscany.registry), I suspect you may disagree with this. From a project perspective, one of my concerns here is that we should not be expanding the charter of Tuscany to include an additional technology category at this point (a generic registry). From a technology perspective, I have the following concerns: - The majority of the implementation appears to offer features not required by the runtime (e.g util, scoping, all of the stuff related to multiple keys in SPI and API) Yes, the Reference Implementation (RI) does provide much more functions than you expected. However, it's better than nothing. At least folks can start to use WSDL Registry whose API is *not* bound to the RI at all. The RI does *not* prevent us from implementing the WSDL Registry API from scratch as you suggested. While folks are able to use the WSDL Registry, we can go for other implementation(s) in parallel. I don't believe we should check this code in for the reasons I previously mentioned. IMO we should work on an implementation that fulfills the requirements that I mentioned above, namely something that resolves WSDL artifacts. On the other hand, Frank and I talked about the registry the other day and we both think it might be something useful for SDO Type registry (and Global Property registry). And Fuhwei's team needs a registry too. SCA and SDO as one Tuscany team don't have to duplicate similar effort. If SDO requires a generic registry, perhaps it is best that Frank, Kelvin or one of the other committers working in that area review your patch and decide if it fits their requirements and check it into the SDO subproject? I don't think this should be checked in as a sibling project to SDO, DAS, or SCA as that expands the Tuscany charter. I am also not comfortable with the Java SCA runtime sharing source code between subprojects as we (I should say Jeremy) just spent a lot of time decoupling them. Frank, do you feel this is something that could be checked into SDO? If it ends up used by no one, and we have a new implementation for the WSDL Registry API already, we can easily throw the RI away and I don't see it hurt anything (it will *not* hurt my feeling since I volunteered and it's my interest to help with my experience anyway) I'd prefer we work on a solution that addresses the specific runtime requirements we have without introducing unneeded complexity, keeping in mind YAGNI. - It is difficult to follow and does not appear to be similar to how other extensions are architected (e.g. loaders, builders,
Re: Registry proposal, was: Delivery Status Notification (Failure)
Thank you all for the patience. (I also used the waiting time to assure no huge change to the API and SPI) A Reference Implementation is now available at http://issues.apache.org/jira/secure/attachment/12341070/registry4.zip for JIRA http://issues.apache.org/jira/browse/TUSCANY-677 The implementation has a JavaDoc at impl/SPI/doc and please try the live demo at impl/API/src/test/java/org/apache/tuscany/registry/test demonstrating using SPI to register Locator and loader and using API to get symbol on demand. A WSDL Reference Implementation will be provided next time. -- Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Hi Yang,
I took a review of your prototype and found you are implementing it in Java
5 SDK. Currently SDO impl is on JDK 1.4. Do you plan to support JDK 1.4 for
this registry feature? Thanks.
Fuhwei
Yang ZHONG [EMAIL PROTECTED] wrote: I've updated the registry proposal
basing on Jim's feedback especially his
wonderful runtime-pick-scope idea.
Please see the new attachment at
http://issues.apache.org/jira/secure/attachment/12340483/registry3.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
Thanks, Jim.
For your convenience, here copys some package description from the included
JavaDoc
(Still the included ReadMe.txt may help you find corresponding info)
1. Accessing the registry service
WSDLRegistries WSDL;
@Autowire
public setWSDLRegistries(WSDLRegistries registries)
{
WSDL = registries;
}
2. Accessing Definition identified by Name Space
Definition myDefinition = WSDL.getDefinition(
http://incubator.apache.org/tuscany;);
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Frank and I talked about the registry the other day,
we both think it may be something useful for SDO Type registry (and Global
Property registry).
(Did you suggest that too?)
However, there's no concrete plan to integrate yet.
By the time we actually integrate (if it happens), maybe SDO impl is moving
to Java 5 I hope :-)
Otherwise, I can volunteer myself again for the porting.
BTW, many products including Application Servers has moved to Java 5, they
enable standalone usage of the registry.
Otherwise, I can also volunteer myself again for the porting.
On 9/11/06, Fuhwei Lwo [EMAIL PROTECTED] wrote:
Hi Yang,
I took a review of your prototype and found you are implementing it
in Java 5 SDK. Currently SDO impl is on JDK 1.4. Do you plan to
support JDK 1.4 for this registry feature? Thanks.
Fuhwei
Yang ZHONG [EMAIL PROTECTED] wrote: I've updated the
registry proposal basing on Jim's feedback especially his
wonderful runtime-pick-scope idea.
Please see the new attachment at
http://issues.apache.org/jira/secure/attachment/12340483/registry3.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
Thanks, Jim.
For your convenience, here copys some package description from the
included
JavaDoc
(Still the included ReadMe.txt may help you find corresponding info)
1. Accessing the registry service
WSDLRegistries WSDL;
@Autowire
public setWSDLRegistries(WSDLRegistries registries)
{
WSDL = registries;
}
2. Accessing Definition identified by Name Space
Definition myDefinition = WSDL.getDefinition(
http://incubator.apache.org/tuscany;);
--
Yang ZHONG
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
I've updated the registry proposal basing on Jim's feedback especially his
wonderful runtime-pick-scope idea.
Please see the new attachment at
http://issues.apache.org/jira/secure/attachment/12340483/registry3.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
Thanks, Jim.
For your convenience, here copys some package description from the included
JavaDoc
(Still the included ReadMe.txt may help you find corresponding info)
1. Accessing the registry service
WSDLRegistries WSDL;
@Autowire
public setWSDLRegistries(WSDLRegistries registries)
{
WSDL = registries;
}
2. Accessing Definition identified by Name Space
Definition myDefinition = WSDL.getDefinition(
http://incubator.apache.org/tuscany;);
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
Thanks for your comments, and mine are inline below.
On 9/4/06, Jim Marino [EMAIL PROTECTED] wrote:
Hi Yang, comments inline.
On Sep 4, 2006, at 12:14 PM, Yang ZHONG wrote:
2-1. SPI is not any part of user Programming Model at all, since it's
internal, we can change it any way later.
I'd prefer before we check something in and use it throughout the
code base we sort these issues (SPI, API, WSDL) out as they will
impact a number of bindings.
Fine with me, it's not a bad idea since we have to do it anyway and it saves
some (refactoring) time overall.
Sorry for folks waiting to wait a little longer.
My current reference implementation has no dependency on SCA at
all, it
enables easy development, easy debuging and problems isolation.
Once the implementation is stabilized, we can always have more time
and
resources to refine what granularity to apply SCA.
Where do we intend to house the code? If it is in the Java SCA
project, I'd prefer we only have the capabilities we need and not
build something that is a generic symbol cache. If the code will be
maintained elsewhere, then I would tend to treat it as an external
dependency.
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
- 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 :-)
rantI 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.
An example of inner interface usage is EMF
interface EPackage
{
interface Registry
}
therefore EPackage.Registry is a Registry of EPackages.
I don't really normally argue about interface styles, I've already
changes
SymbolSpace.Registry to SymbolSpaceRegistry in the *new* attachment
as you
suggested before.
If you're talking about NameSpace.xxx, I sure will change them too
in next
update.
Cool. Thanks.
Right, I only documented non-SCA client Programming Model to use the
registry,
I hesitated to include SCA client one because of the requirement
(setRegistry) and the assumption of SCA clients know what to do.
Since you mention it (thank you), I'll also document the SCA client
PM to
use the registry in next update.
O.K., I think it is really simple:
Registry registry;
@Reference
public void setRegistry(Registry registry){
-or-
@Autowire
public void setRegistry(Registry registry){
Thanks a lot. I'll put them into JavaDoc.
If I understand correctly, you concern why multiple dimensions.
A typical scenario is MyApplication.Ear = MyWeb.War + share.jar(
MyService.wsdl) + MyEJB.jar
and the share.jar is shared by both MyWeb and MyEJB.
Some frameworks has an option to check receiving data against
interface,
incuding Java and I know SCA used to have that option.
Checking instance against model may have problems if the model is
loaded as
more than one copies,
Xxx.class and SDO/EMF types all have such problems.
We don't keep the model around during runtime operation so I don't
think this is a problem for us.
I don't know if current SCA ever computs equals, isSuperType and
instanceof
between message/portType/binding/service models.
Even if we did do this, would it ever be done across remote
boundaries (a deployment unit)? At that point we have by-val
semantics (and likely serialization) anyway.
If never, I admit multi-dimension as a generic isuue doesn't have
to be
applied to SCA except for performance concerns
(I've seen real customers sometimes have huge WSDL/XSD files and
loading and
caching them more than once is unecessary pain for customers)
Perhaps we can optimize as needed? If we cache per application, I
don't see this as a huge performance hit. Also, I'd probably want
Re: Registry proposal, was: Delivery Status Notification (Failure)
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 :-) rantI 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
Re: Registry proposal, was: Delivery Status Notification (Failure)
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 :-) rantI 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
Re: Registry proposal, was: Delivery Status Notification (Failure)
Really appreciate your compliment and thanks a lot for your comments.
My comments are below.
On 9/3/06, Jim Marino [EMAIL PROTECTED] wrote:
Hi Yang,
Thanks for your effort on this (the documentation is really
impressive too). I have some more comments based on an initial look:
- There appears to be a number of places static references on
interfaces are used, e.g. SymbolSpace.Registry. Doing this is really
problematic in a managed environment as we have found with SDO and
earlier versions of SCA which used .INSTANCE. As a Java developer I
also find this approach not really intuitive. Is there a technical
reason for doing this?
Maybe the old attachment is confusing, I tried to remove it however I didn't
find a way to do that.
In the new attachment, I've already removed INSTANCE from API, and there's
no INSTANCE in WSDL API.
If you meant SPI, I didn't feel urgent to change right now from two
perspective:
2-1. SPI is not any part of user Programming Model at all, since it's
internal, we can change it any way later.
I intend to focus on API, WSDL API and reference implementations so
that Ant and other folks can use as soon as possible.
Then we can do fine tuning inside the implementations. So I
prioritize SPI changes lower/later than providing something working first.
2-2. There's a granularity to apply SCA. I'm pretty sure about two extremes:
SCA is perfect for service invocation and SCA is not a replacement
for basic programming such as new ArrayList().
For granularities between those two extremes, different people may
have different opinions.
So I prioritize SPI changes lower/later than providing API, WSDL API
and something working first.
My current reference implementation has no dependency on SCA at all, it
enables easy development, easy debuging and problems isolation.
Once the implementation is stabilized, we can always have more time and
resources to refine what granularity to apply SCA.
- 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 :-)
An example of inner interface usage is EMF
interface EPackage
{
interface Registry
}
therefore EPackage.Registry is a Registry of EPackages.
I don't really normally argue about interface styles, I've already changes
SymbolSpace.Registry to SymbolSpaceRegistry in the *new* attachment as you
suggested before.
If you're talking about NameSpace.xxx, I sure will change them too in next
update.
- I don't think we should hardcode component names into interfaces
nor do we need to use locateService() to find a component. Rather, we
should just rely on the container to inject the correct regsitry
instance through autowire into a component as in:
@Autowire
public void setRegistry(Registry myRegistry){
//
}
Right, I only documented non-SCA client Programming Model to use the
registry,
I hesitated to include SCA client one because of the requirement
(setRegistry) and the assumption of SCA clients know what to do.
Since you mention it (thank you), I'll also document the SCA client PM to
use the registry in next update.
Stepping back a bit, I would also like to understand the requirements
of the registry a little better and this is where my ignorance of
WSDL issues will probably show through...Do we need the ability to
cache using multidimensional keys? For example, if we didn't share
symbols across applications, I don't see that as a major performance
issue given the number of WSDLs and applications a typical runtime
instance is going to manage (limited) versus everything else that is
going on including creation of the assembly model and runtime
artifacts (many). Instead, couldn't we just cache by deployed unit?
If I understand correctly, you concern why multiple dimensions.
A typical scenario is MyApplication.Ear = MyWeb.War + share.jar(
MyService.wsdl) + MyEJB.jar
and the share.jar is shared by both MyWeb and MyEJB.
Some frameworks has an option to check receiving data against interface,
incuding Java and I know SCA used to have that option.
Checking instance against model may have problems if the model is loaded as
more than one copies,
Xxx.class and SDO/EMF types all have such problems.
I don't know if current SCA ever computs equals, isSuperType and instanceof
between message/portType/binding/service models.
If never, I admit multi-dimension as a generic isuue doesn't have to be
applied to SCA except for performance concerns
(I've seen real customers sometimes have huge WSDL/XSD files and loading and
caching them more than once is unecessary pain for customers)
To help me understand things a bit better, why would a registry
interface like the one below not work for our purposes (let's assume
for the time being the container can provide the client code
Re: Registry proposal, was: Delivery Status Notification (Failure)
Hi Yang, comments inline.
On Sep 4, 2006, at 12:14 PM, Yang ZHONG wrote:
2-1. SPI is not any part of user Programming Model at all, since it's
internal, we can change it any way later.
I'd prefer before we check something in and use it throughout the
code base we sort these issues (SPI, API, WSDL) out as they will
impact a number of bindings.
My current reference implementation has no dependency on SCA at
all, it
enables easy development, easy debuging and problems isolation.
Once the implementation is stabilized, we can always have more time
and
resources to refine what granularity to apply SCA.
Where do we intend to house the code? If it is in the Java SCA
project, I'd prefer we only have the capabilities we need and not
build something that is a generic symbol cache. If the code will be
maintained elsewhere, then I would tend to treat it as an external
dependency.
- 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 :-)
rantI 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
An example of inner interface usage is EMF
interface EPackage
{
interface Registry
}
therefore EPackage.Registry is a Registry of EPackages.
I don't really normally argue about interface styles, I've already
changes
SymbolSpace.Registry to SymbolSpaceRegistry in the *new* attachment
as you
suggested before.
If you're talking about NameSpace.xxx, I sure will change them too
in next
update.
Cool. Thanks.
Right, I only documented non-SCA client Programming Model to use the
registry,
I hesitated to include SCA client one because of the requirement
(setRegistry) and the assumption of SCA clients know what to do.
Since you mention it (thank you), I'll also document the SCA client
PM to
use the registry in next update.
O.K., I think it is really simple:
Registry registry;
@Reference
public void setRegistry(Registry registry){
-or-
@Autowire
public void setRegistry(Registry registry){
If I understand correctly, you concern why multiple dimensions.
A typical scenario is MyApplication.Ear = MyWeb.War + share.jar(
MyService.wsdl) + MyEJB.jar
and the share.jar is shared by both MyWeb and MyEJB.
Some frameworks has an option to check receiving data against
interface,
incuding Java and I know SCA used to have that option.
Checking instance against model may have problems if the model is
loaded as
more than one copies,
Xxx.class and SDO/EMF types all have such problems.
We don't keep the model around during runtime operation so I don't
think this is a problem for us.
I don't know if current SCA ever computs equals, isSuperType and
instanceof
between message/portType/binding/service models.
Even if we did do this, would it ever be done across remote
boundaries (a deployment unit)? At that point we have by-val
semantics (and likely serialization) anyway.
If never, I admit multi-dimension as a generic isuue doesn't have
to be
applied to SCA except for performance concerns
(I've seen real customers sometimes have huge WSDL/XSD files and
loading and
caching them more than once is unecessary pain for customers)
Perhaps we can optimize as needed? If we cache per application, I
don't see this as a huge performance hit. Also, I'd probably want
things loaded separately in different deployment units as it
simplifies re-deployment and application upgrades. So, I think
caching per application and not multi-dimensionally should be the
starting place.
I see at least 3 areas WSDLManager can improve (besides the multi-
dimension
issue):
3-1. It's nice the WSDLManager supports location(String/URL) Scoping.
however it doesn't seem supporting other Scoping such as
CompositeComponent
Particularly, it's a problem when wsdlLocation/scdlLocation is
absent
3-2. Scope delegation is not mentioned at all. e.g. a location
query should
be able to be delegated to all included location,
and a CompositeComponent query should be able to be delegated
to all
included CompositeComponent
Perhaps we can make this the job of the runtime? In other words, just
as SCA does not require applications to track instances and has a
concept of Scope, we could do the same for the registry. This would
mean client code requests a registry from the runtime and the runtime
resolves the correct one:
@Autowire
public void setRegistry(Registry
Re: Registry proposal, was: Delivery Status Notification (Failure)
Hi Yang,
Thanks for your effort on this (the documentation is really
impressive too). I have some more comments based on an initial look:
- There appears to be a number of places static references on
interfaces are used, e.g. SymbolSpace.Registry. Doing this is really
problematic in a managed environment as we have found with SDO and
earlier versions of SCA which used .INSTANCE. As a Java developer I
also find this approach not really intuitive. Is there a technical
reason for doing this?
- 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.
- I don't think we should hardcode component names into interfaces
nor do we need to use locateService() to find a component. Rather, we
should just rely on the container to inject the correct regsitry
instance through autowire into a component as in:
@Autowire
public void setRegistry(Registry myRegistry){
//
}
Stepping back a bit, I would also like to understand the requirements
of the registry a little better and this is where my ignorance of
WSDL issues will probably show through...Do we need the ability to
cache using multidimensional keys? For example, if we didn't share
symbols across applications, I don't see that as a major performance
issue given the number of WSDLs and applications a typical runtime
instance is going to manage (limited) versus everything else that is
going on including creation of the assembly model and runtime
artifacts (many). Instead, couldn't we just cache by deployed unit?
To help me understand things a bit better, why would a registry
interface like the one below not work for our purposes (let's assume
for the time being the container can provide the client code with the
correct manager instance scoped to a deployment unit/classloader)?
http://celtix.objectweb.org/docs/api/org/objectweb/celtix/wsdl/
WSDLManager.html
Again, thanks for all your effort.
Jim
On Sep 2, 2006, at 12:28 PM, Yang ZHONG wrote:
I've updated the registry proposal basing on feedbacks (thank everyone
especially Jeremy and Jim) and some time to refine diagrams and
examples/samples,
and proposed a WSDL Registry (thank Jeremy for strong-interface
suggestion).
Please see the new attachment at
http://issues.apache.org/jira/secure/attachment/12340097/registry.zip
for JIRA
http://issues.apache.org/jira/browse/TUSCANY-677
It seemed easy to overlook ReadMe.txt and miss some info already
provided,
so please spend a little time on diagrams and examples/samples if
possible.
The major change is the API Programming Model from
SymbolSpace.Registry.INSTANCE
to
CurrentCompositeContext.getContext().locateService(
SymbolSpaceRegistry.class, SymbolSpaceRegistry.SERVICE)
Thank Ant for detailed info.
I've tried not to involve Scoping in the WSDL Registry, so the API
doesn't
mention Scoping at all.
However, a scope notation is still used in WSDLRegistry to make
the API
practically useful.
But I've left the signature to be Object to be flexible/open enough.
Although the WSDL Registry proposal doesn't cover Scoping, it's not
really
necessarily too early to discuss Scoping,
so that we might have a little bit more thorough thinking/
discussion about
Scoping before the eventual approach adopting.
I see at least 3 kinds of scenario (examples assume WSDLRegistries
WSDL =
CurrentCompositeContext.getContext().locateService
( WSDLRegistries.class,
WSDLRegistries.SERVICE)):
3-1. Designated WSDL location.
Users may need Message/PortType/Binding/Service/Definition lookup
to be
scoped by the designated location,
and recursively delegated to all included locations. e.g. (location
dimension/Scoping)
WSDL.getInterfaceRegistry(
FTP://hosting.org/WSDL/vertical.wsdlftp://hosting.org/WSDL/
vertical.wsdl
)
3-2. Absent WSDL location with designated CompositeComponent (thank
Raymond
for explaining me Composite).
Users may need Message/PortType/Binding/Service/Definition lookup
to be
scoped by the designated CompositeComponent,
and recursively delegated to all included CompositeComponents. e.g.
(CompositeComponent Scoping)
WSDL.getBindingRegistry( compositeComponent)
3-3. Nothing designated.
Users may need Message/PortType/Binding/Service/Definition lookup
to be
scoped by context.
I don't know SCA confident enough yet to propose anything, however
I hope
you don't mind me sharing that I feel CompositeComponent is a natural
context Scoping for SCA.
If that's the approach adopted, the lookup may need to be scoped by
the
context CompositeComponent and recursively delegated to all included
CompositeComponents. e.g. (no matter what context Scoping ends up
being
adopted)
WSDL.getServiceRegistry( null)
For either 3-2 or 3-3, we may need something like:
static Scoping COMPOSITE_SCOPING = new ScopingCompositeComponent()
{
public IterableCompositeComponent
Re: Registry proposal, was: Delivery Status Notification (Failure)
Hi, Please see my comments in line. Thanks, Raymond - Original Message - From: Jeremy Boynes [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, August 30, 2006 8:19 AM Subject: Registry proposal, was: Delivery Status Notification (Failure) I might be missing something as well but I didn't see any code under impl at all I guess it's for the API/SPI review first. I'm also with Ant in thinking we should not have a dependency on EMF. From the javadoc, I don't see the EMF dependencies. I'd also add that I found it difficult to grok the relationships between all the interfaces and inner-interfaces and how the behaviour would integrate with Map semantics - for example, how does this differ from just using strongly-typed Maps? I agree. If the interface is designed for public API/SPI, it should be first-class interface instead of being inner. I'm also seeing a lot of naming conflicts among API and SPI interfaces/classes/parameterized types. This seems to be very problematic to me. When we run out of names, it means to me we don't model it correctly. A class diagram would be of great help for us. I'm also not convinced that throwing everything (all types of stuff) into one central registry model is a good way to go. I can see a lot of benefit in having more specialized interfaces tailored for each type of stuff. I guess we can reuse the same infrastrcture backed by the generic registry but provide more specialized interfaces on top of it. And we can also choose to have separate instances of registries for specific domains. -- Jeremy On Aug 30, 2006, at 4:10 AM, ant elder wrote: Having this attached to a JIRA is fine, thats preferred over sending attachments to the dev list. Thanks for all this, I've only just started looking but it looks very comprehensive, a lot more than I was expecting 8-). I've a few questions so far. Firstly you didn't click the button granting license of the code to the ASF, was that an oversight? The readme talks about some test examples and samples showing how to use the registry but the test folders don't seem to be included in the zip? From the brief look it wasn't clear to me if the registry will require EMF, hopefully it doesn't? Thanks, ...ant On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote: Neither tuscany-dev nor infra takes my email with attachment, so I've attached file for review into http://issues.apache.org/jira/browse/TUSCANY-677 Sorry for the inconvenience and thanks for any comment. On 8/30/06, Mail Delivery Subsystem [EMAIL PROTECTED] wrote: This is an automatically generated Delivery Status Notification Delivery to the following recipient failed permanently: [EMAIL PROTECTED] Technical details of permanent failure: PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it is spam (body) - Original message - Received: by 10.35.31.14 with SMTP id i14mr634348pyj; Wed, 30 Aug 2006 03:06:43 -0700 (PDT) Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41 -0700 (PDT) Message-ID: [EMAIL PROTECTED] Date: Wed, 30 Aug 2006 03:06:41 -0700 From: Yang ZHONG [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Subject: Re: Auto discovering WSDL Cc: [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary==_Part_28704_31437365.1156932401933 References: [EMAIL PROTECTED] ems2.IONAGLOBAL.COM [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] --=_Part_28704_31437365.1156932401933 Content-Type: multipart/alternative; boundary==_Part_28705_19724073.1156932401933 --=_Part_28705_19724073.1156932401933 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Could you please review the registry API and SPI? - Message truncated - -- Yang ZHONG - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
Raymond guessed right that it's an API/SPI review, so no impl/tests attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification (Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency on EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour would
integrate with Map semantics - for example, how does this differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very problematic
to
me. When we run out of names, it means to me we don't model it correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a lot of
benefit in having more specialized interfaces tailored for each type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic registry
but provide more specialized interfaces on top of it. And we can also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of the code
to
the
ASF, was that an oversight? The readme talks about some test examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment, so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem [EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
is spam
(body)
- Original message -
Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
-0700
(PDT)
Message-ID:
[EMAIL PROTECTED]
Date: Wed, 30 Aug 2006 03:06:41 -0700
From: Yang ZHONG [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL
Cc: [EMAIL PROTECTED]
In-Reply-To:
[EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary==_Part_28704_31437365.1156932401933
References:
[EMAIL PROTECTED]
ems2.IONAGLOBAL.COM
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
--=_Part_28704_31437365.1156932401933
Content-Type: multipart/alternative;
boundary==_Part_28705_19724073.1156932401933
--=_Part_28705_19724073.1156932401933
Re: Registry proposal, was: Delivery Status Notification (Failure)
I had one additional comment: is there a reason we have to use the
.INSTANCE approach to locating the default Provider?
Jim
On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
Raymond guessed right that it's an API/SPI review, so no impl/tests
attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be not
thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for
following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have
info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling
point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/
fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this
registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification
(Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency on
EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour
would
integrate with Map semantics - for example, how does this
differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it
should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very
problematic
to
me. When we run out of names, it means to me we don't model it
correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a lot of
benefit in having more specialized interfaces tailored for each
type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic
registry
but provide more specialized interfaces on top of it. And we can also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over
sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it
looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of
the code
to
the
ASF, was that an oversight? The readme talks about some test
examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to
me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment,
so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem mailer-
[EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected as it
is spam
(body)
- Original message -
Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
-0700
(PDT)
Message-ID:
[EMAIL PROTECTED]
Date: Wed, 30 Aug 2006 03:06:41 -0700
From: Yang ZHONG [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL
Cc: [EMAIL PROTECTED]
In-Reply-To:
[EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary==_Part_28704_31437365.1156932401933
References:
[EMAIL PROTECTED]
ems2.IONAGLOBAL.COM
[EMAIL
Re: Registry proposal, was: Delivery Status Notification (Failure)
I don't think we need Provider at all.
--
Jeremy
On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
I had one additional comment: is there a reason we have to use the
.INSTANCE approach to locating the default Provider?
Jim
On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
Raymond guessed right that it's an API/SPI review, so no impl/
tests attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be
not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for
following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have
info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling
point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/
fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this
registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification
(Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency
on EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour
would
integrate with Map semantics - for example, how does this
differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it
should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very
problematic
to
me. When we run out of names, it means to me we don't model it
correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a
lot of
benefit in having more specialized interfaces tailored for
each type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic
registry
but provide more specialized interfaces on top of it. And we can
also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over
sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it
looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of
the code
to
the
ASF, was that an oversight? The readme talks about some test
examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to
me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment,
so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem mailer-
[EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status
Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected
as it
is spam
(body)
- Original message -
Received: by 10.35.31.14 with SMTP id i14mr634348pyj;
Wed, 30 Aug 2006 03:06:43 -0700 (PDT)
Received: by 10.35.103.13 with HTTP; Wed, 30 Aug 2006 03:06:41
-0700
(PDT)
Message-ID:
[EMAIL PROTECTED]
Date: Wed, 30 Aug 2006 03:06:41 -0700
From: Yang ZHONG [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Subject: Re: Auto discovering WSDL
Cc: [EMAIL PROTECTED]
In-Reply-To:
[EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary
Re: Registry proposal, was: Delivery Status Notification (Failure)
I'm fine with other service locating mechanisms, please name one and I'll
update.
Please keep little dependency. If the other mechanism(s) has dependency more
than just J2SE such as SCA, JNDI repository,
may be we can have several mechanism coexisted target various requirement...
Thanks again for comments.
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I don't think we need Provider at all.
--
Jeremy
On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
I had one additional comment: is there a reason we have to use the
.INSTANCE approach to locating the default Provider?
Jim
On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
Raymond guessed right that it's an API/SPI review, so no impl/
tests attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be
not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for
following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have
info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are sometimes
preferred.
Actually, generalization and extensibility is exactly the selling
point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/
fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this
registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification
(Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency
on EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour
would
integrate with Map semantics - for example, how does this
differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it
should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very
problematic
to
me. When we run out of names, it means to me we don't model it
correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a
lot of
benefit in having more specialized interfaces tailored for
each type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic
registry
but provide more specialized interfaces on top of it. And we can
also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over
sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it
looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of
the code
to
the
ASF, was that an oversight? The readme talks about some test
examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to
me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment,
so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem mailer-
[EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status
Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 Message rejected
as it
is spam
(body)
- Original message -
Received: by 10.35.31.14 with SMTP id i14mr634348pyj
Re: Registry proposal, was: Delivery Status Notification (Failure)
As part of Tuscany there should not be any mechanism in a API for
service location - that is the responsibility of the IoC container.
--
Jeremy
On Aug 30, 2006, at 10:43 AM, Yang ZHONG wrote:
I'm fine with other service locating mechanisms, please name one
and I'll
update.
Please keep little dependency. If the other mechanism(s) has
dependency more
than just J2SE such as SCA, JNDI repository,
may be we can have several mechanism coexisted target various
requirement...
Thanks again for comments.
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I don't think we need Provider at all.
--
Jeremy
On Aug 30, 2006, at 9:59 AM, Jim Marino wrote:
I had one additional comment: is there a reason we have to use the
.INSTANCE approach to locating the default Provider?
Jim
On Aug 30, 2006, at 9:39 AM, Yang ZHONG wrote:
Raymond guessed right that it's an API/SPI review, so no impl/
tests attached
yet although I have some impl already.
Ant guessed right too that I forgot to grant license, I must be
not thinking
straight working late :-)
I don't see any link to post-grant, I'll remember to do that for
following
attachments. Thank Ant.
There's neither* EMF *nor* Eclipse dependency. impl/EMF and impl/
Eclipse
are just subproject targeting certain usage.
Please take a look at ReadMe.txt for more details, it also have
info to find
Class Diagram and others.
I agree with Jeremy that strongly-typed Maps/interfaces are
sometimes
preferred.
Actually, generalization and extensibility is exactly the selling
point of
this generic registry.
Tailoring can be done based on the framework/infrastructure/
fundation (as
Raymond commented).
There're at least two ways to provide strong interfaces over this
registry.
2-1. Delegating
new StrongInterface()
{
public MySymbol getMySymbol (QName qName)
{
return mySymbolSpace.resolve( qName);
}
}
2-2. Extending
class StrongInterfaceImpl extends SymbolSpaceImpl implement
StrongInterface
Thank everyone for all comments.
On 8/30/06, Raymond Feng [EMAIL PROTECTED] wrote:
Hi,
Please see my comments in line.
Thanks,
Raymond
- Original Message -
From: Jeremy Boynes [EMAIL PROTECTED]
To: tuscany-dev@ws.apache.org
Sent: Wednesday, August 30, 2006 8:19 AM
Subject: Registry proposal, was: Delivery Status Notification
(Failure)
I might be missing something as well but I didn't see any code
under impl
at all
I guess it's for the API/SPI review first.
I'm also with Ant in thinking we should not have a dependency
on EMF.
From the javadoc, I don't see the EMF dependencies.
I'd also add that I found it difficult to grok the
relationships between
all the interfaces and inner-interfaces and how the behaviour
would
integrate with Map semantics - for example, how does this
differ from
just using strongly-typed Maps?
I agree. If the interface is designed for public API/SPI, it
should be
first-class interface instead of being inner.
I'm also seeing a lot of naming conflicts among API and SPI
interfaces/classes/parameterized types. This seems to be very
problematic
to
me. When we run out of names, it means to me we don't model it
correctly.
A class diagram would be of great help for us.
I'm also not convinced that throwing everything (all types of
stuff) into
one central registry model is a good way to go. I can see a
lot of
benefit in having more specialized interfaces tailored for
each type of
stuff.
I guess we can reuse the same infrastrcture backed by the generic
registry
but provide more specialized interfaces on top of it. And we can
also
choose
to have separate instances of registries for specific domains.
--
Jeremy
On Aug 30, 2006, at 4:10 AM, ant elder wrote:
Having this attached to a JIRA is fine, thats preferred over
sending
attachments to the dev list.
Thanks for all this, I've only just started looking but it
looks very
comprehensive, a lot more than I was expecting 8-). I've a
few questions
so
far. Firstly you didn't click the button granting license of
the code
to
the
ASF, was that an oversight? The readme talks about some test
examples
and
samples showing how to use the registry but the test folders
don't seem
to
be included in the zip? From the brief look it wasn't clear to
me if
the
registry will require EMF, hopefully it doesn't?
Thanks,
...ant
On 8/30/06, Yang ZHONG [EMAIL PROTECTED] wrote:
Neither tuscany-dev nor infra takes my email with attachment,
so I've
attached file for review into
http://issues.apache.org/jira/browse/TUSCANY-677
Sorry for the inconvenience and thanks for any comment.
On 8/30/06, Mail Delivery Subsystem mailer-
[EMAIL PROTECTED]
wrote:
This is an automatically generated Delivery Status
Notification
Delivery to the following recipient failed permanently:
[EMAIL PROTECTED]
Technical details
Re: Registry proposal, was: Delivery Status Notification (Failure)
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote: As part of Tuscany there should not be any mechanism in a API for service location - that is the responsibility of the IoC container. +1 (which nicely avoids external dependencies on some locator implementation and evil Singletons) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service locating.
I hope I can learn from that practice and update the registry generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API for
service location - that is the responsibility of the IoC container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
In case its not completely clear from Jeremy and Jim's emails what to do: you could define a client interface for the registry, write an implementation of that and define that impl class name in some scdl. We can then include the scdl in the runtime and things could use autowire to get hold of the registry instance. As and example of this you can look at our ServletHost, ServletHostImpl, how thats defined in the web app scdl, and then how thats used by the Axis2 binding: http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/spi/src/main/java/org/apache/tuscany/spi/host/ServletHost.java http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/webapp-host/src/main/java/org/apache/tuscany/runtime/webapp/ServletHostImpl.java http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/runtime/webapp-host/src/main/resources/META-INF/sca/webapp.system.scdl http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/bindings/binding.axis2/src/main/java/org/apache/tuscany/binding/axis2/Axis2BindingBuilder.java ...ant On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote: On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote: As part of Tuscany there should not be any mechanism in a API for service location - that is the responsibility of the IoC container. +1 (which nicely avoids external dependencies on some locator implementation and evil Singletons) -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service locating.
I hope I can learn from that practice and update the registry
generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API for
service location - that is the responsibility of the IoC
container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
Thank Ant so much for details, that's very helpful!
I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry implementation in
JavaDoc
SymbolSpace.Registry is the generic registry interface, it doesn't prevent
us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or anything else?
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service locating.
I hope I can learn from that practice and update the registry
generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API for
service location - that is the responsibility of the IoC
container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
On Aug 30, 2006, at 11:59 AM, Yang ZHONG wrote:
Thank Ant so much for details, that's very helpful!
I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry
implementation in
JavaDoc
Why do we have the inner interface? I agree with Jeremy that it
doesn't seem very intuitive.
SymbolSpace.Registry is the generic registry interface, it doesn't
prevent
us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone
tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or
anything else?
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service
locating.
I hope I can learn from that practice and update the registry
generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API
for
service location - that is the responsibility of the IoC
container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Registry proposal, was: Delivery Status Notification (Failure)
No problem, consider them removed in API.
Sorry, what's the WSDL model used in SCA again please?
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 11:59 AM, Yang ZHONG wrote:
Thank Ant so much for details, that's very helpful!
I'll update the API:
2-1. remove INSTANCE
2-2. demonstrate the SCA way to get SymbolSpace.Registry
implementation in
JavaDoc
Why do we have the inner interface? I agree with Jeremy that it
doesn't seem very intuitive.
SymbolSpace.Registry is the generic registry interface, it doesn't
prevent
us from having SCA specific interface(s).
I can come up with a WSDL Registry interface proposal. Can someone
tell me
which model is used by SCA: WST, WSDL4J, EMF, home grown or
anything else?
On 8/30/06, Jeremy Boynes [EMAIL PROTECTED] wrote:
I'm having trouble parsing this. Are you talking about an SCA
registry, or a WSDL registry, or the mechanism for locating it (via
IoC as Ant described or something else)?
I was saying that in an IoC world there is /no/ provider part of the
API - a user never locates anything, they declare dependencies and
the container resolves them. The dependency would be on the actual
client interface (SymbolSpace.Registry I guess but I've already
admitted to not grokking the interfaces).
--
Jeremy
On Aug 30, 2006, at 11:28 AM, Yang ZHONG wrote:
Can someone propose a SCA specific API mentioned by Jeremy please?
Something like
interface ScaRegistry
{
Definition getDefinition (String nameSpace);
Message getMessage (QName);
}
I don't know the SCA requirement much enough to make such proposal.
At the same time, we can practise IoC in ScaRegistry service
locating.
I hope I can learn from that practice and update the registry
generic API
accordingly.
Thanks for pointing out a nice mechanism.
On 8/30/06, Jim Marino [EMAIL PROTECTED] wrote:
On Aug 30, 2006, at 10:49 AM, Jeremy Boynes wrote:
As part of Tuscany there should not be any mechanism in a API
for
service location - that is the responsibility of the IoC
container.
+1 (which nicely avoids external dependencies on some locator
implementation and evil Singletons)
--
Jeremy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Yang ZHONG
Re: Registry proposal, was: Delivery Status Notification (Failure)
On Aug 30, 2006, at 12:20 PM, Yang ZHONG wrote: No problem, consider them removed in API. Sorry, what's the WSDL model used in SCA again please? We don't really model WSDL. We do parse it using WSDL4J for now but need something to support WSDL2.0 (probably Woden when it can support 1.1). -- Jeremy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
