OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-c-cpp message

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


Subject: RE: [sca-c-cpp] ISSUE 17: Should C++ -> WSDL Roundtrip with WSDL -> C++


Attached is an updated version, with initial examples for some of the C++ annotations.  @WebService, @WebFunction (was @WebMethod), and @Oneway examples are complete.  @WebParam is in progress, however the associated WSDL fragment has not been updated. 

 

Thanks.

 

David.

 


From: David Haney [mailto:haney@roguewave.com]
Sent: Wednesday, August 13, 2008 5:06 PM
To: Bryan Aupperle; sca-c-cpp@lists.oasis-open.org
Subject: RE: [sca-c-cpp] ISSUE 17: Should C++ -> WSDL Roundtrip with WSDL -> C++

 

I haven't had a chance to add any examples to the document yet, however I have made a few updates based on last weeks call and some of the comments in Bryan's email.

 

- Updated the handling for namespaces indicating that the default C++ namespace or WSDL targetNamespace is implementation defined, and that implementations should provide a mechanism for overriding these default locations.

 

- Updated targetNamespace for WSDL extensions to match convention used by BPEL spec. (slightly modified).

 

- Added a new WSDL annotation cppType (based on JAXB's javaType) to allow customization of the mapping between XSD and C++ types.

 

- Added a new annotation, XmlAdapter, to provide similar functionality to the cppType annotation.

 

- Provided a comment based on the Java spec indicating that for the purposes of SCA, all pure-virtual, no state classes are treated as if they had an @WebService annotation with default values.  I believe that covers the issue of consuming an un-annotated C++ class.

 

The updated version is attached.

 

Thanks.

 

David.

 

 


From: Bryan Aupperle [mailto:aupperle@us.ibm.com]
Sent: Monday, August 11, 2008 7:54 AM
To: sca-c-cpp@lists.oasis-open.org
Subject: RE: [sca-c-cpp] ISSUE 17: Should C++ -> WSDL Roundtrip with WSDL -> C++

 


I've looked at the JAX-WS spec more fully and I think there are some areas we need to look at in a bit more detail.

1) A header file with no Web service annotations

If I read the JAX-WS specification correctly, then a file with no @WebService annotations would not lead to any portTypes being defined.  I think we want to be a bit more liberal than this.  If a file is used in an interface.cpp element then clearly the intent is for at least one class in the file to define an interface and if the interface is marked as remotable in the SCDL, then the interface has to map to WSDL.  So some options are:
- Each class in the file maps to a portType
- Each class with only virtual methods maps to a portType
- A class matching the name of the service maps to a portType
- A class identified on either a class or callbackClass attribute  of an interface.cpp method is mapped to a portType

The last option is probably the best from an SCA standpoint, but it requires having the SCDL at the time of the mapping.  The second option is perhaps the most generally useful.

2) Default parameter names when mapping from C++ to WSDL.

JAX-WS says that without @WebParam annotations, the names parts/elements corresponding to method parameters are named arg1, arg2, ... I realize that this covers the most general case where in a virtual method declaration parameters are not themselves named, only typed.  However, in the case where parameters are named in the declaration, I think it would be desirable to use the name in the parameter mapping.

3) We already identified that we will need examples parameter mapping, but some explanation may be needed as well.  Section 3.6.2 of the JAX-WS specification talks about wrapper beans, request beans, and response beans.  We clearly need to talk about how C++ is different here.  I don't have any specific thought just yet, but I hope to before our next call.

Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect
Master Inventor

Research Triangle Park,  NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

"David Haney" <haney@roguewave.com>

08/05/2008 08:35 PM

To

Bryan Aupperle/Raleigh/IBM@IBMUS, <sca-c-cpp@lists.oasis-open.org>

cc

 

Subject

RE: [sca-c-cpp] ISSUE 17: Should C++ -> WSDL Roundtrip with WSDL -> C++

 

 

 




I’ve taken a second pass at providing a C++->WSDL / WSDL->C++ mapping, however this time instead of attempting to completely define the mapping in our spec, I’ve referenced the JAX-WS spec, and have provided guidance for applying that specification to C++.  There are some areas where the behavior is different enough that JAX-WS doesn’t apply and we still have to define the behavior ourselves, however much of the work around defining the mapping of WSDL portTypes/bindings/operations to Java classes/methods applies equally well to C++ classes/member functions.  
 
