I propose "triggers" as the name for the things that kick off sequences.
On Mon, Apr 7, 2014 at 8:02 PM, Srinath Perera <srin...@wso2.com> wrote: > Hi Paul, > > > Its a good question. I think the basic idea here is that you cannot rely >> on which thread you are on. i.e. there is no guarantee of threads being the >> same, only of context and message remaining available within a sequence >> execution flow. >> > > Sorry, I should have explained what I meant in detail. Consider following > code. > > > <sequence ... > > <sequence ...> > <sequence receive="anotherSequence"> > <sequence receive="devNullSequence"> > </sequence> > > Here (other syntax are possible too) > First sub sequence run blocking the main thread of execution > Second sub sequence runs in the background with a callback > Third sub sequence runs in background but no callback. > > Currently this is somewhat possible via "receive" in send mediator. I am > proposing to make it a high level concept work with all sequences. > > I would like to avoid adding a mediator for synchronizing because you >> shouldn't be manipulation any variables that aren't specific to that >> sequence. If you access a database or modify cache, that should be done in >> a thread-safe manner anyway. >> > > I think we need some way to have mutual exclusion. One real world example > I had to solve ( and did solve via custom mediator) is that batch first n > messages and send do a call to a backend service. One way to handle this > problem is how "Go" handle mutual exclusion without locks. IMO we should > also think about this a more as it is not nice to ask people to write > custom mediators on such cases. > > --Srinath > > > >> >> Paul >> >> >> On 7 April 2014 09:44, Srinath Perera <srin...@wso2.com> wrote: >> >>> Hi Paul, >>> >>> I like the model. If we are doing it, I think we need to also think about >>> >>> 1) How does sequence and thread of equation are related? This is more or >>> less parent sequence wait for the client sequence to respond (sync vs. >>> Asynchronous). e.g. We support async outgoing calls via "receive" property. >>> I am proposing to make this also a general concept. >>> >>> 2) Adding a mean to achieve mutual exclusion (synchronized block) >>> >>> --Srinath >>> >>> >>> >>> >>> >>> >>> On Fri, Apr 4, 2014 at 12:07 PM, Paul Fremantle <p...@wso2.com> wrote: >>> >>>> I've been discussing the ESB semantics with the cloud tooling team >>>> and we had a very interesting thought process yesterday. >>>> >>>> The first starting point is that I think we can simplify away from the >>>> in/out/fault sequence model. >>>> >>>> The new call and respond mediators mean that any API or Proxy can be >>>> defined by a single sequence that calls other sequences and then moves on, >>>> and finally responds (or not). >>>> >>>> This model (which has been discussed before) makes service chaining >>>> much simpler. >>>> >>>> Having described this model we then started describing the rest of the >>>> semantics to the tools guys and Tyler made a very interesting pair of >>>> observations. >>>> The first observation was why separate sequence and template. A >>>> template is just a sequence with parameters, and a sequence is just a >>>> template with zero parameters. (I'm ignoring endpoint templates etc for the >>>> moment, but maybe the same applies to them?) >>>> >>>> The second was that the proxy/api/tasks are all ways of kicking off a >>>> sequence. Of course if you have multiple sequences/targets/etc in a proxy, >>>> then its not like a task. But if you have a single sequence, with the >>>> target service(s) as a parameter(s) then it is very similar to a task. So >>>> his suggestion is that we create a meta concept of >>>> "orchestrators"/"actuators"/"activators". We didn't decide on a name for >>>> these but I personally like activators. >>>> >>>> In other words there are basically just two types of things: sequences >>>> (which do stuff) and activators (which activate sequences). >>>> >>>> Paul >>>> >>>> -- >>>> Paul Fremantle >>>> CTO and Co-Founder, WSO2 >>>> OASIS WS-RX TC Co-chair, Apache Member >>>> >>>> UK: +44 207 096 0336 >>>> US: +1 646 595 7614 >>>> >>>> blog: http://pzf.fremantle.org >>>> twitter.com/pzfreo >>>> p...@wso2.com >>>> >>>> wso2.com Lean Enterprise Middleware >>>> >>>> Disclaimer: This communication may contain privileged or other >>>> confidential information and is intended exclusively for the addressee/s. >>>> If you are not the intended recipient/s, or believe that you may have >>>> received this communication in error, please reply to the sender indicating >>>> that fact and delete the copy you received and in addition, you should not >>>> print, copy, retransmit, disseminate, or otherwise use the information >>>> contained in this communication. Internet communications cannot be >>>> guaranteed to be timely, secure, error or virus-free. The sender does not >>>> accept liability for any errors or omissions. >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> http://people.apache.org/~hemapani/ >>> http://srinathsview.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Paul Fremantle >> CTO and Co-Founder, WSO2 >> OASIS WS-RX TC Co-chair, Apache Member >> >> UK: +44 207 096 0336 >> US: +1 646 595 7614 >> >> blog: http://pzf.fremantle.org >> twitter.com/pzfreo >> p...@wso2.com >> >> wso2.com Lean Enterprise Middleware >> >> Disclaimer: This communication may contain privileged or other >> confidential information and is intended exclusively for the addressee/s. >> If you are not the intended recipient/s, or believe that you may have >> received this communication in error, please reply to the sender indicating >> that fact and delete the copy you received and in addition, you should not >> print, copy, retransmit, disseminate, or otherwise use the information >> contained in this communication. Internet communications cannot be >> guaranteed to be timely, secure, error or virus-free. The sender does not >> accept liability for any errors or omissions. >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ============================ > Srinath Perera, Ph.D. > Director, Research, WSO2 Inc. > Visiting Faculty, University of Moratuwa > Member, Apache Software Foundation > Research Scientist, Lanka Software Foundation > Blog: http://srinathsview.blogspot.com/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Jackie Wheeler* VP, Technical Content WSO2, Inc. Mobile: +1 510 725-2876 http://wso2.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
