Featured Post

Applying Email Validation to a JavaFX TextField Using Binding

This example uses the same controller as in a previous post but adds a use case to support email validation.  A Commons Validator object is ...

Saturday, June 2, 2012

Editing Part Names in EA-Generated WSDL

Although wsdl:part supports both type and element attributes, it's best to use the element attribute.  When generating Sparx Systems EA WSDL, type is used by default.  This post demonstrates how to switch to element.

A wsdl:part defines a section of a wsdl:message.  The part can be described by a type or an element.  If a type is used, an element name will be generated behind-the-scenes based on the operation name.  The preferred alternative is to name your own element in the wsdl:types section and to use that name and namespace consistently throughout the document.

This post is based on an EA example from Fixing Element Names in EA-Generated WSDL Docs . In that example, toplevel elements (xsd:element) were added alongside complexTypes.  This makes the xsd:elements available by the Select Type dialog.

xsd:element and xsd:complexType Available in Select Type Dialog
To change the wsdl:part name,
  1. Navigate into the Messages section.  
  2. Press F9 to bring up the Attributes dialog.
  3. Select the attribute (OrderRequest in this case).
  4. Press the ... button next to the Type text box.
  5. From the Select Type window, select the element (rather than the complexType).
While both the type="" and the element="" attributes are supported by a wsdl:part element, the element attribute is preferred.  This gives you more control over the element and namespace then relying on the wsdl:part to define it's own root element.
Posted by at

5 comments:

  1. AnonymousMarch 27, 2014 at 1:33 PM

    Hi, I see you have posted a few times on EA's ability to generate code (java, wsdls, etc.). How often do you actually use these features? Are you actually using the generated artifacts during implementation? or are you just using the artifacts to prescribe what should be written?

    ReplyDelete
    Replies
    1. CarlMarch 27, 2014 at 1:42 PM

      Hi,

      I don't generate Java code from EA. I prefer to work with the code in Eclipse only. I've tried a few times, but the round-trip model updates aren't perfect and the resulting models aren't too helpful. I model Java code for specification and design purposes all the time, and there is a relationship between the UML I model and the .java files, but not one that's enforced in the tools.

      I regularly generate WSDL from EA and this does produce a huge value. The WSDL I generate is exported into Git where it is part of a build process based on Maven's CXF code generation plugin. The generated code is created as part of the build and compiled along with "real code" from Git. This is a one-way process. I only update the WSDL (and hence the definitions in the Java code) through EA and export the WSDL into Git.

      Delete
    2. AnonymousMarch 31, 2014 at 12:51 PM

      Thanks Carl,

      That affirms what I have been observing as well. The Java code coming from EA isn't compile ready. The generated artifacts also seem to be causing more confusion than its resolving among my developers.

      We are also building a web service domain model and using maven's cxf plugin. I was trying to generate java from EA so that we could use cxf's "wsprovide" utility. Generating the WSDLs in EA seemed like an error-prone multi-step process, but I will review that procedure.

      It's good to see how EA is being used in everyday practice. Appreciate your feedback.

      Tim

      Delete
    3. CarlMarch 31, 2014 at 1:22 PM

      The trick to making this work is not EA-related. EA generates a WSDL that you can put in configuration management. That WSDL can be maintained outside of EA if you ever want to use a different authoring tool or hand edit the files. In practice, I'm only using EA so that I don't ever have to re-import modified WSDL and risk having something lost in translation.

      You need a strategy to cordon off the generated code (not put in CM) with the rest of the source code. Using the CXF plugin, I generate Java code from the WSDL. For a split second (before generate-sources), my build is broken. However, once the generate-sources phase is hit, all of the code is in place for the Maven compile.

      Design-wise, I work with the generated code in a few key places, translating them quickly to domain objects for general usage.

      The bottom line: if i export an incompatible WSDL from EA, my CM-maintained Java code (usually XML -> domain object mapping) breaks right away. If the WSDL is compatible, then the changes are available to my Java code (non-generated) for the new requirements.

      Delete
    4. AnonymousApril 1, 2014 at 1:18 PM

      thanks again carl, your strategy makes sense but i'm getting tripped up on some of the details.

      What I'm finding is that EA generates a WSDL that omits references to external XSD's. By giving the schema in the EA wsdl project a filename it seems to generate the schema as a seperate .xsd (which is good). However, the wsdl does not include an "xsd:import" statement in the "wsdl:types" section to reference this new .xsd file (not good).

      This means that the WSDL doesn't pass WS-I compliance tests (tested in SOAP UI) immediately after being generated.. which makes sense because referenced datatypes can not be resolved using only the info in the wsdl. Simliarly, all the type declarations in the wsdl are not qualified with a namespace. Thus declared types that do exist in an external xsd (once properly imported) will still not resolve.

      Have you found a way to tweak EA so that generated WSDL artifacts don't have to be further massaged (adding xsd import statements, namespace qualifiers, etc.)? Currently the artifacts are not implementable. If I have to massage the wsdl further, ROI for the tool is diminished. especially since that means that using the "Generate WSDL.." functionality will be overwriting any tweaks that I make "downstream".

      Also, I'm not sure that I would want to keep a WSDL in CM that isn't WS-I compliant.

      appreciate the dialog!

      Tim

      Delete

Subscribe to: Post Comments (Atom)