Hi all,
Have found the a solution. In order to get WSE to accept the message routed
from an external client by ISA, you need to assign a
Microsoft.Web.Services2.Addressing.EndpointReference to the web service
proxy's Destination attribute. An endpoint allows two addresses to be
specified; the internal address of the web service and the internet facing
address. This allows WSE to accept the fact that the To attribute of the web
service had to pass via the external address. Sounds like a cludge, but it
works.
Before I was assigning the .URL property of the proxy class with the
external address of the web service, hoping that ISA would do it's job and
modify the message, but to no avail.
If anyone can think of a better to support 100+ web services please let us
know.
Thanks,
Louis
> Hi all,
>
[quoted text clipped - 19 lines]
>
> Louis
JoseP - 19 Oct 2005 23:48 GMT
Actually, the first address is not an address but a URN and can have any
values. To be able to deploy the web service easily, I set a defined URN to
my web service using the
Microsoft.Web.Services2.Messaging.SoapActor attribute of the web service.
The SoapActor referred to the first URN of the EndPointReference, while the
second reference is to the recipient of the soap message. With this, you can
have multiple deployment of the same web service with different
endpointreference.
> Hi all,
>
[quoted text clipped - 41 lines]
> >
> > Louis
Louis - 20 Oct 2005 10:41 GMT
The original problem has been sidestepped completely by reconfiguring ISA.
ISA is now redirecting traffic to the internal web server using an internal
DNS name which resolves to the internal IIS server. The net effect is that
when the messages are routed by ISA the <To> address doesn’t change therefore
WSE doesn't know or care about this.
> Actually, the first address is not an address but a URN and can have any
> values. To be able to deploy the web service easily, I set a defined URN to
[quoted text clipped - 51 lines]
> > >
> > > Louis