You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Asankha C. Perera" <as...@wso2.com> on 2006/06/08 15:15:37 UTC

Chat log

<asankha> hi Glen
<gdaniels> Good day, all - sorry to be a little late!
<paulfremantle> hi
<paulfremantle> my connection is not good today
<paulfremantle> i may be on znd off
<paulfremantle> my typing isnt good either :-)
<gdaniels> I figured that was just due to the bad connection :)
<gdaniels> So what's on the agenda for today?
<asankha> Paul you have anything planned? Glen.. did u check out 
http://wiki.apache.org/incubator/Synapse/InProgress/Features_and_Design
<gdaniels> checking now
<asankha> it lists what we are planning for 1.0.. whats required and 
whats nice to have...
<asankha> would like you to check on the wsdl mediation stuff that you 
suggested..
<gdaniels> fault handling (and optional hierarchy).... optional hierarchy?
<gdaniels> what's that
<asankha> thats being able to specify fault handlers at say sequence 
level, so that if a mediator (say send) encounters a fault (say a 
transport error) the innermost handler will first handle the
fault
* ant_away has joined #apache-synapse
* ant_away is now known as ant_
<ant_> hi, sorry so late
<asankha> hi Ant
<asankha> Paul's having a bad connection today.. so he is d/c at times..
<gdaniels> asankha: that hierarchical fault handling sounds pretty useful
<asankha> great.. we havent yet started working on it.. but i think it 
wont be very difficult either
<asankha> Ant we are talking about whats at 
http://wiki.apache.org/incubator/Synapse/InProgress/Features_and_Design
<asankha> on what we are planning for 1.0
<ant_> ok thx, i'll go look...
<gdaniels> so I'm trying to understand endpoints here
<gdaniels> (in general I think this doc is great, but would benefit from 
some examples)
<gdaniels> is the idea that you define mediators that run when a 
particular URL is accessed?  or more than that?
<gdaniels> i.e. does this tie in with Proxy Services?  And do we expect 
to use the service name or the URL as the differentiator?
<asankha> well.. an endpoint is a named .. and will "resolve" to an 
absolute address at runtime.. and optionally can specify the WS-RM and 
WS-Sec policies/parameters on messages heading there
<gdaniels> can you give me a little example?
<asankha> if u have messages heading to www.amazon.com/serviceA you 
could define an endpoint with that address, and specify WS-Sec 
credentials for signing that message
<asankha> then within mediation rules, you can just say <send> <endpoint 
ref="amazon"> </send>
* paulfremantle has quit IRC (Read error: 110 (Connection timed out))
<asankha> and you can thus reuse the endpoint definition as well as make 
it easier to define RM/Sec etc at the point where messages leave synapse
<gdaniels> oh so this is *outgoing* endpoints
<asankha> yes.. sorry if it was not clear in the doc...
<gdaniels> gotcha
<asankha> proxies are the incoming ones
<gdaniels> no it says "used by the Send mediator", I just didn't get that
<ant_> so Endpoints are outgoing to remote services, and Proxy Services 
are for incoming services hosted by Synapse?
<gdaniels> might be nice to rephrase a little but that makes sense.
<gdaniels> ant: that seems right to me
<ant_> ok
<asankha> ant: yes..
<asankha> glen: sure will rephrase.. i didnt notice it since i wrote it 
with the idea in my mind..
* saminda_ has joined #apache-synapse
<gdaniels> so the proxy stuff...
<gdaniels> the idea is that Synapse lives inside Axis2, and only does 
mediation for the services that are configured as proxies?
<gdaniels> it's a little confusing to read
<asankha> no.. proxy services allow you to create "virtual" services on 
the underlying Axis2 but managed by Synapse
<gdaniels> Or do you mean that all messages go through the Synapse main 
rules, but only the messages for the proxy services terminate with 
Synapse (the others continue through Axis2)?
<asankha> what it means to the end user is that you can expose your 
existing services (WS/JMS/REST) as web services (or even JMS/REST) on 
Synapse with different semantics
<gdaniels> right, yes, that's the big use case for me
<asankha> e.g. if u write a service without WS-Sec, you can create a 
proxy on Synapse with WS-Sec and use the proxy to pass messages into the 
original
<gdaniels> +1
<asankha> also you can present a "different" WSDL on the proxy to that 
of the original service
<asankha> and perform the transformation through synapse
<gdaniels> yes yes
<asankha> for the case where u want optimal performance, you could 
directly tie a proxy to an 'endpoint' and we will just pass-through
<asankha> we need some support from Apache Neethi to enable WS-Sec/RM 
from WSDL and Policy
<ant_> So theres regular Axis2 services, Synapse Proxy Servics, and is 
there something else? something to do with the Synapse default mediation 
rules?
<gdaniels> and if you tie it to an endpoint, we'll also respect whatever 
policies for things like RM and Security are in the WSDL of the "real" 
service
<gdaniels> (when sending)
<asankha> glen: yes
<asankha> ant: we also have the default "synapse" service
<asankha> what we had from before
<asankha> now since synapse is a MAR, we will have our custom dispatcher 
as the last one and trap messages not dispatched to any other service
<gdaniels> hm
<asankha> these will flow in through the main synapse rules using the 
synapse service
<gdaniels> interesting
<saminda_> we allow only proxy services and synapse service only
<asankha> so Axis2 will not complain that a /foo service is not there 
etc if a message comes to such a service, but synapse will handle it
<gdaniels> so for a given message, it will either a) go to a normal 
Axis2 service, b) go through Synapse as a proxy service, or c) go 
through Synapse default rules
<saminda_> yes
<saminda_> a)
<gdaniels> I like that
<saminda_> we should not deploy real axis2 services
<saminda_> what we should have proxies
<gdaniels> right, but you could deploy some kind of custom thing if you 
wanted to
* saminda has quit IRC (Read error: 110 (Connection timed out))
<gdaniels> so what about MEPs?
<saminda_> yes, if it's pointing to synapse evn
<saminda_> that's stateless
<saminda_> sorry statefull
<saminda_> aint we aiming for something stateless for 1.0, may be :)
<gdaniels> so I've got a real service which says for operation "foo" 
both the inbound and outbound messages are reliable
<gdaniels> then I configure a synapse proxy to it
<gdaniels> does it do the reliability correctly?
<asankha> well yes.. but its totally done by sandesha and neethi at 
module level..
<asankha> and we need them to make those changes to meet our timelines
<gdaniels> which changes?
<asankha> currently we cannot enable WS-Sec/RM just by specifying a 
policy and attaching the policy to the WSDL
<asankha> right now you need to change the service.xml to do this
<gdaniels> hm
<gdaniels> so let me make sure I'm getting this.  Right now you can only 
enable stuff by engaging+configuring modules in service.xml
<asankha> but we need to create a service on axis programmatically by 
simply providing the WSDL and policies
<asankha> yes
<gdaniels> gotcha
<gdaniels> ok
<gdaniels> hm
<gdaniels> still seems like you should engage the module in service.xml
<asankha> this feature is already on neethi/sandesha and rampart plans.. 
but we need to 'get it
done quickly' :-)
<asankha> yes, we do engage it at service level
<asankha> actually we will engage addressing, rampart and sandesha globally
<gdaniels> ok, good - so you can then switch out which module actually 
does the work
<gdaniels> (different versions, etc)
<asankha> this will not harm any client who does not know WS-A/Sec/RM
<asankha> err... i dont think having different versions is straight 
forward.. at least not for 1.0 release...
<gdaniels> we should be thinking about how we would want that to work, 
though, so we make sure not to design ourselves into a corner
<asankha> actually we could do this for proxy services and endpoints.. 
but not for message level mediation..
<asankha> i.e. we could only have one version of RM supported at the 
synapse service level..
<asankha> since it captures all messages
<gdaniels> right
<gdaniels> then the individual proxy services could have other versions 
if they want
<asankha> yes..
<asankha> but i think its too much for 1.0
<gdaniels> sure
<asankha> we want to make an RC early as we can and get more people to 
use it and get involved with whats being developed...
<ant_> proxy services sound like they make things easy, but only if 
there's an existing real Axis2 service. If i want to use Synapse for the 
WS provider in Tuscany,
<gdaniels> no no
<gdaniels> proxy services simply require a remote WSDL
<ant_> i'd have a Tusscany entryPoint for a service but not a real Axis2 
service
<gdaniels> It could be .Net, whatever
<gdaniels> Tuscany, JBoss, WebLogic, etc
<asankha> ant: glen is right.. you only need a wsdl and policies if any 
for a proxy service
<ant_> i think i'm confused
<asankha> you can proxy to any external or other service..
<gdaniels> to configure a proxy service you just point to the remote WSDL
<asankha> ant: is it clear?
<gdaniels> Eventually, we enable configuring mediation behavior on a 
per-operation basis
<gdaniels> I like that :)
<asankha> yes
<saminda_> oh yes
<ant_> asankha, ok yes i think i've got it now
<ant_> there'd be some optimization for invoking a real Axis2 service 
being proxyed by syanpse in the same axis2 system?
* sanjiva has quit IRC (Read error: 110 (Connection timed out))
<asankha> well.. nothing special is planned.. but to the same JVM java 
will not talk through sockets so it should be good
<gdaniels> folks, I need to run.  Will play with the latest bits by next 
chat - feature list looks good!
<asankha> ok.. i think we can wind up
<asankha> i willpost the log
<gdaniels> see you all next week
* gdaniels has quit IRC
* saminda_ has quit IRC ("Leaving")
<asankha> ok.. im leaving too Ant .. bye
<ant_> bye, ttyl...


---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-dev-help@ws.apache.org