Contract definition language

[marklittle]

We need some way of defining the contract between client and service. There are various levels to this, including (but not limited to):

(i) what service the service provides (!)
(ii) what non-functional aspects the service provides (e.g., is it secure, is it transactional - policies).
(iii) QoS aspects (uptime, reliability etc.)
(iv) MEPs supported (includes protocols, such as HTTP, JMS, RMI, IIOP, ...)

Now JBI uses WSDL 1.1 and 2.0 for some of this, but I think that's far too Web Services specific (and it's darn difficult to parse for humans!) Others agree (http://searchwebservices.techtarget.com/tip/1,289483,sid26_gci1120180,00.html?bucket=ETA)

This isn't something we have to solve perfectly, but we need a starting point. Obviously whatever we come up with needs to be translatable to-from other formats (like WSDL), simply because existing services will be defined in those languages. But within the ESB, I'd prefer we worked in something more "native" and less baroque.

[heiko.braun]

IMHO using WSDL has many benefits to it:

- poeple now it
- existing tools work with it
- the ws-* specifications, which jbossesb seems to inherit, are based on wsdl.

The last point is probably the most inportant one. If we come up with our own definition language we need to incorporate these specs (or concepts) somehow. Just think of WS-Addressing and WS-Policy.

On other hand it already incorporates abstractions that fit well into the esb concept.

I cannot imagine that we come up with a propriatary description language thats anyhow simplier and less complex then wsdl.

[marklittle]

WSDL is fine if you're in a Web Services world and even then up to a point. It isn't a generic contract definition language. A combination of WSDL and WS-Policy gets you a little closer to things, but even then you can't define meta-data easily, such as SLAs. WSDL tools are also pretty poor for working at the SOA level: most take the approach of distributed objects, which isn't what SOA is about.

Finally, WSDL isn't simple! WSDL 2.0 adds more complexity. We should add nothing to the ESB that acts as a barrier to adoption and ease of use. People who are using JBossESB for Web Services may well expect to see some aspect of the contract definition appear in XML and WSDL. People who are using JBossESB for REST, JMS, or anything other than Web Services, may not expect to see WSDL anywhere.