Re: [sca-assembly] Concerns raised by Siemens

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

Hi,

I would like to second Philipp's comments and offer whatever help it takes to implement Sanjay's proposal. Making SCA a more open standard by providing a way to assert conformance using proprietary implementation languages will help with SCA adoption which up to this point has been a bit slow.

I would also like to comment that I was very surprised to find out this issue was brought up late during the face-to-face, without any forewarning. Unfortunately, due to time zone constraints, I wasn't present during the discussion. In my opinion, it would have been much more productive to have:

1. Made more of an effort to include interested parties by continuing the original discussion on the mailing list or calling it out as an explicit agenda item for the face-to-face. We should be aiming at making SCA inclusive. For example, the following comment taken from the F2F meeting minutes over ASSEMBLY-132 and ASSEMBLY-149 does not appear to be in that spirit:

"Essentially it seems that current proposals allow companies to claim conformance to standards without going through the standards process ...MS [Microsoft] could always do a BPEL implementation but it is their problem not ours" 

2. Characterized the issue more accurately. The following was stated during the meeting minutes:

"We've actually spent a lot of time on this and been unable to find a satisfactory solution...the issue is delaying the spec and we shouldn't spend more time on this for 1.1" 

Actually, there is a proposal (Sanjay's) that does provide a satisfactory solution. In addition, I have spent a significant amount of time with Mike Edwards reviewing the test cases and it is our opinion that the existing structure does provide the ability to verify conformance against proprietary languages. As Philipp said, claiming there is not enough time is a stretch given the issue was raised back in June. If time is as issue, why is significant work being done on the 1.2 specs (e.g. eventing) prior to 1.1 being complete?

3. Provided an official response/explanation as to why the issue was closed. I have only seen the meeting minutes and am not aware of any official response being sent.

I believe these public comments were made in good faith and with the desire to make SCA more open. It would be better if we made an attempt to work directly with the companies that raised these issues and others during the public comment period. Why not engage them to work together on a solution that is satisfactory to everyone? 

Jim

On Dec 17, 2009, at 6:02 PM, Konradi, Philipp wrote:

Dear colleagues,

to be honest I’m not very happy about the final outcome of concerns raised by Siemens [1][2] and especially the way things went.

The decision to close them with no action came out of nowhere. Maybe that’s just my personal impression but:

- Not a single objection was expressed before on the mailing list

- A solution proposal was already in work (driven by Sanjay) and there were indications of acceptance

- A vote conducted during the TC confcall on 10. Nov. closed with not a single person voting for closing the issue with no action (19 persons present)[3]. TC agreed “that modifying the conformance requirements will be considered and the work would be worthwhile”

So what has changed so immediately?

If the problem is the amount of efforts then I offered help already once [4] and I and my colleagues would be glad to help with the proposal work. Just let me know!

If the problem is the time left until SCA 1.1 release then I think the issues should be closed with agreement to continue the work started in the next SCA Spec release cycle.

Just saying “Can always revisit for 1.2” is totally unsatisfactory because Siemens submitted the concerns in JUNE. If there was not enough time to get to an agreement till end of the year then I doubt that it’s a good investment for Siemens to start the whole game again and try to accommodate the standard to industrial needs.

Is SCA an implementation language independent assembly model or not? If yes, then it should be visible also in conformance requirements IMHO.

Adopting the SCA assembly model for a programming / scripting language which doesn’t belong to the mainstream is currently extremely difficult. Both workarounds, add multi-language support as well as go through standardization, are quite an obstacle and doesn’t really foster wide adoption of SCA.

Regards,

Philipp

 [1] http://www.osoa.org/jira/browse/ASSEMBLY-149

[2] http://www.osoa.org/jira/browse/ASSEMBLY-152

[3] http://lists.oasis-open.org/archives/sca-assembly/200911/msg00078.html

[4] http://lists.oasis-open.org/archives/sca-assembly/200910/msg00007.html