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 <[email protected]> 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 > [email protected] > > 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 > [email protected] > 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
