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: New Issue: Remove dependencies on SCA Policy and SCA WS Binding


Hi,

I would like to file an issue against the SCA Assembly Specification to remove the dependencies on the Policy and WS Binding Specifications. The goal is to properly modularize the specifications where WS Binding and Policy are layered on Assembly, with dependencies going only in one direction. 

I plan to write-up a detailed proposal after discussion on tomorrow's call. However, I would like to file the issue as a start.

Motivations
------------------

There are a number of motivations for this proposal:

(1) There is no technical reason why Assembly must be dependent on Policy or WS Binding. Fabric3 is an open source, fully conformant SCA runtime that can completely remove (not just disable) Policy and WS-* features via simple configuration (removal of JAR files).  

(2) Increase SCA adoption. Many people have commented that SCA adoption could be increased if runtimes could conform in steps as opposed to being confronted with a series of specifications to implement en masse. 

(3) Proper specification design implies that different technology concerns be modular. Currently, the SCA specifications are not modular in a proper sense since their dependency graph has cycles in it. It is important to note a modular approach has been adopted by other specifications such as Java EE, which has introduced the notion of profiles.

(4) Many use cases do not require policy or WS-*. Based on extensive implementation experience at large banks, software vendors, and governments, SCA works well with non-WS-* technologies such as RESTful APIs and high performance messaging. Siemens has also identified embedded systems and constrained devices use cases where WS-* is not appropriate. Further, many use cases do not require the complexity of Policy (particularly the external attachment features).   

(5) Interop is not impacted as it is still provided by the portability of Assembly artifacts. It is also common for interop to be provided with alternative technologies to WS-* such as AMQP, MQTT, REST with defined media types, or protocol buffers over ZeroMQ.

Also, it is important to note that this issue does not impact the TC Exit Criteria, as those have already been satisfied.

Jim
  


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