[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Concerns raised by Siemens
Mike, Comments inline. Jim On Jan 6, 2010, at 12:06 PM, Mike Edwards wrote:
For the record, these are not just issues raised by Microsoft and Siemens but also members of the TC (at least myself :-) ). The agenda I was aware of is here: On Tuesday, the 13:00PST timeslot was allocated for "Assembly Specification V1.1 completion consideration of remaining issues and work items" and Thursday 11:00PST was scheduled for " Assembly Specification V1.1 - slot for any follow up discussions and actions". While the meaning may have been clear to some, in my opinion the agenda was very ambiguous in this respect. More importantly, the issue was not handled in the best way or with the goal of engaging in a real discussion. Sanjay submitted a proposal a while back which resulted in positive comments by a number of people. Then, after some time, the issue was voted closed toward the end of the F2F. Reaching out to the people who raised the issue (many of whom are TC and/or OASIS members) would have been more productive and could have lead to a more satisfactory result for everyone involved. However, I don't want to belabor this point further as it is taking attention away from the core issues. This agenda was also discussed at previous TC conference calls, and the objective of closing out ALL remaining issues at the F2F was made clear. Turning to your numbered points: 2. There is a satisfactory solution (Sanjay's) 1. There are no technical objections. The issue is about how to enforce items A & B mentioned above? 2. Why was the "copyleft" style license unsatisfactory? 3. What guarantees are in place to ensure a vendor claiming conformance to the existing SCA specifications does in fact conform? I'm assuming there is nothing legally binding and the only check in place is "public opinion". 4. What guarantees are in place to ensure a vendor makes their software and any necessary artifacts to run the SCA conformance tests available? Again, I'm assuming there is nothing legally binding and the only check in place is "public opinion". 3. Provide a Public Response I would like to address the claim that allowing alternative implementation types will impede portability. This is a red herring. Opening the specifications will have no practical impact on the state of application portability since SCA is not very portable in the first place. This is due to a number of reasons, including (as you mentioned) extensibility and the fact that most applications will require proprietary vendor features. For example, in my experience implementing a number of SCA systems (and an SCA runtime), here are a few of the portability issues that were encountered: 1. SCA Policy does not mandate a policy language. This means there is no guarantee policy configuration will be portable across vendor implementations. 2. Using implementation.java, there is no standard way to access a database. Code that needs to access a database - including via JDBC - must use proprietary features to do so. With Fabric3, we had to build a significant amount of proprietary infrastructure to support data access, including support for JPA EntityManager injection and transaction enlistment. Even making the most basic JDBC connection using Class.forName() will be proprietary as it requires JDBC drivers to be visible from the component implementation's classloader. 3. The security APIs available in the languages are insufficient for most applications 4. There currently is no way to spawn managed threads (although there is an open issue in the Java TC for this) 5. Integration with presentation tier technologies is not specified. 6. There is no standard way to obtain managed environment resources such as a transaction manager. Portability will be further hindered by the polyglot nature of SCA. Some runtimes may not support certain implementation types. For example, a conformant C++ or BPEL-based runtime may not be able to host conformant Java components. Given my involvement in SCA over the years, I'm not bashing it. However, it is important to be realistic about what it is and isn't. Otherwise, we run the risk of overhyped expectations such as those that were made in the past regarding J2EE "portability". That said, there is a definite "pattern" to portability. At the Assembly level, parts of applications can be made fairly portable through a combination of implementation.composite and import resolution. Basically, similar to what the Assembly conformance tests do. At the level of policy and implementation languages, there is much less portability. Given these restrictions, opening the specification to other languages will have no practical portability impact. Assembly artifacts can still be architected to be portable while the language-level and policy artifacts aren't portable anyway. ------ If you can respond to the questions above regarding the objections to the previous proposal to opening conformance, I will take a look at providing a revised proposal. Jim |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]