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