> Unfortunately, what you can put in here is not particularly useful in
> specifying the semantics that your client understands. Just
> saying "Accept: application/xml" or whatever is clearly insufficient if
> you're looking for a business purchase order (for example) and only
> know how to process one or two concrete formats (whether specified
> through XML Schema or not).
"Doctor, doctor, it hurts when I declare that I accept application/xml !"
Don't do that. "application/xml" is largely meaningless.
If you want to declare support for a PO format, say "Accept:
application/purchase-order+xml".
There's no hiding going on. I've built several large, Web based,
machine-to-machine systems, some spanning many organizational and
political boundaries, and I've never needed something you'd recognize
as a service description language - at least nothing that resembles
the likes of IDL or WSDL. Having all services implement the same
application interface (HTTP) makes description of those interfaces
unnecessary. Only the data types need declaring, but that's a) part
of the role of a form, and b) discovered at runtime.
Mark.
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
