Home/ Questions/Q 397043
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T16:36:41+00:00

I’ve just finished reading about SOAP via Spring-WS in Spring in Action, 2nd edition,

  • 0

I’ve just finished reading about SOAP via Spring-WS in “Spring in Action”, 2nd edition, by Craig Walls from Manning Publications Co. They write about Contract First, much like the Spring docs, with making a message and method XML and then transforming that to XSD and then again to WSDL, while wiring up the marshalling and service path in Spring.

I must admit, I’m not convinced. Why is this a better path than, let’s say, making a service interface and generating my service based on that interface? That’s quite close to defining my REST @Controllers in Spring3. Do I have options of going a path like this with making SOAP webservices with Spring?

Also: I’d like to duplicate an already existing webservice. I have its WSDL and I can have my service placed instead of it. Is this recommended at all? If so, what’s the recommended approach?

Cheers

Nik
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think you must have your wires crossed.

    Contract first means defining a WSDL, and then creating Java code to support this WSDL.

    Contract last means creating your Java code, and generating a WSDL later.

    The danger with contract last is if your WSDL is automatically generated from your Java code, and you refactor your Java code, this causes your WSDL to change.

    Spring-WS only supports contract first

    2.3.1. Fragility

    As mentioned earlier, the
    contract-last development style
    results in your web service contract
    (WSDL and your XSD) being generated
    from your Java contract (usually an
    interface). If you are using this
    approach, you will have no guarantee
    that the contract stays constant over
    time. Each time you change your Java
    contract and redeploy it, there might
    be subsequent changes to the web
    service contract.

    Aditionally, not all SOAP stacks
    generate the same web service contract
    from a Java contract. This means
    changing your current SOAP stack for a
    different one (for whatever reason),
    might also change your web service
    contract.

    When a web service contract changes,
    users of the contract will have to be
    instructed to obtain the new contract
    and potentially change their code to
    accommodate for any changes in the
    contract.

    In order for a contract to be useful,
    it must remain constant for as long as
    possible. If a contract changes, you
    will have to contact all of the users
    of your service, and instruct them to
    get the new version of the contract.

    • 0