aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Charters <>
Subject Re: [DISCUSS] Applications and subsystems
Date Thu, 25 Feb 2010 13:14:28 GMT
I think for the 'deviation' model to work, each statement needs to be
a small incremental progression from the default.  I don't yet see how
that would work.  If I have an "all shared" subsystem (type 1), then
the small increment is to prevent something, whereas, if I have an
"explicitly shared" subsystem (type 2), then the small increment is to
allow something (would need to be a different header).  I don't think
we should be allowing any statements about sharing in "application
subsystems" (type 3).

Maybe you could give me a bit more detail on how you seen the
increments working?

Regards, Graham.

On 25 February 2010 11:52, David Bosschaert <> wrote:
> Right, the defaults would be different, but I guess there should be a
> way to deviate from the defaults. Would it not make sense to use the
> same syntax in use cases 1/3 to describe the deviation from the
> defaults to what you are using in use case 2?
> What I'm thinking is: nothing specified -> defaults
> something specified -> overrides defaults
> I don't fully understand why you would use different configuration
> settings for this in options 1/3 just yet...
> Cheers,
> David
> On 25 February 2010 11:16, Graham Charters <> wrote:
>> Hi David,
>> I think I see it a little differently.  If we try to common up the
>> headers, then we end up with a matrix of rules for which headers are
>> allowed on which type of 'subsystem'.  Take the example you gave
>> below; for the three types of subsystem I described earlier, only the
>> second type (Explicitly shared) would ever make statements about the
>> services that are exported or imported.  Types 1 and 3 have different
>> rules for defaulting what is shared.
>> Regards, Graham.
>> On 22 February 2010 10:24, David Bosschaert <> wrote:
>>> I'm not entirely sure what you're thinking yet, could you maybe give
>>> us an example?
>>> I would imagine that configuration entities with the same meaning
>>> would be configured in the same way across the different types. So you
>>> define the services that you're exporting using the same header/tag,
>>> whether this is a subsystem or an application. Or do you see this
>>> differently?
>>> Best regards,
>>> David
>>> On 19 February 2010 16:04, Graham Charters <> wrote:
>>>> I'd been thinking the different sets of manifest.  I think the way
>>>> these types of subsystems will be used will be quite different and
>>>> subsystem definitions will typically not morph from one type to
>>>> another.  It therefore seems to make sense to emphasise the
>>>> distinction.
>>>> On 19 February 2010 15:01, Guillaume Nodet <> wrote:
>>>>> On Fri, Feb 19, 2010 at 15:00, Graham Charters <>
>>>>>> <snip>
>>>>>> I think what we have so far is the basics of 3.  We should aim for
>>>>>> consistency across all three, but I think the sharing policy defaults
>>>>>> need to remain separate.  If we were to choose just one policy,
>>>>>> we will force the others into expressing a lot of unnecessary
>>>>>> information.  We could broaden Application to cover all three, but
>>>>>> think that would be confusing.  Maybe there are other forms of
>>>>>> subsystem for the different sharing policies, where each is
>>>>>> specialized for the useful defaults.
>>>>> I agree with having different default policies.  What do you have in
>>>>> mind as to identify those different use cases from a user point of
>>>>> view ?  Are you thinking about completely different set of manifest
>>>>> headers ? Or simply one which would contain the "kind" of
>>>>> application/subsystem defined ?
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog:
>>>>> ------------------------
>>>>> Open Source SOA

View raw message