Well, we had two operation models called proxy service mediation and message mediation. In the earlier case message is going to be dispatched to the respective proxy service where as in the later case message will be directed to the main sequence. Now the message mediation operational model is only available for the HTTP/S
>From my POV this is conceptually wrong with the initial design of synapse. Do we want to drop in the message mediation. Thanks, Ruwan On Thu, Apr 2, 2009 at 1:35 PM, Andreas Veithen <andreas.veit...@gmail.com>wrote: > I guess the HTTP(S) restriction is there for the case where Synapse is > used as an HTTP proxy. I don't see how we would get a similar behavior > with any other transport, so this actually looks right (but should be > better documented in the code). > > Andreas > > On Thu, Apr 2, 2009 at 07:59, Ruwan Linton <ruwan.lin...@gmail.com> wrote: > > Yes, I fixed the handler module.... but what I am referring is the normal > > synapse behavior, not the handler module. > > > > For the message mediation case I think we shouldn't restrict the > transports. > > > > Thanks, > > Ruwan > > > > On Thu, Apr 2, 2009 at 8:58 AM, indika kumara <indika.k...@gmail.com> > wrote: > >> > >> Hi Runwan > >> > >> HTTP and HTTPS for synapse message mediation (_SynapseService) > >> setting was there in the previous code (Proxy service only had the per > >> service transports ) . I actually only did refractor - cut and paste > >> and change only organization. Synapse as Handler module can be > >> deployed without much effort... may three , four line ........ > >> > >> Thanks > >> Indika > >> > >> On Thu, Apr 2, 2009 at 7:29 AM, Ruwan Linton <ruwan.lin...@gmail.com> > >> wrote: > >> > I went through the new synapse startup logic and it seems OK but this > >> > makes > >> > the following concrete changes to the synapse architecture > >> > > >> > Synapse can no longer be deployed just as a pure module in axis2, it > >> > requires much more work. > >> > The message mediation is restricted to HTTP and HTTPS, which I am not > >> > sure > >> > whether we want to keep it as it is. > >> > > >> > But still this new logic even doesn't address the original problem in > >> > the > >> > discussion. In the new logic transport listeners starts even before > the > >> > mediators getting loaded into synapse. > >> > > >> > I think we need to improve this, and to me Eric's point is completely > a > >> > valid point. I will further look into resolving this and will keep the > >> > list > >> > posted. > >> > > >> > Thanks, > >> > Ruwan > >> > > >> > On Tue, Mar 31, 2009 at 3:53 PM, Supun Kamburugamuva < > supu...@gmail.com> > >> > wrote: > >> >> > >> >> Hi Indika, > >> >> > >> >> On Tue, Mar 31, 2009 at 10:02 AM, indika kumara < > indika.k...@gmail.com> > >> >> wrote: > >> >>> > >> >>> If the synapse is run top on axis2 or any other, it should be > properly > >> >>> initialized and started before initialize synapse. > >> >> > >> >> > >> >> We are talking about two things here. Initialization and startup. I > >> >> agree > >> >> synapse should inilialize after axis2. Also Synapse should start > after > >> >> Axis2. But at the moment it seems that Synapse is starting even > before > >> >> it > >> >> initializes. The way Synapse is written it is perfectly normal to > >> >> assume > >> >> that it is started when Axis2 is started. But if we do it in the > >> >> current > >> >> way, this assumption is broken and can lead to failures as Eric said. > >> >> If > >> >> Axis2 is initialize properly we can initialize Synapse. As Eric said > if > >> >> both > >> >> are successfully initialized we can start Axis2 transports, which > >> >> automatically starts Synapse. > >> >> > >> >> Thanks, > >> >> Supun. > >> >> > >> >> > >> >>> > >> >>> It is a well known > >> >>> semantic that system should be in consistent state before use it. > You > >> >>> can refer [1] and it says why I did. > >> >> > >> >> > >> >> > >> >> > >> >>> > >> >>> The way message get in to synapse and mediation engine (main > behavior) > >> >>> are two different aspects and definitely should have two different > >> >>> decision designs as it is wrong if main behavior depend on other > >> >>> behavior. The starting, shutdown --- simply state (consistent) > >> >>> management of mediation should not depend any thing. Axis2 Hander > is > >> >>> make way to get message into in to synapse and for good design, > >> >>> mediation engine should separate from this design decision. Managing > >> >>> mediation engine should be independent from axis2 or any other. > >> >>> > >> >>> If it is needed to avoid effect of started listeners if the synapse > >> >>> mediation engine started up is failed, then only applicable > >> >>> transaction semantic is compensation transaction. In order to > enforce > >> >>> that, it is needed to properly shutdown listeners, etc --- some how > >> >>> need to move into a consistent state before system startup. > >> >>> > >> >>> [1] > http://www.mail-archive.com/dev@synapse.apache.org/msg02688.html > >> >>> > >> >>> Thanks > >> >>> Indika > >> >>> > >> >>> > --------------------------------------------------------------------- > >> >>> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > >> >>> For additional commands, e-mail: dev-h...@synapse.apache.org > >> >>> > >> >> > >> >> > >> >> > >> >> -- > >> >> Software Engineer, WSO2 Inc > >> >> http://wso2.org > >> >> supunk.blogspot.com > >> >> > >> >> > >> > > >> > > >> > > >> > -- > >> > Ruwan Linton > >> > Senior Software Engineer & Product Manager; WSO2 ESB; > >> > http://wso2.org/esb > >> > WSO2 Inc.; http://wso2.org > >> > email: ru...@wso2.com; cell: +94 77 341 3097 > >> > blog: http://ruwansblog.blogspot.com > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > >> For additional commands, e-mail: dev-h...@synapse.apache.org > >> > > > > > > > > -- > > Ruwan Linton > > Senior Software Engineer & Product Manager; WSO2 ESB; > http://wso2.org/esb > > WSO2 Inc.; http://wso2.org > > email: ru...@wso2.com; cell: +94 77 341 3097 > > blog: http://ruwansblog.blogspot.com > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > -- Ruwan Linton Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: ru...@wso2.com; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
