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: NEW ISSUE: How to map WSDL 1.1. portType to WSDL 2.0 interface andvice versa?


Title: How to map WSDL 1.1. portType to WSDL 2.0 interface and vice versa?

Target document:  SCA Assembly Specification

Description:

Section 8 of the assembly spec talks about SCA interfaces. This section 
also defines <interface.wsdl>. <interface.wsdl> is allowed to point to a 
WSDL 1.1 portType or a WSDL 2.0 interface.

SCA specs require that all interface types are translatable to one 
another. For example, given a wsdl 1.1 interface the Java specs tell you 
how to map it to Java interface or vice versa.

But the assembly spec does not say how WSDL 1.1 portType is mapped to 
WSDL 2.0 interface and vice versa. There are several problems with this:

1) WSDL 2.0 interfaces supports features that are not present in WSDL 
1.1. For example, WSDL 1.1 does not have anything equivalent to the 
Robust In-Only MEP that is present in WSDL 2.0.

2) WSDL 1.1 portTypes supports features that are not present in WSDL 
2.0. For example, WSDL 1.1 has the concept of message parts and allows 
the message parts to point to a XML Schema Type. WSDL 2.0 does not have 
message parts, and WSDL 2.0 messages can only point to XML Schema GEDs.

3) WSDL 1.1 does not have a clean separate between abstract WSDL and 
concrete WSDL. The "operation signature" in WSDL 1.1 can be altered by 
the WSDL binding it is bound to. This makes it hard for the developers 
of a component to not care what the interface type is on the component. 
This can be mitigated by requiring compliance to WS-I Basic Profile 1.1 
(or later version)

Proposal:

There are two possible ways to fix this problem:

1) Subset WSDL 2.0 and WSDL 1.1 and define a mapping between the two.

2) Change the assembly spec to say that <interface.wsdl> => WSDL 1.1 and 
that WSDL 2.0 interfaces are not supported by this interface type. 
Anyone wanting to support WSDL 2.0 interface must utilize SCA's 
extensibility point and create something like <interface.wsdl2> and 
define the mapping between WSDL 1.1 and WSDL 2.0.

I prefer option (2). Mostly because: WSDL 2.0 is not supported by most 
tools. Latest release of JAX-WS does not support WSDL 2.0 and there is a 
note saying a future version of JAX-WS will do this. Mapping will 
require subsetting WSDL 1.1 and WSDL 2.0 and validating that the mapping 
is correct and complete. This is a non-trivial exercise and given our 
workload we should let someone else do this. Such a mapping is a general 
WS-* problem and having 'someone else' (perhaps a later version of 
JAX-WS) do this work may in fact be more appropriate. If and when such a 
mapping is available, SCA specs/implementations can support it.

If we adopt option (2) then this would require us to purge all mention 
of WSDL 2.0 in all the SCA specs and clarify that interface.wsdl's 
@interface attribute can only point to a WSDL 1.1 portType.

-Anish
--


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