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

["Konradi, Philipp" <philipp.konradi@siemens.com>]

“It's also worth noting that the original two proposals were to decouple Assembly from the Web Services binding and Policy. It does not necessarily follow that WSDL constraints should be removed from Assembly, although that would not be a bad thing.”

I agree with Jim. It’s worth to emphasize that:

a)      The question on the call has been whether Siemens would see interface description of remotable interfaces using wsdl as useful (since we support the decoupling of assembly spec from WS binding and people wanted to know how far we’d like to go). My answer was and is: No (IMO even for enterprise use cases).

b)      But as to the question whether I’d see it as absolutely necessary to be done together with decoupling of assembly and WS binding: No. Most important for us is to start moving, decouple the specs and release them as soon as possible. By doing so we’d ensure that this great standard and great work put into it can continue to evolve.

 

We can revisit the even better solution later (after as Eric said, gaining more feedback and experience from real use cases) under better circumstances.

 

Philipp

 

From: sca-assembly@lists.oasis-open.org [mailto:sca-assembly@lists.oasis-open.org] On Behalf Of Jim Marino
Sent: Thursday, September 19, 2013 3:45 PM
To: OASIS Assembly
Subject: Re: [sca-assembly] New Issue: Remove dependencies on SCA Policy and SCA WS Binding

 

Hi,

 

As I mentioned in the discussion on Tuesday and as I understand Eric's points, WSDL really isn't a "core" (understood as "indispensable"/"central",etc.) Assembly concept: it is a specific constraint for a particular situation. In fact, SCA originally did not require WSDL mappings in any form prior to OASIS. This constraint was added after the fact. This is one set of evidence that WSDL is not critical to Assembly.

 

The other evidence is empirical: Fabric3 does not rely on WSDL. Like Web Services and Policy, it can simply be removed and forgotten. The runtime will continue to work (actually, more efficiently :-)).

 

It's also worth noting that the original two proposals were to decouple Assembly from the Web Services binding and Policy. It does not necessarily follow that WSDL constraints should be removed from Assembly, although that would not be a bad thing.

 

I've already provided evidence in the form of the Fabric3 runtime that decoupling Assembly from WS-* and Policy is not only practical but can be done in a very simple way. A few people have made the contrary claim that Assembly is inextricably tied to Policy and WS-*. Can someone offer specific technical examples as evidence of why those specifications must be coupled? 

 

Jim

 

   

 

On Thu, Sep 19, 2013 at 8:57 PM, Martin Chapman <martin.chapman@oracle.com> wrote:

Eric,

 

You missed the discussion on Tuesday. The question was whether 1) it is possible to decouple and 2) whether to do the decoupling in v1.1 or v1.2.

Doing it in v1.1 MAY require work other than just playing around with conformance clauses.

 

Martin.

 

From: Eric Johnson [mailto:eric@tibco.com]
Sent: 19 September 2013 18:28
To: Martin Chapman
Cc: Mike Edwards; OASIS Assembly

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

 

Hi Martin,

On 9/19/13 10:07 AM, Martin Chapman wrote:

To do the job properly requires a re-examination of some of the out-dated core principles.

Hmmm.

One possible way to address that re-examination might be to decouple assembly from as many of the other specifications, and then let the implementations evolve. With actual experience implementing the specification across myriad different use-cases, the way to address those "out-dated" core principles might emerge. And then the standard could move forward based on existing practice, rather than guessing about the future.

In any event, as I've stated many times - mostly in conjunction with our 1.2 efforts - the existing specification language does not constrain one to using WSDL 1.1 for interface definitions. The only circumstance in which an interface must map to WSDL 1.1 relates to two distinct interface types, both marked remotable, and the conforming implementation is supposed to see if they're compatible. I've argued strenuously for relaxing this constraint to map to WSDL 1.1 for compatibility testing. I believe this is the only constraint that I can find that actually drives WSDL 1.1 interfaces.

Well, phooey. Just define a REST interface that is remotable to itself, and then see if implementations emerge that have a need to map to an interface type other than WSDL 1.1, for maximum compatibility.

Oh, wait, that would require actually letting Assembly become a spec, and then letting people experiment and build on top of it.

Drat, that's TWO reasons to vote for Assembly as a standard, and in just one short email!

:-)

Eric.

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

 

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