Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News Article: "Code First" Web Services Reconsidered

Article: "Code First" Web Services Reconsidered

The most common approach to web services development is to start from code, and generate an XML Schema and WSDL definition. Most web service advocates consider this "wrong", the reason being that this often leads to interoperability problems and a very tight couping between implementation and interface artifacts. Instead, they argue one should start with a WSDL file, and then generate implementation code – possibly for different consumer and provider frameworks.

In a new InfoQ article, Dennis Sosnoski questions this conventional wisdom, and explains that most of the problems with the code-first (or "start-from-code approach, as he calls it) are rooted in the first generation tooling. He shows how the JiBX framework can be used to  practice start-from-code development without incurring the disadvantages, specifically without coupling implementation and interface too tightly.

See the article for more information.
We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • wow, a pragmatic approach to web services?

    by Jeff Payne,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Great article! Regardless of ones view point on the whole wsdl-fist vs code-first debate, one has to admit that sometimes it's just much more practical to start with the interface in code, especially if it's already been written and needs to be exposed as a service. Plus, I much rather deal with a generated WSDL a few times in the lifetime of a project than deal with generated source code day in and day out.

    One thing that Dennis doesn't mention is reuse. I seems like it would be a lot easier to reuse source code designed by the developer and not generated by a tool.

  • Re: wow, a pragmatic approach to web services?

    by anjan bacchu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Hi There,

    I am working on a "CONTRACT FIRST or WSDL first" project and find that the generated classes don't have an equals or hashcode generated for them. It would be nice if I could somehow get the WEBLOGIC 9.2 java code generator to do something like that.


  • Re: wow, a pragmatic approach to web services?

    by Rajbir Grewal,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Good point of view, I would also like to mention XmlBean binding also.This can be used for Document/Letral style web services. While working on web service on both BEA Workshop and Rational Developer
    I would say its much more easer to develop code first web service using document style in BEA workshop. RSA is more geared towards RPC/literal style. It would be nice if RSA can in corporate XmlBean binding (java2wsdl)in there WSDL generation from code. Using WSDL first (Contract first) approach is little complex and complexity will increase as we try to expose more operations in WSDL.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.