Re: [sca-assembly] Any agenda items for tmorrow's SCA Assembly conference call?

[Jim Marino <jim.marino@gmail.com>]

I think the operative word is "disjoint". The specifications and work between the TCs is well described by that word and not in a negative sense.

A number of us were there too at the creation and an argument was made for decoupling the specifications based on the view that it was possible to produce modular specifications (which would increase uptake) and that the different technologies should be layered. In fact, at one time an argument was made (by Mike Rowley) for only standardizing the Assembly Specification.  

I believe that on the contrary this is where implementation work is critical and should inform the specifications. The reason Tuscany and Fabric3 were created during the early days of SCA was so that the specifications would not be created in a theoretical vacuum. Fabric3 is clear evidence that it is possible to separate and layer the specifications in a useful way. 

The code for policy is in the following module:

https://github.com/Fabric3/fabric3-core/tree/master/kernel/impl/fabric3-policy

If you have a chance to look at it, you will notice it is actually an SCA contribution and policy support is implemented using a set of SCA components. That is because the Fabric3 runtime is itself built on SCA. I think this further proves the possibility of modularizing the Assembly specification since Policy is built using the capabilities of SCA Assembly.

I guess I am making a criticism of Assembly, but I would not characterize it as an architectural one. The SCA Assembly "architecture" is valid and modular. It's simply the way the specification is written/implemented in a few places. In general, the editors did a fantastic job as the spec is unambiguous and clear. There is only the issue of a number of unnecessary references to WS Binding and Policy that can easily be removed.

A number of us including Siemens, TIBCO and Fabric3 have expressed strong interest in decoupling the specifications. If it is only the case that existing editors and chairs do not have the time to assist with ongoing work, maybe we should look into more evenly spreading the burden by rotating those positions to new people? 

Jim      

On Tue, Sep 17, 2013 at 4:19 AM, Jeff Mischkinsky <jeff.mischkinsky@oracle.com> wrote:

hi,
I believe anish is spot on in his characterization of the reasons why we have 2 TCs, policy and assembly, and not one.
I was there "at creation". We debated back and forth and finally came down on 2 TCs that would be joined at the hip, so to speak. The main reason is that administratively it is difficult under the oasis process to have disjoint work going on in one TC. Sub-committees really take independent decisions,  and the voting rules are set up so that one would have to attend all the parent TC meetings anyway. So the decision was made to have to TCs, which then meant that there HAD to be 2 specs.  Otherwise, we would have had only one assembly spec, with a policy chapter or 2.

I do note that with enough work one could probably decouple the specs, (your cool implementation is not really relevant from a spec perspective), but who really has the appetite at this late date to start that, and go through another major approval process.

I think your objection to the way policy is integrated into assembly (and SCA) is really a fundamental criticism (which may be valid) of the assembly architecture.

cheers,
 jeff


Begin forwarded message:

> From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
> Subject: Re: [sca-assembly] Any agenda items for tmorrow's SCA Assembly conference call?
> Date: September 16, 2013 5:54:01 PM PDT
> To: sca-assembly@lists.oasis-open.org

