OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fwd: [sca-assembly] Concerns raised by Siemens


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
Subject: Re: [sca-assembly] Concerns raised by Siemens

Mike,

Comments inline.

Jim

On Jan 6, 2010, at 12:06 PM, Mike Edwards wrote:


Jim,

I'd like to address the points you make - but I am going to separate this from the points made by Philipp, which I will discuss in a separate email.

Your point about these issues being brought up at the F2F meeting.
The agenda for the F2F included two sections on "Assembly Specification V1.1 completion", which included "consideration of remaining issues and work items"
- I agree that this did not list all of the issues individually, but the meaning of this is clear in my mind - ie that all issues open against the 1.1 specification would be
discussed.  And that includes the issues which dealt with the public comments from both Siemens and from Microsoft.


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.

It is unfortunate that you were not able to be present during the discussion.


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:

1. Including the interested parties.

I believe that there has been quite a lot of discussion of these issues on the Assembly mailing list - over the past months.
On a personal level, I posted several emails, where I attempted to summarize the main points of debate and the form that
any alternative solution would have to take.  The sorts of problems that these alternative solutions have were also discussed
both on the email list and during various TC calls.

As for comments made by TC members during the F2F - anyone is free to express their views and I would not subscribe to any
form of censorship.


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.

2. There is a satisfactory solution (Sanjay's)

Well, you may think that it is satisfactory, but that was not the consensus of opinion expressed at the F2F.  I urge you to make your
case to the TC that Sanjay's approach is satisfactory.

However, the consensus view was that it is difficult if not impossible to lay down rules that have any meaning once those rules involve
work done outside OASIS.  I think the view is that there must be 2 items in place to give any meaning to "conformance" when dealing
with a runtime that only implements implementation type(s) not standardized under OASIS

  a) A specification or document that describes the implementation type and its relationship to the Assembly model, in particular the
      componentType derivation must be spelled out in detail.


  b) A version of the test suite using the implementation type must be run against the runtime

We have not been able to establish a satisfactory way of assuring that both of these items are in place - and please note that this
is not about the technical format of the two items, but is about how it is possible to require both that they exist and that they are
open to inspection.
For example, the use of "copyleft" styles of license for the test suite to ensure that the test suite for the new implementation type is
available has not proved acceptable to numerous TC members (that group includes myself).

If someone can suggest a satisfactory approach to these two items, I am sure that the TC will be only too happy to listen - however,
I think it is a tough problem, with potential legal aspects that may require OASIS board approval.


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". 

3. Provide a Public Response

Yes, we agreed to do this and Martin and myself were given an action item to prepare the responses.
Christmas and other work commitments have slowed things up, but you will see that the proposed responses have been posted to the
Assembly mailing list today, prior to discussion and approval (hopefully) at the next TC meeting.



I agree with your desire that SCA should be as open as possible.  On the other hand, the question of "conformance" is an important one
since it helps provide both portability and interoperability between SCA runtimes of different vendors, one of the major goals of bringing
the SCA specifications for standardization in the first place.  We need to find a way of avoiding tossing the baby out with the bathwater
here.  It is clear that anyone can produce an SCA runtime which provides implementation types which are not those standardized at
OASIS - SCA is inherently extensible.  The problem concerns what it means to be "conforming to the SCA Assembly specification" -
what meaning and assurance can be given to such a statement.


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]