Firstly I agree about the need to have a dynamically reloaded xml, and also to have pointers to registries.
Bu I don't understand your other point. In the case of DumbStockQuote, the /StockQuote is an alias. Thats exactly its point. There is no real service deployed at /Stockquote. The alias is looked up in the Synapse config and resolved to the real URI.
Another example is if you use the ProxyStockQuote and the http://stockquote address, which is another alias.
Paul
On 2/6/06,
Soumadeep <[EMAIL PROTECTED]> wrote:
Paul,Yes, what we are suggesting is to come up with such an intelligence by which the original provider url will be facaded by an alias which the client will provide for hitting Synapse. Further, even if the client provides some notion like in the case of DumbStockQuote (http://localhost:8080/StockQuote) the problem still remains as how would you differentiate between two services which have the same name yet provided by different providers?Another thing to note is that synapse.xml is loaded once during startup so it would become difficult to change the x-path based expressions at runtime.What I was proposing is that we have a mapping config file which maps incoming urls irrespective of the wsa-to header to the original services rather than burn it into synapse.xml. We could then have a processor which would read it and make it available to the system. This mapping config file will be easy to maintain and can be loaded on demand.In short, can we externalize the x-path/processor based lookup? and introduce a mapping config (alias->provider URL)eg.<Contract><StockQuote-www-infravio>http://www.infravio.net/StockQuote.asmx </StockQuote-www-infravio><StockQuote-www-webservicex>http://www.webservicex.net/StockQuote.asmx </StockQuote-www-webservicex><StockQuote-www-wso2>http://www.wso2.net/StockQuote.asmx </StockQuote-www-wso2></Contract>what the user will use is http://<host><:port>/StockQuote-www.infravio.Your comments.Best regardsSoumadeep-----Original Message-----Soumadeep
From: Paul Fremantle [mailto:[EMAIL PROTECTED]]
Sent: Monday, February 06, 2006 2:42 PM
To: [email protected]
Subject: Re: [axis2]Concerns about WSATo Header element
The WSA-TO header does not need to be set.
If you look at the DumbStockQuote sample there is no WS-Addressing headers and the WSA-To is not set. On receiving the message, one of two things can happen:
1) If you engage-addressing-in, then the WS-Addressing MAR will set the SynapseMessage.setTo() with the incoming HTTP URL
2) If you don't then you can write a mediator or use the existing ones to define the endpoint to send the message. For example:
<xpath pattern="...">
<header to .../>
</xpath>
Which will set the header based on finding a match in the body of the message.
Paul
On 2/4/06, Mukund Balasubramanian <[EMAIL PROTECTED]> wrote:One way to get around this might be to provide the option of targeting
(physical or logical) in the URL of call into Synapse. That way, you
don't HAVE to have wsa-to elements.
In the case of the logical mapping in the URL of call itself, additional
configuration such as the one Soumadeep is talking about could be used
to map to the physical service.
Mukund Balasubramanian
-----Original Message-----
From: Soumadeep Sen
Sent: Saturday, February 04, 2006 1:21 PM
To: Synapse
Subject: [axis2]Concerns about WSATo Header element
Paul/Sanjiva,
I am a little apprehensive about the way currently we mandate that the
wsa-To element in the SOAP header be set by the user/client for Synapse
to
work. Do you think it would be better to introduce the concept of a
contract
where the wsa-to element value would be mapped to the actual provider
service url in some xml file in Synapse, what the user would put in the
wsa-to is more of a proxy url to the actual service.
The reason I am putting this across is because why would a user go
through
Synapse when he can directly send a request to the actual service
provider.
Let me know if I am missing something here.
Best regards
Soumadeep
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]
"Oxygenating the Web Service Platform", www.wso2.com
