[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [sca-assembly-comment] Fwd: [sca-assembly] Fwd: [sca-assembly-comment] Ballot closure
From: Jim Marino [mailto:jim.marino@gmail.com] Again, sorry I am having trouble with a new mail setup. This was intended to go to the Assembly mailing list as opposed to just Eric. Jim ---------- Forwarded message ---------- Hi Eric, Fabric3 announced conformance to Assembly back in August 2011: And there was a follow-up resolution passed:
Part of our thinking at the time was that we were hoping the larger vendors would step up and contribute by using their runtimes to claim conformance to the other SCA specifications. This seemed like a reasonable request given the burden conformance places on open source projects with very limited resources. It also seems fair given: (a) all of the vendors agreed to stringent TC exit criteria at the outset; and (b) many of the vendors "piled on" features that make achieving conformance much more difficult (I won't enumerate them since I don't want to single any one out). One vendor has contributed significantly to conformance but to my knowledge none of the others have. My own preference that I did discuss with various members in the past was to decouple the specifications so that, for example, Assembly could exit without the need for Policy or Web Services. Each specification would stand on its own merit. It can also be argued that this is technically the right thing to do. It would promote modularity. In addition, it would better serve the needs of a wider user base. For example, while Fabric3 has users that have web services, it also has a number of users in Financial Services that have built low-latency trading systems which require much more performant transports. In a nutshell, I don't understand why the specifications have to be coupled as they are and why that can't be changed. In hindsight, it seems loose-coupling would be a better approach. At least it would allow parts of SCA to succeed without tying them to an albatros of features people don't want or need. This would be a normal process of adjusting course and learning from feedback. Maybe someone can explain why that approach was rejected in more detail? Fabric3 is actively pursuing conformance to the other specifications and we are growing adoption. Apache Tuscany has done the same. It may be the case that the open source projects have to cary the burden of pushing useful standards to completion, in this case SCA. However, something appears broken with a standardization process where organizations with significant R&D resources spend several years defining a set of standards and exit criteria and then fail to share the burden of finalizing them. If two open source projects can invest in conformance, why can't the member vendors? Jim On Tue, Feb 19, 2013 at 7:00 PM, Eric Johnson <eric@tibco.com> wrote: One of my OASIS-involved colleagues indicated that he hadn't seen this note from Jim Marino.
Hi, It was brought to my attention that the TC is considering closing. This caught me by surprise, particularly as it was asserted that there is only one active implementation, which I assume to be Apache Tuscany. Fabric3 (www.fabric3.org) also conforms to the Assembly TC and has active plans to claim conformance to other specifications. Given the breadth of the specifications, conformance requires a significant time investment. Closing the TCs down would derail the investment various runtimes have made in this effort. In addition, closing the specifications would hurt the industry in general as no standards exist that cover the same space as SCA. Is the only issue prompting a ballot for closure that lack of two conformant implementations? Jim --------------------------------------------------------------------- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]