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
attributes
<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
ways
<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
clearer/simpler/unabmiguous
<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
interested
* 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
