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