Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Which is the better approach to web services - contract first or contract last?

Which is the better approach to developing web services; contract first or contract last?
What are the advantages and disadvantages of each?

Which do you have experience with?

EDIT This question is about the implementation of a web service (read: SOAP) The question is whether the implementation classes should be coded first and the WSDL and XSD schema generated from that (contract last) or the WSDL and XSD schema written first and the implementation classes generated (contract first)

like image 456
Martin OConnor Avatar asked Apr 18 '09 17:04

Martin OConnor


People also ask

What is contract first and contract-last approach?

Contract-first means you design the way your services are going to communicate with each other before you design the services themselves. Contract-last is the other way around – you design how your service is going to work, then make one or more methods available as the interface for other services.

What is contract first approach?

The contract first approach is a way of designing and developing API's starting from a contract. Using the openAPI convention you can design your API and share it with your consumers and developers.

What is the contract first approach to building a SOAP web service with JAX WS?

There are two ways of building SOAP web services. We can go with a top-down approach or a bottom-up approach. In a top-down (contract-first) approach, a WSDL document is created, and the necessary Java classes are generated from the WSDL.

What is contract in SOAP web service?

In the contract-first web service, the “contract” (a WSDL definition of operations and endpoints and XML schema of the messages) is created first, without actually writing any service code. In the contract-last web service, existing logic is “exposed” as a web service and the contract is created at the very end.


2 Answers

Contract-first is the generally accepted 'best practice.'

It makes you be very clear with both the producer and consumer of the service exactly what is needed and what is expected. This becomes especially important when you start trying to convert java types -> xml types. You're also able to reuse schemas across different web service.

like image 70
Nathan Avatar answered Sep 27 '22 19:09

Nathan


I've used both approaches. My suggestion is to use contract first schema, but code first WSDL.

Writing a WSDL file has a lot of weird nuances like bindings, ports and such. I'd rather have this done by tools rather than by hand. There are tools to help do this, but none of them are simpler than

@WebService
public ...

At the very least you can verify your deployment.

For the schema, I suggested contract first because the XML Schema language is far richer than what you can describe in Java. An example I usually give is showing that XML Schema can restrict the size of a string and apply a regular expression pattern. Doing that in Java and annotations looks a bit messier.

Another advantage of doing the schema as contract first is the presence of tools to convert your schema file into HTML documentation.

The XJC tool can generate the requisite class files. However, I would only recommend doing that at start.

In the end you should take the generated WSDL file and work with that instead. That way you can use wsimport and verify that the whole thing from WSDL to Schema is valid.

You can deploy with the WSDL file by using the wsdlLocation attribute in your @WebService implementation and the application server will fix the binding data for you when users request the WSDL from the server, but you still retain your annotations. Otherwise your annotations will not appear on the requested WSDL files.

like image 35
Archimedes Trajano Avatar answered Sep 27 '22 19:09

Archimedes Trajano