Hi Sidd,
I understand the Via provides the physical mapping to the Logical To
element. Let me side-track you guys for a minute and submerge yourself in
the Real-world (as stated in my post
news:OpTyEA$bEHA.1048@tk2msftngp13.phx.gbl...), most messages flying around
today doesnt have WS-* headers. While it may change in the future with
WS-Addressing being submitted to W3C (together with SUN), according to
documentation, if WSE2.0 doesnt find any Addressing headers in a message, it
will map the RequestURL to the SOAPActor attribute of the service (which
typically states the well-known logical name)...
So I am out there exposing my WSE-aware service and if I am going to sell
interoperability, I should be able to AT LEAST recognize a plain old vanilla
SOAP Message with no WS-* headers, however, my WSE-Aware service will thrown
an exception saying that it cannot match the SOAPActor with the RequestURL.
What this is effectively encouraging is asking the service implementors to
put a Physical address as the SOAPActor (I mean the actual physical address
of the service endpoint here, even an intermediary Router address cannot
work as the Router will still be forwarding the message to the service) So,
we actually go back to square one where a service is tightly bound to an
endpoint address thru the SOAPActor attribute.
Have you guys got any thoughts about this ? Please tell me if my
understanding or implementation of this is all wrong.
--
Thank you very much
Warmest Regards,
Softwaremaker
Architect | Evangelist | Consultant
+++++++++++++++++++++++++++++++++
[quoted text, click to view] "Sidd" <ElCid@hotmail.com> wrote in message
news:OMlYIskhEHA.3864@TK2MSFTNGP10.phx.gbl...
> Hi Pranav,
>
> You cannot currently dynamically select a policy based on an
endpoint.
> However, I would still like to understand your scenario a bit. Say a user
> enters soap.tcp://machine:6000/Service1, and another user enters
> soap.tcp://machine:7000/Service1, I am assuming that there will be two
> separate policies in the policy cache file. The way WSE works is that when
> an outoging message passes through the output pipeline, the WSE policy
> filter first checks to see if the message satisfies the policy, and if
not,
> it tries to enforce the policy. The policy filter automatically maps the
> "To" of a message to find the appropriate policy in the policy cache.
>
> In cases where you using the TCP transport, you can have a logical
name
> mapped to a physical name. So, for an endpoint with physical address
> soap.tcp://machine:6000/Service, you can have it mapped to a logical name
of
> MyLogicalEndpoint. This way, you can have your messages with the To field
as
> MyLogicalEndpoint and physical address to be
> soap.tcp://machine:6000/Service. The advantage is that if
MyLogicalEndpoint
> moves from machine to machine, your policy file does not have to change,
> because now it is bound to something logical, rather than a physical
> address. You can look at the TcpSyncStockService example for an example of
> how to do this. However, I am not sure this solves your problem.
>
> Let me know.
>
> Thanks,
>
> Sidd [MSFT]
>
> "Pranav" <Pranav@discussions.microsoft.com> wrote in message
> news:29362F9D-79B0-4EA2-A4B9-ED846E40A96D@microsoft.com...
> > Policies seem to be tied to either one endpoint
> > ("soap.tcp://machine:6000/Service") or to the <default endpoint> (all
> > endpoints)
> >
> > 1. My problem is that i have a dynamic endpoint:
> > I allow the user to enter machine name and the port number. Then i
create
> > the endpoint from this info.
> > At this point, in the code, i need a way to pick a policy, say Policy1,
> and
> > apply it to this endpoint. Can I do this? Basically i am looking for a
way
> to
> > programmatically apply a policy to an endpoint.
> >
> >
>
>
