You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Glen Daniels <gl...@thoughtcraft.com> on 2005/09/13 18:25:45 UTC

[axis2] Namespaces aren't necessary for our component registry

Hi all:

I think we should adjust the AxisConfiguration class to refer to 
components (services, modules) by simple string names and not by QNames.

First off, when you define a service in service.xml, the name is a 
string.  Obviously the file-based naming for services also uses strings. 
   Ditto for modules.

Clearly WSDL defines QNames for services, and any individual Axis 
service deployment should be able to *map* to a particular WSDL QName, 
but in terms of our deployment registry we should be referring to things 
by string names most of the time.

The actual changes I'm talking about would include:

* Change method accessors in AxisConfiguration to use Strings
* Keep getService(QName), which would look up a service by its WSDL
   <service> QName instead of by its Axis deployment name

This serves to simplify lookups, make it easier to write tools, increase 
developer comprehension of what's going on, and make it clearer how 
things like URL based dispatching work.

Thoughts?

--Glen

Re: [axis2] Namespaces aren't necessary for our component registry

Posted by Eran Chinthaka <ch...@opensource.lk>.
Yeah, I'm working on this but didn't dig in to this that deeper to 
figure out to see whether Glen's suggestions are feasible.
.
Give me some time to finish the service group stuff and get back to this.


Sanjiva Weerawarana wrote:

>+1! I think Eran is working on some stuff related to this already??
>
>Sanjiva.
>
>On Tue, 2005-09-13 at 12:25 -0400, Glen Daniels wrote:
>  
>
>>Hi all:
>>
>>I think we should adjust the AxisConfiguration class to refer to 
>>components (services, modules) by simple string names and not by QNames.
>>
>>First off, when you define a service in service.xml, the name is a 
>>string.  Obviously the file-based naming for services also uses strings. 
>>   Ditto for modules.
>>
>>Clearly WSDL defines QNames for services, and any individual Axis 
>>service deployment should be able to *map* to a particular WSDL QName, 
>>but in terms of our deployment registry we should be referring to things 
>>by string names most of the time.
>>
>>The actual changes I'm talking about would include:
>>
>>* Change method accessors in AxisConfiguration to use Strings
>>* Keep getService(QName), which would look up a service by its WSDL
>>   <service> QName instead of by its Axis deployment name
>>
>>This serves to simplify lookups, make it easier to write tools, increase 
>>developer comprehension of what's going on, and make it clearer how 
>>things like URL based dispatching work.
>>
>>Thoughts?
>>
>>--Glen
>>    
>>
>
>
>  
>

Re: [axis2] Namespaces aren't necessary for our component registry

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
+1! I think Eran is working on some stuff related to this already??

Sanjiva.

On Tue, 2005-09-13 at 12:25 -0400, Glen Daniels wrote:
> Hi all:
> 
> I think we should adjust the AxisConfiguration class to refer to 
> components (services, modules) by simple string names and not by QNames.
> 
> First off, when you define a service in service.xml, the name is a 
> string.  Obviously the file-based naming for services also uses strings. 
>    Ditto for modules.
> 
> Clearly WSDL defines QNames for services, and any individual Axis 
> service deployment should be able to *map* to a particular WSDL QName, 
> but in terms of our deployment registry we should be referring to things 
> by string names most of the time.
> 
> The actual changes I'm talking about would include:
> 
> * Change method accessors in AxisConfiguration to use Strings
> * Keep getService(QName), which would look up a service by its WSDL
>    <service> QName instead of by its Axis deployment name
> 
> This serves to simplify lookups, make it easier to write tools, increase 
> developer comprehension of what's going on, and make it clearer how 
> things like URL based dispatching work.
> 
> Thoughts?
> 
> --Glen