javajunky
11-07-2007, 11:51 AM
Hi guys,
I've been cheerfully using the WebServiceExporter for several months now, but I've recently realised that I made a bit of an architectural boo-boo, and have a need to de-couple the *url* for a web-service from its bean id/name.
Just as a recap, the current definition (grossly cut-down):
<object name="UserService_implementation" type="MyType/>
<object name="UserService" type="Spring.Web.Services.WebServiceExporter, Spring.Web>
<property name="TargetName" value="UserService_implementation"/>
</object>
Exposes a web-service of the form
http://myhost/UserService.asmx
Which is great, and exactly what I wanted! *However* just recently I've wanted (so that I could just explicitly and easily dependencies between 'services' [gah!] ) to do something like the following:
<object name="UserService" type="MyType/>
<object name="UserService_WebService" type="Spring.Web.Services.WebServiceExporter, Spring.Web>
<property name="TargetName" value="UserService"/>
</object>
Note the subtle differences between the two configurations, this [fairly obviously, given the last example], responds to a url of the form:
http://myhost/UserService_WebService.asmx
*HOWEVER* I would like to be able to expose the *bean* named 'UserService_WebService' as the service 'UserService.asmx'.
So, reading the documentation I see the 'Name' property, a-hah I read from the documentation:
The web service name. (defaults to the object id)
So I change this property to be the name I want the service to be exposed as ;) :
<object name="UserService" type="MyType/>
<object name="UserService_WebService" type="Spring.Web.Services.WebServiceExporter, Spring.Web>
<property name="TargetName" value="UserService"/>
<property name="Name" value="UserService"/>
</object>
But :( unfortunately the web-service is still 'exposed' as UserService_WebService.asmx, (however the WSDL etc. does take into account this 'Name' property.
On further [basic] examination I realise the 'issue' I'm seeing is because the WebServiceHandlerFactory directly maps the URL straight to the bean name and ignores the 'Name' property entirely e.g:
if (appContext.ContainsObjectDefinition(serviceName))
{
serviceType = appContext.GetType(serviceName);
// check if the type defines a Web Service
object[] wsAttribute = serviceType.GetCustomAttributes(typeof(WebServiceA ttribute), true);
if (wsAttribute.Length == 0)
{
serviceType = null;
}
}
Now I *get* why this is done (clearly its a fast way of doing it), but would it not be a lot more flexible to de-couple the url from the actual object definition name, and use appContext.GetObjectsOfType(typeof(WebServiceExpor ter)), then iterate over the 'Name' property of these objects ? .. I imagine there would be a penalty in terms of in-advertantly early-initialising these objects, so I guess you could do it on the definitions rather than the objects themselves, I'm ok here locally as I've actually re-implemented the WebServiceHandlerfActory locally to work properly with asynchronous web services as I got frustrated with running out of threads in IIS (stupid stupid thread-pool implementation), but just thought I'd ask the question in case a) My approach is suicide or b)Its a minor over-sight ?
I've been cheerfully using the WebServiceExporter for several months now, but I've recently realised that I made a bit of an architectural boo-boo, and have a need to de-couple the *url* for a web-service from its bean id/name.
Just as a recap, the current definition (grossly cut-down):
<object name="UserService_implementation" type="MyType/>
<object name="UserService" type="Spring.Web.Services.WebServiceExporter, Spring.Web>
<property name="TargetName" value="UserService_implementation"/>
</object>
Exposes a web-service of the form
http://myhost/UserService.asmx
Which is great, and exactly what I wanted! *However* just recently I've wanted (so that I could just explicitly and easily dependencies between 'services' [gah!] ) to do something like the following:
<object name="UserService" type="MyType/>
<object name="UserService_WebService" type="Spring.Web.Services.WebServiceExporter, Spring.Web>
<property name="TargetName" value="UserService"/>
</object>
Note the subtle differences between the two configurations, this [fairly obviously, given the last example], responds to a url of the form:
http://myhost/UserService_WebService.asmx
*HOWEVER* I would like to be able to expose the *bean* named 'UserService_WebService' as the service 'UserService.asmx'.
So, reading the documentation I see the 'Name' property, a-hah I read from the documentation:
The web service name. (defaults to the object id)
So I change this property to be the name I want the service to be exposed as ;) :
<object name="UserService" type="MyType/>
<object name="UserService_WebService" type="Spring.Web.Services.WebServiceExporter, Spring.Web>
<property name="TargetName" value="UserService"/>
<property name="Name" value="UserService"/>
</object>
But :( unfortunately the web-service is still 'exposed' as UserService_WebService.asmx, (however the WSDL etc. does take into account this 'Name' property.
On further [basic] examination I realise the 'issue' I'm seeing is because the WebServiceHandlerFactory directly maps the URL straight to the bean name and ignores the 'Name' property entirely e.g:
if (appContext.ContainsObjectDefinition(serviceName))
{
serviceType = appContext.GetType(serviceName);
// check if the type defines a Web Service
object[] wsAttribute = serviceType.GetCustomAttributes(typeof(WebServiceA ttribute), true);
if (wsAttribute.Length == 0)
{
serviceType = null;
}
}
Now I *get* why this is done (clearly its a fast way of doing it), but would it not be a lot more flexible to de-couple the url from the actual object definition name, and use appContext.GetObjectsOfType(typeof(WebServiceExpor ter)), then iterate over the 'Name' property of these objects ? .. I imagine there would be a penalty in terms of in-advertantly early-initialising these objects, so I guess you could do it on the definitions rather than the objects themselves, I'm ok here locally as I've actually re-implemented the WebServiceHandlerfActory locally to work properly with asynchronous web services as I got frustrated with running out of threads in IIS (stupid stupid thread-pool implementation), but just thought I'd ask the question in case a) My approach is suicide or b)Its a minor over-sight ?