synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Asankha C. Perera" <>
Subject Chat log
Date Thu, 20 Jul 2006 13:22:42 GMT
Session Start: Thu Jul 20 17:23:01 2006
Session Ident: #apache-synapse
* Now talking in #apache-synapse
* saminda has joined #apache-synapse
* saminda has quit IRC (Client Quit)
* saminda has joined #apache-synapse
* hzbarcea has joined #apache-synapse
<hzbarcea> hi everybody
<asankha> hi hadrian
<asankha> have you been working on any schema stuff?
<hzbarcea> yes, i started to work on it, but didn't finish and i am 
flooded with some other work at the moment
<hzbarcea> i didn't have a chance to reply to a few mails on the list either
<asankha> ok.. np.. just curious to know if you are working on it..
<hzbarcea> i think the whole issue got a bit confusing
<asankha> shall i undo my recent changes.. if that will make things 
easier for u to work on?
<asankha> but our community does not want to change the language to be 
schema validatable..
<hzbarcea> i didn't look at them yet, you can leave them there and we'll 
make necessary changes later
<hzbarcea> :) you tell could why me?
<hzbarcea> now that was some english har to validate, wasn't it?
<hzbarcea> hard to validate i meant
<asankha> yes..
<hzbarcea> just the order was off
<hzbarcea> could you tell me why? (is the correct order)
<hzbarcea> :)
<asankha> but the main issue is with attributes
<hzbarcea> Paul said that we should do the validating in synapse
<asankha> since we have cases like either attribute A and B or attribute C
<asankha> which cannot be validated
<hzbarcea> i can agree with this, i didn' say we should validate the 
configuration all the time but it should be validateable
<hzbarcea> do you mean the combination of attributes or the value of the 
<asankha> the combination of attributes :-(
<hzbarcea> ok, let's take wsdl
<hzbarcea> one can have
<hzbarcea> (sorry I meant xml schema not wsdl)
<hzbarcea> <xs:element ref="QName"/> or
<hzbarcea> <xs:element name="NCNAME" type="QName"/>
<hzbarcea> correct?
<hzbarcea> one cannot put an @type attribute with @ref
<asankha> yes..
<hzbarcea> so this is documented and the logic coded in the parser/validator
<hzbarcea> it does not mean that a schema should not be validateable
<asankha> so how do you propose we validate say a filter mediator.. like 
<filter (source="xpath" regex="string") | xpath="xpath">
<asankha> with a combination of schema and some additional logic coded 
into the parser/validator?
<hzbarcea> i didn't get there yet, i could think of at least a couple of 
<asankha> hmm.. this is interesting if you can do it quite easily
<hzbarcea> the schema is not necessarily for the synapse project itself, 
but 3rd party tools, etc
<hzbarcea> what would you do with this configuration:
<asankha> yes..
<hzbarcea> <filter source="xpath" foo="one" bar="2"/>
<hzbarcea> a schema would clearly and simple tell that @foo and @bar ar 
invalid attributes
<hzbarcea> the semantics cannot be expressed in the schema and I am not 
trying to go there
<asankha> ok.. i understand what you say now
<hzbarcea> for instance one can express that @source is an xs: string 
but not that it is an xpath expr
<hzbarcea> plus, as I said in a previous thread I don't think changes 
are needed in synapse, we just have to come up with the schema
<asankha> cool.. +1
<hzbarcea> thx
<hzbarcea> personally i still didn't understand what exactly the 
community has against schema and validation
* sanjiva has joined #apache-synapse
<asankha> hi sanjiva
<hzbarcea> one point I think Sanjiva made (here, he just joined :), hi 
Sanjiva) is that we shouldn't make xml more complicated just for the 
sake of validating it
<hzbarcea> and I could not agree more
<hzbarcea> so in my mind
<hzbarcea> xml configuration should be simple and straightforward
<asankha> exactly.. not that anyone is against using schema for 
validation - but think that the language should not be changed to 
achieve schema validation
<hzbarcea> schema should reflect the syntax
<hzbarcea> semantics should be documented and reflected in the logic/code
<hzbarcea> if we were to change the language it would be to make it 
<hzbarcea> we'd have to discuss each instance of the change and evaluate 
impact on users who might already use synapse and would have to make changes
<asankha> i think you should write a summary of this and post to the 
mailing list... as some may not read the chatlogs in detail
<hzbarcea> well, i think all this was already stated on the mailing list :)
<hzbarcea> but i could certainly do so, better probably on the wiki and 
point to it in a message on the list
<asankha> yes.. that'll be better...
<hzbarcea> the problem right now is that I am fighting other issues, 
still synapse related which will take another couple of days
<asankha> other issues?
<hzbarcea> :) i didn't mean bugs
<hzbarcea> i am looking into two things, one being a rules based mediator
<hzbarcea> using drools in particular
<hzbarcea> another one is a scenario i am not sure how to address
<asankha> i think you could do so easily with a class mediator.. or 
better yet.. write your own extension
<hzbarcea> by easy you mean it's just writing code right? easy indeed :)
<hzbarcea> coming back
<hzbarcea> let's say one has the server behind a firewall
<hzbarcea> and puts synapse in the dmz
<asankha> :)
<asankha> ok.. lets talk about the second scenario
<hzbarcea> now the server returns to the client a WS-A reference to 
another service the client must talk to
<asankha> ok..
<hzbarcea> but the client cannot hit it, so synapse would have to deploy 
a new (dynamic) proxy and pass back to the client the reference to the 
new one
<hzbarcea> sounds fun enough?
<hzbarcea> (the first scenario, i am writing an extension, indeed)
<asankha> i guess thats one way to do it.. but if you can get the client 
to always set the transport to the synapse instance, then synapse can 
forward to the real service even if you dont have a proxy
<hzbarcea> i am not sure i understand
<hzbarcea> we have to servers A and B
<saminda> dynamic indeed, what would you propose ??
<hzbarcea> the client C sees synapse S as service A, it does not know 
about A really
<asankha> i think the proxy model is 'easier to understand' and manage 
but the message model can be used as well
<hzbarcea> but S sends the original message to A and A returns *in the 
message* a reference to B.  S gets the reference to B, what will it give 
back to C?
<asankha> can you set the client to use synapse (S) as a proxy for all 
traffic? (i assume this is http)
<asankha> if you can get all the messages into S at transport, then you 
can always look into the messages at S and forward appropriately
<asankha> so the client never knows about S
<asankha> its set as a transparent proxy
<asankha> e.g. ProxyStockQuoteClient
<hzbarcea> now i think I know what you mean, you are assuming a SOAP 
message, what if it's POX?
<saminda> i think in B's case it has two options
<saminda> being anonymus or reference another
<asankha> still if its http/s you can do it..
<asankha> even on other transports
<hzbarcea> http
<asankha> once the underlying Axis2 gets the POX/REST message, it will 
wrap it in a SOAP envelope
<hzbarcea> you can do it, but you need another endpoint
<asankha> so after synapse gets hold of a message, its always SOAP no 
matter the transport or whether it was originally SOAP or POX/REST
<hzbarcea> the issue (the way i see it) is dynamic deployment of another 
endpoint in synapse
<hzbarcea> messages sent to the initial endpiont go to A
<saminda> that depends
<hzbarcea> messages sent to dynamicly deployed endpoint go to B
<hzbarcea> let's make things more fun
<hzbarcea> A is soap, B is JMS :)
<hzbarcea> A sends back a reference to service B with a jms transport
<asankha> ok.. :) we support JMS!
* sanjiva has quit IRC (Read error: 113 (No route to host))
<asankha> i still dont think this is a problem..
<asankha> if you want, you could re-write the content in the reply 
messgae from A and replace the reference to B with something else..
<hzbarcea> this probably means that you know somethink i don't (yet) :)
<hzbarcea> that's exactly what i am trying to do, but replace it with what?
<hzbarcea> it has to be a referece to something else, the client can hit
<hzbarcea> and that other endpoint must exist, but it wasn't 
preconfigured, because synapse didn't know about it at startup, so it 
has to be created, configured and deployed at runtime. 
<hzbarcea> unless there is a simpler way i don't see
<asankha> i think so.. can you put up a basic diagram for the scenario.. 
Im sure we can do this right now .. and would love to work on this
<asankha> you could post this to the user group as others may also be 
* sanjiva has joined #apache-synapse
<hzbarcea> i intended to do so of course after finishing my work :)
<hzbarcea> you asked what keeps me busy...
<asankha> what i proposed to you initially.. i.e use synapse as a 
transparent proxy should perform what you require
<hzbarcea> then i need some sort of differentiator in the second message 
to tell synapse to send it to be not a
<asankha> no.. what i mean is.. since synapse server can send whatever 
the message to whatever the server...
<asankha> whatever address service A replies to the client for service B 
should be valid at the synapse server
<hzbarcea> agree, but it has to be told to do so
<hzbarcea> it is
<asankha> now the problem is to get the client to send messages to B (or 
C.. or D.. dynamically) as if he can access them all without any problem
<hzbarcea> undortunately i have to drop out now, i have to get to the 
office :)
<asankha> the trick is to set synapse as a transparent proxy for the 
clients transport
<asankha> the client uses WS-A for the actual service address.. but all 
messages first get to synapse
<asankha> sure.. lets talk about this on the user list.. maybe you can 
document this in brief for others also to follow
<hzbarcea> sure, thanks
<hzbarcea> bye
<asankha> talk to you next week.. bye
* hzbarcea has left #apache-synapse

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message