Re: Ws-Addressing - WSE and vanilla Web Service Proxies

Hi William - either you are or I am :)

I do have a single end point - the problem is that I get a "Message
Information
Header Required" when i call the routing service from a non-WSE client proxy.

All i want to know is how to get round this. Are you saying i need to do
something on the server rather that set one or two headers on the client?

You mention secure/insecure - why is that? I simply have a routing service
and haven't moved to attch any security to it - a very basic web service end
point which i am simply accessing from clients via an intermediate WSE
routing configuration.

I actually implemented exactly as stated in the WSE patterns book ... but
unfortunately they didn't details how to actually *use* WS-Addressing for
non-WSE clients.

steven
http://stevenR2.com

"Softwaremaker" wrote:

Why not let your routing service (I assume it probably implements a single
routing interface: ProcessMessage(m) and has a routing table as well) check
the contents (Content-based) for the necessary s:headers and route it to the
endpoint that can process it ?

In other words, you will have the same service (sort of) using 2 different
endpoints (one with security, one without) and they both can handle the
specific implementations that are required. You may want to deploy the
non-secured ones internally and the secured ones facing the cloud, for
example. This is akin to the address/bindings/contracts model WCF deploys.

It is difficult and I dont see the point of having a single service endpoint
being able to handle secured and unsecured messages. Seems like an
afterthought to me. What is the motivation of securing it in the first place
?

Am I missing something ?

--
Thank you.

Regards,
William Tay
http://www.softwaremaker.net/blog
=========================================

"Steven L" <StevenL@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:724973C8-600D-4FD2-AD76-0FF5F814645B@xxxxxxxxxxxxxxxx
Gracias Pablo.

The pipeline process is something i'm reasoable familiar with - didn't
realise there was such a significant difference in the generated proxies.

Here is crux of my problem - i need to allow a normal .Net service to use
the routing services i am creating - that is *essential* and some may not
use
WSE.

Got any pointers on making this work?

saludos,
steven.
http://stevenR2.com

"Pablo Cibraro" wrote:

Hi Steven,

The proxies created by WSE are completely different to those created by
..NET.
The WSE proxies intercept the SOAP messages and execute a pipeline where
the
message is transformed to a different version (The new message version
contains WS-Addressing and WS-Security headers).
The WS-Addressing headers are always added in that pipeline, but the
WS-Security headers are not (that depend on some WSE specific
configuration,
the WSE policies).

The same happens on the server side, if you configure WSE, a WSE
pipeline
will run before calling to your service (This pipeline performs
different
security validations and removes the WS-Addressing and WS-Security
headers).

The best way to know what headers are required is to enable WSE tracing
and
see the different messages between the client and the service.

Regards,
Pablo Cibraro
http://weblogs.asp.net/cibrax
[MVP - Connected Systems Developer]


"Steven L" <Steven L@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:CEC76416-7CEC-464F-950C-A502B33EF494@xxxxxxxxxxxxxxxx
I have a hub performing some internal routing for a set of services we
have,
using the WS-Addressing support in WSE 3.0.

When a vanilla .Net generated proxy client tries to call the service
you
get:
"Microsoft.Web.Services3.Addressing.AddressingFault: Message
Information
Header Required"

When a WSE generated proxy client does the same it works fine.

Can someone explain or point me at the different in the client proxy
configurations between these.

I will have some vanilla .Net clients and some Java clients and so i
need
to
tell them exactly what (Soap Headers?) to set on their proxy client so
they
can successfully call the routing service - i don't need to set these
when
calling the service directly, so any detail on exactly what causes
this
requirement by the WSE would be greatly appreciated!

Regards,
Steven
http://stevenR2.com






.

Relevant Pages

  • Re: Ws-Addressing - WSE and vanilla Web Service Proxies
    ... I can clearly get this working by figuring out when i have a WSE client ... writing services on the assumption that my decision to use routing is a good ... You will need minimally the wsa headers. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Ws-Addressing - WSE and vanilla Web Service Proxies
    ... the proxies inherits differently from vanilla ... asp.net web services and those proxies injects headers into the messages ... Header Required" when i call the routing service from a non-WSE client ... I actually implemented exactly as stated in the WSE patterns book ... ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Ws-Addressing - WSE and vanilla Web Service Proxies
    ... Why not let your routing service (I assume it probably implements a single ... The proxies created by WSE are completely different to those created by ... The WS-Addressing headers are always added in that pipeline, ... When a WSE generated proxy client does the same it works fine. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Ws-Addressing - WSE and vanilla Web Service Proxies
    ... the routing service is It. ... In WSE 2.0, it is ... I can't use this in the nonWSE client ... You will need minimally the wsa headers. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Ws-Addressing - WSE and vanilla Web Service Proxies
    ... The proxies created by WSE are completely different to those created by ... The WSE proxies intercept the SOAP messages and execute a pipeline where the ... The WS-Addressing headers are always added in that pipeline, ... When a vanilla .Net generated proxy client tries to call the service you ...
    (microsoft.public.dotnet.framework.webservices.enhancements)