Pros:
-          We don’t have to reinvent the wheel and define a complete mapping ourselves.  We can rely on an established mapping, augmenting it as necessary so that it can be applied to C++.
-          We provide some level of interoperability between the SCA C++ and SCA Java specifications, as SCA Java also relies on the JAX-WS binding for defining their mapping.
 
Cons:
-          JAX-WS only defines a mapping to WSDL 1.1, so we also will only be defining a mapping to WSDL 1.1.  This limitation also applies to the SCA Java spec, so we can follow their lead in terms of how we’ll address a WSDL 2.0 mapping.
-          Our C++ implementation is relying on a Java specification, which seems a little odd.
 
The current draft is still pretty rough, and needs examples throughout, however I think it provides a more complete mapping than the previous proposal.  Main areas of work will be the incorporation of examples (which will probably result in minor changes to the described APIs), as well as cleanup around fault/exception handling.  We also need to provide some clarification around how the SDO data bindings will be handled in this system, and how we’ll roundtrip between WSDL and C++ if parameters are defined in terms of complexTypes (which will map to commonj::sdo::DataObjectPtrs, which lack the type information to roundtrip without code generation of those types).
 
We can discuss this at this week’s meeting, and see if we want to pursue this approach, or if we should revert back to enhancing the previous proposal.
 
Thanks.
 
David.
 
 

 



From: Bryan Aupperle [mailto:aupperle@us.ibm.com]
Sent:
Wednesday, May 07, 2008 11:41 AM
To:
sca-c-cpp@lists.oasis-open.org
Subject:
Re: [sca-c-cpp] ISSUE 17: Should C++ -> WSDL Roundtrip with WSDL -> C++

 

As promised...

Upon further study, the real distinction seems to be based on if messages have one part with a type defined by a schema element or potentially multiple parts each with a type defined by a schema type (simple or otherwise).


As far as I can tell the difference between doc-literal and wrapped doc-literal has to do with the rules for the name of the schema element describing the request message at least as far as the WSDL goes.  If I am missing something here, I would love to be enlightened.  I do not suggest distinguishing between these.


In any event, I still believe we have to address both ways of describing messages and this document has revised mapping rules based on those David described last week as well as the WSDL fragments promised below.



Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

Bryan Aupperle/Raleigh/IBM@IBMUS

05/05/2008 04:30 PM

 

To

sca-c-cpp@lists.oasis-open.org

cc

 

Subject

Re: [sca-c-cpp] ISSUE 17: Should C++ -> WSDL Roundtrip with WSDL -> C++


 

 

 

 






As I think about this some more, we are going to have to address mapping from WSDL for at least rpc-literal, doc-literal and wrapped doc-literal.  We could try and limit this, but the reality is that all three styles are in use.


In the reverse direction I believe that again, we cannot ignore doc-literal or wrapped doc-literal since these are popular, and interoperable styles.  We can discuss if we need annotations to control which style is to be generated or leave it  to be specified in an implementation dependent manner (e.g. tool preference).


David has stated the basic principles but now we need to apply them to each style.


I'll try to work on some WSDL fragments of each style that illustrate the principles.


Bryan Aupperle, Ph.D.
STSM, WebSphere Enterprise Platform Software Solution Architect

Research Triangle Park,  NC
+1 919-254-7508 (T/L 444-7508)
Internet Address: aupperle@us.ibm.com

"David Haney" <haney@roguewave.com>

04/29/2008 07:53 PM

 

 

To

<sca-c-cpp@lists.oasis-open.org>

cc

 

Subject

[sca-c-cpp] ISSUE 17: Should C++ -> WSDL Roundtrip with WSDL -> C++


 

 

 

 






Attached is some initial work around redefining the C++ -> WSDL and WSDL
-> C++ mapping.  It still needs quite a bit of work, but there may be
enough there to start discussing whether it's a direction we want to
take.

Thanks.

David.

-- David Haney
-- Director of Architecture
-- Rogue Wave Software
--
http://www.roguewave.com/


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php [attachment "wsdl-cpp-mapping-2.doc" deleted by Bryan Aupperle/Raleigh/IBM]

wsdl-cpp-mapping-20080827.doc



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