[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] Concerns raised by Siemens
Jim, Because of the formatting and indentations, it’s hard for
me to see what questions you are asking. Can you summarize them so there is no ambiguity? Also while I’m happy to have a dialogue like this on email,
I would not advise starting work on a proposal while the issue is in a closed
state. Finally I would point out that most TC members who voted to
close no action, expressed a desire to find a solution to this in the 1.2 timeframe,
so it’s not going to be completely buried and forgotten. Martin. From: Jim Marino [mailto:jim.marino@gmail.com] Hi, I would like for this not to drop off the radar. I'm willing
to put forth a proposal, but listed a set of questions below to help me do so.
Mike or Martin, can you please respond when you get a chance? Thanks, Jim Begin forwarded message:
From: Jim
Marino <jim.marino@gmail.com> Date: January
8, 2010 4:15:06 AM PST To: OASIS
Assembly <sca-assembly@lists.oasis-open.org> 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.
Given the timezone I (and others) live in, it was not
practical to attend the meetings in their entirety. although I made an effort
to attend as much as possible.
Turning to your numbered points: I don't think anyone is asking for censorship, quite the
contrary. My point was several comments made during the discussion at the F2F
were not conducive to working with the people/organizations that raised the
conformance issues. In my opinion, that is a fair and valid criticism.
Sure I would be happy to look into this. In order to do
this, I want to clarify a few points upfront as it will help focus my efforts: 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".
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]