[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
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
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,
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.
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.
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.
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.
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.
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]