Ruwan, Can you cite any transport other than HTTP(S) with which that would actually work?
Andreas On Thu, Apr 2, 2009 at 14:53, Ruwan Linton <ruwan.lin...@gmail.com> wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
