sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [sca-assembly] Concerns raised by Siemens
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
- Date: Wed, 6 Jan 2010 11:06:02 +0000
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.
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.
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.
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.
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.
Yours, Mike.
Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431
Email: mike_edwards@uk.ibm.com
From:
| Jim Marino <jim.marino@gmail.com>
|
To:
| OASIS Assembly <sca-assembly@lists.oasis-open.org>
|
Date:
| 18/12/2009 16:41
|
Subject:
| Re: [sca-assembly] Concerns raised by
Siemens |
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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]