[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
s/medial/medical/ From: Martin Chapman There is no precise definition but generally enterprise software supports business process and needs of an organisation. As such the software needs to exhibit various qualities of volume, throughput, availability, reliability, transactionally etc but typically no one’s physical life depends on it i.e. no one dies or gets injured when it stops working. To support different deployment scenarios and qualities, enterprise software and related standards are usually designed with lots of flexibility and options - some argue too much J This can be contrasted with embedded, real-time or resource constrained environments used to fly airplanes, drive cars, run phone networks, medial systems etc. I can compare this with CORBA which was initially designed for general purpose distributed computing, and then had a parallel set of specs for a real-time and embedded environements – note both specs existed in parallel as the needs of both communities differed. Of course I suspect that are at least as many different characterisations as there are people, but the point being that SCA was originally intended to support a diverse but non-specific set of deployment scenarios. Martin. From: Jim Marino [mailto:jim.marino@gmail.com] 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]
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 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 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]