>
> Jim,
>
> I agree that separation of Asm and Policy is *possible*. I would argue that:
> 1) it is not desirable,
> 2) it is not easy (from a spec POV, not from the POV of a particular implementation), there is plenty of work involved there.
> 3) by design, asm and policy are joined at the hip/intertwined.
>
> The only reason they are different specs, done in different TCs, is for administrative reasons. The skill set and interest required for participating in assembly and policy are/were different. There certainly were folks that were interested in both. But enough folks were just interested in policy or just asm to make it an administrative problem in terms of attendance, quorum etc.
>
> I view asm and policy as a single spec divided into two parts for convenience/manageability.
>
> -Anish
> --
>
> On 9/16/13 4:01 PM, Jim Marino wrote:
>> Ashok,
>>
>> First, separating Assembly and Policy is possible and it is not hard to
>> achieve technically speaking. Fabric3 has already done this as both
>> Policy and WS Binding features can be removed from the runtime by simply
>> deleting three JAR files. Architecturally, Policy and WS Binding support
>> are added to Fabric3 via OSGi-based modularity.This allows for a
>> separation of concerns that, in my opinion, should also be reflected in
>> the specifications.
>>
>> Second, we haven't discussed this before with the benefit of actual SCA
>> implementation experience. This is an issue that has the support of at
>> least Fabric3, Siemens, and TIBCO. It's worthy of discussion and not a
>> waste of time.
>>
>> I'm sorry you feel this topic is not a productive use of your time and
>> have nothing to contribute to the technical discussion.
>>
>> Jim
>>
>> On Tue, Sep 17, 2013 at 12:43 AM, Ashok Malhotra
>> <ashok.malhotra@oracle.com <mailto:ashok.malhotra@oracle.com>> wrote:
>>
>>   We have discussed this before.  SCA Assembly and SCA Policy are
>>   intertwined and hard to separate.
>>   We also discussed the separation of Assembly from the WS Bindings
>>   and, after a long discussion,
>>   decided against it.  There is no new news.  Let's not waste our time.
>>   All the best, Ashok
>>   On 9/16/2013 3:43 PM, Jim Marino wrote:
>>>   Hi,
>>>
>>>   I would like to have an item placed on the agenda to discuss
>>>   removing the dependencies on the SCA Policy and SCA Web Services
>>>   Binding specifications from the Assembly specification. I have
>>>   discussed this already with some TC members but it would be good
>>>   to begin wider discussions.
>>>
>>>   Jim
>>>
>>>
>>>
>>>   On Mon, Sep 16, 2013 at 5:09 PM, Mike Edwards
>>>   <mike_edwards@uk.ibm.com <mailto:mike_edwards@uk.ibm.com>> wrote:
>>>
>>>       Folks,
>>>
>>>       Does anyone have agenda items for tomorrow's SCA Assembly
>>>       conference call?
>>>
>>>       Please send any items to the chairs as soon as possible.
>>>
>>>
>>>
>>>
>>>       Yours,
>>>
>>>       *Mike Edwards*
>>>       STSM - Cloud Computing and SOA Standards
>>>       Chair UK ISO SC38 mirror committee (Cloud & SOA)
>>>       Co-Chair OASIS SCA Assembly TC
>>>       ------------------------------------------------------------------------
>>>       *Phone:*44-1962-818014 (37248014)| *Mobile:*44-7802-467431
>>>       (274097)*
>>>       E-mail:*_mike_edwards@uk.ibm.com_
>>>       <mailto:mike_edwards@uk.ibm.com>*
>>>       Chat:*Google Talk: mike.edwards.inglenook@gmail.com
>>>       <mailto:mike.edwards.inglenook@gmail.com> *
>>>       Find me on:*LinkedIn:
>>>       http://www.linkedin.com/pub/mike-edwards/4/6b/97b
>>>       <http://www.linkedin.com/pub/mike-edwards/4/6b/97b>Twitter:
>>>       https://twitter.com/open_services
>>>       <https://twitter.com/open_services>
>>>       IBM
>>>
>>>       Mail Point 137, Hursley Park
>>>       Hursley, SO21 2JN
>>>       United Kingdom
>>>
>>>
>>>
>>>
>>>       IBM United Kingdom Limited
>>>       Registered in England and Wales with number 741598
>>>       Registered office: PO Box 41, North Harbour, Portsmouth,
>>>       Hants. PO6 3AU
>>>       Unless stated otherwise above:
>>>       IBM United Kingdom Limited - Registered in England and Wales
>>>       with number 741598.
>>>       Registered office: PO Box 41, North Harbour, Portsmouth,
>>>       Hampshire PO6 3AU
>>>
>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

--
Jeff Mischkinsky                                                jeff.mischkinsky@oracle.com
Sr. Director, Oracle Fusion Middleware                          +1(650)506-1975
        and Web Services Standards                              500 Oracle Parkway, M/S 2OP9
Oracle                                                          Redwood Shores, CA 94065

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php