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: [sca-c-cpp] ISSUE 17: Should C++ -> WSDL Roundtrip with WSDL -> C++


I've done another review of the OMG specification, and have some more
information concerning compatibility and whether round-tripping can be
supported.

- The round-trip from C++ -> WSDL -> C++ can't be guaranteed.  C++ has
many constructs that can map to roughly the same WSDL structure.  For
example, a std::string and a const char* parameter will both map to an
xsd:string in schema.  It won't be possible to guarantee a roundtrip in
these scenarios without extensive annotations to record the original C++
type and structures in the generated schema.  

- The round-trip from WSDL -> C++ -> WSDL may be definable, as long as
the rules for constructs generated from WSDL have the same rules for
mapping WSDL back to C++.  Even then, without source annotations, it may
not be possible to guarantee a roundtrip.  If a schema element has a
name like "my-name", this can't be directly mapped to a C++ name, so
some transformation will be applied (OMG doesn't appear to define rules
for this transform).  For this example, let's assume the '-' is
converted to '_'.  This results in a C++ element named "my_name".  When
converting back to a schema, there's nothing that indicates "my_name"
should be transformed (it's a legal schema name, so it will not be
changed.

- It should be possible to guarantee that WSDL1 == WSDL2 in the scenario
C++ -> WSDL1 -> C++ -> WSDL2, since any name conversion issues should be
resolved in the initial conversion from C++ -> WSDL1.  Likewise, we
should be able to guarantee C++1 == C++2 for WSDL -> C++1 -> WSDL ->
C++2.

- Most of the OMG document specifies the mapping of Schema elements
(particularly complex schema elements) to C++ class hierarchies.  I'm
not sure this is something strictly needed by SCA, since users could
presumably use SDO types for complex data (OMG doesn't speak to SDO
types).  

- OMG defines a number of namespaces, types, exceptions, etc... that it
relies on in it's spec.  None of these types are currently recognized by
the SCA C++ -> WSDL definition (explicitly, some may work implicitly due
to rules around following typedefs).  If we expect users to use the OMG
rules for WSDL -> C++, we should probably explicitly talk to some of
their types, in the same manner that we talk to some of the primitive
types and SDO.


Based on what I've gathered so far, I'm not sure it makes sense for the
SCA C++ spec to rely on the OMG specification for it's WSDL -> C++
mapping.  While OMG does define a variety of good models for various
scenarios, it also imposes quite a bit of its own constructs on to the
model.

I'd like to propose the following basic changes (we can work out a
formal change proposal if this basic approach is acceptable)

1. Specify a WSDL -> C++ mapping based on our existing C++ -> WSDL
mapping, in a manner similar to how it's handled in the C spec.  We can
use the OMG spec as a reference to make sure that any key issues are
covered; however we don't need to follow their specific conventions.
This should make it easier for us to specify schema extensions, similar
to SDO, for configuring the names and types of various elements.

2. Clarify the language for both WSDL -> C++ and C++ -> WSDL (and most
likely the C spec as well) that the mappings described are REQUIRED to
be supported by a compliant implementation, however also indicate that
specific implementations MAY support alternative bindings as well.  This
opens the door for vendors to continue to support the OMG binding, and
potentially other mappings as well.  We can maintain the OMG reference
as a non-normative association.

What does everyone think?

Thanks.

David.


-- David Haney
-- Chief Architect, Hydra Products
-- Rogue Wave Software
-- http://www.roguewave.com/ 




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