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: Fw: [sca-assembly-comment] Few comments from Siemens


A comment received from Siemens regarding the SCA Assembly public review...

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

----- Forwarded by Mike Edwards/UK/IBM on 12/06/2009 16:13 -----
From: "Konradi, Philipp" <philipp.konradi@siemens.com>
To: <sca-assembly-comment@lists.oasis-open.org>
Date: 12/06/2009 00:13
Subject: [sca-assembly-comment] Few comments from Siemens

Below are two comments from Siemens on the SCA Assembly Specification draft, Version 1.1 CD03, put for public review.


Comment 1


Chapter 13.2 "SCA Runtime", line 3874-3875:

"3. The implementation MUST support and comply with at least one of the OpenCSA Member Section adopted implementation types."


Siemens proposes to skip this conformance requirement for the following reasons:

a) This conformance requirement limits SCA implementations focusing on support of proprietary or domain-specific languages.

The following two cases fully apply to Siemens and probably to many other companies:

- a lot of proprietary, exotic programming & scripting languages exist and are used for system engineering and development.

- creation of domain-specific languages gets more and more important and is actively used for application development

Because of this language diversity it has been of big value for Siemens to see that SCA offers one common, language-independent model to assemble and wire components together.

The conformance requirement mentioned above means a considerable obstacle for users and implementers, who would like to use the SCA model and provide lightweight runtime implementations supporting SCA-Assembly, -Policy + a very specific implementation type, because it requires:

- either to standardize the proprietary language (which is often not an option since the language specification is not even public, the overhead & time required to get it through the standardization process are too high)

- or to implement support for another language to be able to claim conformance but which is actually not required and used by application.

At the same time for such a lightweight SCA runtime it's still important to be able to claim SCA conformance. Even company-internal providers need to offer to users some extent of standard compliance, with SCA assembly and policy model in this particular case, to assure usage of proved, widely used concepts, ease of extension as well as of migration.

The big advantage of SCA for our company has always been to have a model for building service-oriented applications which is totally independent of any programming language or communication technology. We'd like to see SCA stay as open as possible and supporting diversity where it's needed. We think that this conformance statement is too restrictive and doesn't facilitate broad acceptance of SCA.

b) This conformance requirement limits customization of an SCA runtime.

SCA runtime implementations are often build in a modular way and allow to install/uninstall implementation types or bindings. This conformance requirement does not allow customization of a runtime in a way where particular implementation types, which are currently not required by application (but required to claim conformance), don't get deployed (e.g. to decrease the memory footprint --> important for industrial use).

c) This conformance requirement doesn't really ensure portability if it has been the purpose of this statement.

A runtime which complies with this statement, and thus can claim being SCA-conformant, is free to deviate from SCA specifications when it comes to any other implementation type it supports.

If ensuring portability is the goal then we’d rather propose to rephrase the conformance requirement to something like: "If the implementation supports an implementation type adopted by OpenCSA Member Section then the implementation MUST support it in a compliant way."


Comment 2


Chapter 13.2 "SCA Runtime", line 3876-3877:

"4. The implementation MUST support binding.sca and MUST support and conform to the SCA Web Service Binding Specification v 1.1."

Siemens proposes to change this conformance requirement to the following statement:

"4. The implementation MUST support binding.sca."

for the following reason:

This conformance requirement considerably limits usage of SCA runtimes in the Industry. For most of embedded or industrial applications Web Services aren’t used at all. Other communication standards like BACnet are used in such applications instead. Requiring runtimes to bring support for Web Services will unnecessarily increase their footprint and prevent their usage on embedded devices, which is a really important use case for companies like Siemens.



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]