WebServiceProxyFactory with proxied objects

[valdis99]

Is it possible to expose a proxied object via the WebServiceProxyFactory? It looks like you can only specific the ProxyClass, which is the Type name, not an Object name or a reference to an Object.

Why would I want to do this? Here's the scenario:

We are using the WSE 2.0 package to invoke web services, mainly for WS-Security. When VS.NET generates the source, it creates 2 classes -- one for WSE and the standard non-WSE one. I've successfully used the WebServiceProxyFactory to wrap both objects behind a single interface, and it works great. (I'm using Preview 2 of Spring.NET 1.1) When using the WSE version one has access to the Pipeline property (which is the input/output stack on the webservice invocation). In certain cases, I need access to that Pipeline object to manipulate it. (And yes, it has to be dynamic unfortunately; I can't just edit the configuration :(). As an experiment, my thought process was to use Introduction to introduce a "no-op" Pipeline property into the non-WSE class, and then try to expose that object via the WebServiceProxyFactory. Hence, my initial question.

For now I have extended the non-WSE generated stub, added the no-op Pipeline property to achieve the same goal. But, we are invoking multiple web services under this scheme and that means more classes/maintenance/etc. That, and I'm trying to learn about AOP.

Is anyone else using WSE for web services? Is there a better way to do this?

[Bruno Baia]

Hi,

Is it possible to expose a proxied object via the WebServiceProxyFactory? It looks like you can only specific the ProxyClass, which is the Type name, not an Object name or a reference to an Object.

you right, we need a property with an object name or a reference to an object to give to the WebServiceProxyFactory a proxied object, but what you can do for now is to create the proxied object with the WebServiceProxyFactory object result :


<object id="MyAdvice" type="Aspects.MyAdvice, Aspects" />

<object id="MyWebService" type="Spring.Web.Services.WebServiceProxyFactory, Spring.Services">
<property name="ProxyClass" value="Client.MyWebService, Client" />
<property name="ServiceInterface" value="IServices.IMyService, IServices" />
</object>

<object id="MyService" type="Spring.Aop.Framework.ProxyFactoryObject, Spring.Aop">
<property name="Target" ref="MyWebService" />
<property name="InterceptorNames">
<list>
<value>MyAdvice</value>
</list>
</property>
</object>


But, i don't think it's usefull in your case, because you can't access properties like Pipeline (or another SoapHttpClientProtocol/WebServiceClientProtocol property) in your advices.


About WSE, we are working on a new WebServiceProxyFactory that will
make unnecessary to generate a proxy using WSDL.exe or
VS.NET and we think of integrating WSE on it and make some advices for common use cases.


About your scenario, why do you need both WSE and non WSE proxy class ? Are you trying to abstract the fact you are using WSE or not ?

Bruno.

[valdis99]

About your scenario, why do you need both WSE and non WSE proxy class ? Are you trying to abstract the fact you are using WSE or not ?
We need to be able to support making web service calls using WS-Security and not using WS-Security. The (easiest) way at the time was to switch between the two generated stubs. Now that I think about it some more, it might make sense to just manipulate the Pipeline for the Wse generated version to remove any WS-Security related filters when we don't want WS-Security on that particular call. Seems like it should work; I'll give that a try instead.

About WSE, we are working on a new WebServiceProxyFactory that will
make unnecessary to generate a proxy using WSDL.exe or
VS.NET and we think of integrating WSE on it and make some advices for common use cases.
I'd be interested to test this out once it becomes available. For our use case, we would want access to the Pipeline.

[Bruno Baia]

Hi Valdis,

sorry i forgot u, another topic made me recall that u can be interested by the new WebServiceProxyFactory.

U can find a preview in the POC diretory :
"Spring.Net / src / POC / WebServices"

The 'Calculator' sample uses WSE 2.0 SP3.

Feel free to give me feedbacks, specially on WSE.
I only made one WSE aspect (usernamesigning), but u can see what it will look like.

Regards,
Bruno on vacations :)

[valdis99]

Bruno,

Thanks for the pointer to the latest code. I've tried it out and I have a few comments and/or additional requirements.

1. Expose the ClientCertificates property. All of our web service calls are using 2-way SSL not Basic Authentication. I've made this change and it works nicely. I've added properties to specify the key identifier of the certificate as well as the StoreLocation and StoreName of the key store to find the certificate in.

2. Provide a property for the WSDL Url in addition to the WebService Url. This is probably something that we need to fix in our system (the webservice is deployed under SharePoint), but I needed to add this to be able to discover the WSDL and then invoke the service.

In reality, this approach seems to work nicely for web services which are using primitives and/or simply object models. Unfortunately, the web services which I'm invoking have extremely complex return types and parameters. It seems like most of the advantage of this Factory is lost when you have to code by hand the complex parameters and return types for the service. The biggest benefit to using this versus the WebServiceProxyFactory is that I can now use AOP with these objects.



Valdis

[Bruno Baia]

Hi Valdis,

thanks to be my first beta tester :)


1. Expose the ClientCertificates property. All of our web service calls are using 2-way SSL not Basic Authentication. I've made this change and it works nicely. I've added properties to specify the key identifier of the certificate as well as the StoreLocation and StoreName of the key store to find the certificate in.

Added to the todo list.


2. Provide a property for the WSDL Url in addition to the WebService Url. This is probably something that we need to fix in our system (the webservice is deployed under SharePoint), but I needed to add this to be able to discover the WSDL and then invoke the service.

I tested with a link finishing by ".asmx?WSDL" that point directly to the WSDL and it seemed to work. I'll take a look.


In reality, this approach seems to work nicely for web services which are using primitives and/or simply object models. Unfortunately, the web services which I'm invoking have extremely complex return types and parameters. It seems like most of the advantage of this Factory is lost when you have to code by hand the complex parameters and return types for the service. The biggest benefit to using this versus the WebServiceProxyFactory is that I can now use AOP with these objects.

Exact, code-first and contract-first approaches.
We have a discussion about it here :
http://forum.springframework.net/viewtopic.php?t=318


-Bruno