Re: [sca-assembly] New Issue: Remove dependencies on SCA Policy and SCA WS Binding

[Jeff Mischkinsky <jeff.mischkinsky@oracle.com>]

Hi,
  I think these 2 issues should be separated and considered independently, as they are very different beasts.

  My comment on SCA Binding is that i can see an argument that WS* has not exactly taken over the world, BUT then i would ask you WHAT binding would you substitute in its place?
The reason WS Binding is mandatory is to provide a guarantee that SCA is "out of the box" interoperable. WS* was chosen as the lowest common denominator, 5+ years ago, when SCA was actively being developed.
So if you have a better idea of what a lowest common denominator binding, required so that users are guaranteed that they can actually interoperate, please propose that.

In point 4, is it not the case that it is hit or miss as to whether a user will be able to interoperate with servers depending upon whether they are using the same non-standard proprietary bindings?

BTW: I don't think your notion of interoperability is standards based. Sure its true i can make my stuff work with your stuff if we privately agree on how to do that. The notion of STANDARD interop is that we don't have to privately agree on anything, even if the binding is based on some standard protocol.

The path you outline would remove the guarantee of out of the box interop. If you can convince the community that is not needed any more, then removing the requirement for mandatory binding(s) would be ok.

cheers,
 jeff

On Sep 16, 2013, at 5:08 PM, Jim Marino wrote:

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

--
Jeff Mischkinsky			          		jeff.mischkinsky@oracle.com
Sr. Director, Oracle Fusion Middleware 				+1(650)506-1975
	and Web Services Standards           			500 Oracle Parkway, M/S 2OP9
Oracle								Redwood Shores, CA 94065