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

[Jim Marino <jim.marino@gmail.com>]

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