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: Re: [sca-assembly] New Issue: Remove dependencies on SCA Policy and SCA WS Binding


Hi Martin,

I guess I'm challenged with email and I accidentally sent a follow-up question to Martin privately ("reply") instead of publicly (reply-all).

For public record, my original question was:

Could you define what you mean by "enterprise"/"non-enterprise"? 

Sorry Martin to make you reply twice...

Jim



On Wed, Sep 18, 2013 at 12:14 PM, Martin Chapman <martin.chapman@oracle.com> wrote:

Phillipp,

 

I think the point is that if one wanted to do open heart surgery on the spec  to make it more suitable for non-enterprise scenarios, this has a different intention from the original charter and probably a different set of interested parties. Therefore some form of a chartering exercise might be required.

 

Martin.

 

From: Konradi, Philipp [mailto:philipp.konradi@siemens.com]
Sent: 17 September 2013 18:18
To: OASIS SCA Assembly


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

 

Thanks for discussion on the call.

 

Positive is that the discussion went so far towards details on how to separate assembly from the rest, rather than fundamental objections: which spec version, will wsdl still be the common remotable interface description…

 

There been also comments on the call like: SCA target is Enterprise domain… need to create another TC if we want to go that route…

Can you explore more, why you think so?

 

Thanks,

Philipp

 

 

From: sca-assembly@lists.oasis-open.org [mailto:sca-assembly@lists.oasis-open.org] On Behalf Of Konradi, Philipp
Sent: Tuesday, September 17, 2013 10:40 AM
To: Jim Marino; OASIS SCA Assembly
Subject: RE: [sca-assembly] New Issue: Remove dependencies on SCA Policy and SCA WS Binding

 

The fact is, there is no common denominator for interop communication. There are plenty of standards out there, each targeting interop in some way.

WS* may be relevant for some enterprise applications, but for SW which is used in cars, buildings, factories it’s (almost) totally irrelevant.

And even if there would be one now, technology evolves (much faster than standards do, and at different speed in different industries) and whatever we’d agree now, it would be not / less relevant for a lot of users at the time specs get released. The current issue with our WS* binding specification which struggles against the argument REST is more relevant now, is not an exception, rather the rule.

 

So I think the TC would do the SCA community a favor, if SCA evolves towards modularity and independence of its parts, this way speeding up the standardization process, lowering the barrier for providers to adopt SCA while enabling them to focus on (interop) offerings which matter to their target groups.

 

Thanks,

Philipp

 

 

From: sca-assembly@lists.oasis-open.org [mailto:sca-assembly@lists.oasis-open.org] On Behalf Of Jim Marino
Sent: Tuesday, September 17, 2013 5:04 AM
To: OASIS SCA Assembly
Subject: Re: [sca-assembly] New Issue: Remove dependencies on SCA Policy and SCA WS Binding

 

Thanks for the thought provoking response.

 

Comments inline.

 

Jim

On Tue, Sep 17, 2013 at 4:12 AM, Jeff Mischkinsky <jeff.mischkinsky@oracle.com> wrote:

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?

 

This question can be interpreted in at least two ways. I'll take it to mean what remote transport/protocol combination would I use for general interoperable communication between remote services. My own opinion is that interop only really needs to be a concern where both ends cannot make assumptions about the other. In some cases, this may be the majority of the time (e.g APIs available over the web). However, in many other situations, this is only a small part of a much larger picture.

 

The answer to the question is, "it depends". Where latency requirements are relaxed (e.g. Java-based applications that can be subject to full CG cycles), a REST over HTTP approach with an understood and documented media type using JSON or XML works well. In these cases, however, I have found the design of the service (or resource) is much more important for achieving useful interoperability than the particular technology used to represent data over HTTP.    

 

Most of the SCA applications I deal with, however, have very strict latency and/or reliability requirements. For example, forex trading platforms typically cannot allow full CG pauses during normal business operation because the 99 percentile latencies (the most important) will go out the window. For these scenarios, I would recommend SCA use a messaging technology specifically designed for low latency. Several vendors who are members of the Assembly TC have products in this space which work across languages/programming stacks.

 

If you want interop in the "classic" sense for the previous scenario (a "standard", no need to use a "common middleware layer"), my recommendation would be to look at AMQP or ZeroMQ. Both are standards (or nearing completion as standards) and are specifically designed for low-latency communication. I prefer brokerless solutions as I believe that is the way messaging architectures are evolving for performance reasons so ZeroMQ is my personal favorite.

 

There are also other use-cases where different technologies may provide better interop options. For example, Siemens has highlighted how they are using SCA in the context of constrained devices. MQTT is an excellent candidate for these scenarios.

 

This is why I think it would be valuable to begin work on additional SCA bindings, particularly for AMQP, MQTT, and ZeroMQ. Doing so would provide the additional benefit of specifying how SCA fits with other OASIS standards in application architectures.

 

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.

 

I think it is important to be very clear about what is meant by "interoperability" and, more specifically, what its limits are. The SCA specifications do not mandate 100% interoperability "out-of-the-box". Specifically, the  WS Binding section dealing with interop for callbacks (Section 5) is optional. This means for a significant number of SCA interaction patterns, there is no "out-of-the-box" interop. 

 

This should not be taken as a criticism of SCA in terms of interop. I don't think it is realistic to expect any technology standard to offer complete interoperability for all cases. That was tried with CORBA and WS-*. Instead, I would like to see SCA be pragmatic about interop by providing a number of *options* people can select based on their requirements. That was the original design intention of many of us who were involved at SCA before it was moved to OASIS. It would be useful to keep that in mind.

 


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?

 

This is not any different than what exists today with the WS-* Binding.

 

The bindings I mentioned are all standards, or close to becoming ones. Today, interop with the WS-* Binding is hit-or-miss since support for callbacks is optional. This leaves out one of the most compelling features in SCA - its async programming model.

 


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.

 

None of the bindings I mentioned require endpoints to "privately" agree on anything. The protocol rules and semantics are well-defined in standards and all of the bindings have multiple implementations in various languages. In fact, it is likely the case that the protocol rules and semantics are better defined in these standards than WS-* since they are based on additional years of experience.

 


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.

 

I disagree for the reasons above. I would argue out-of-the-box interop will be improved if we allow choice. It will enable users to select a technology appropriate to their requirements. More importantly, many of the *standards-based* protocols I have mentioned here are better suited to the interaction patterns and asynchronous capabilities provided by SCA. For example, ZeroMQ is much easier to map to SCA wire semantics than WS-* since it has an extremely well thought-out design that specifically addresses asynchronous messaging. I could say the same about other standards such as AMQP and MQTT.

 


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






 

This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation

This message and any attachments are solely for the use of intended recipients. The information contained herein may include trade secrets, protected health or personal information, privileged or otherwise confidential information. Unauthorized review, forwarding, printing, copying, distributing, or using such information is strictly prohibited and may be unlawful. If you are not an intended recipient, you are hereby notified that you received this email in error, and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system. Thank you for your cooperation




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