Discussions

News: Looking for a few good WSDLs

  1. Looking for a few good WSDLs (48 messages)

    SearchSOA (a sister site of TSS.com) has a new article up, called "Looking for a few good WSDLs," in which he's looking for examples of WSDLs in the wild that exemplify some best practices. The end result is meant to be a resource center focused on WSDLs for SOAP. The qualities of a "good WSDL" according to Thomas Erl (a domain expert for SearchSOA) are:
    • the service endpoint
    • each service operation
    • every input and output message supported by each operation
    • the data representation model of each message's contents
    • rules and characteristics of the service and its operations
    So! If you're using WSDL 2.0 or 1.1, WADL, or any other remote service endpoint description, send your suggestions and reasonings to mmeehan at techtarget dot com. If there's a way to do WSDL or WADL well, everyone should have a way to find it out. It'd also be interesting to see what other remote resource description protocols exist.

    Threaded Messages (48)

  2. The best WSDL is no WSDL at all[ Go to top ]

    This is the lesson we've learned as we've abandoned SOAP altogether...
  3. Re: The best WSDL is no WSDL at all[ Go to top ]

    This is the lesson we've learned as we've abandoned SOAP altogether...
    Fair enough! Do you do remote service invocation? How? Is it a public API of any sort? By that, I mean "do other organizations use it" as a black box?" If you do publish APIs, what's their nature? How do you validate inputs and outputs? Do your clients do any discovery on the services, so they can determine without your interaction what the service can do?
  4. Is it a public API of any sort?
    WSDL isn't really an API. I'd think if you were publishing a web service, you'd want to publish both an API (for each language) and the WSDL. For all of the minuses of CORBA, the IDL really did define an API.
    Do your clients do any discovery on the services, so they can determine without your interaction what the service can do?
    This idea has always sounded silly to me. The meat of any protocol specification is always the semantic definition, not the syntax. For example, the syntax of HTML and CSS is relatively straightforward, but the semantics require pages and pages of description, none of which can be automatically interpreted by client programs.
  5. Is it a public API of any sort?


    WSDL isn't really an API. I'd think if you were publishing a web service, you'd want to publish both an API (for each language) and the WSDL.
    The "public API" being referred to was the service, not thw WSDL.
    For all of the minuses of CORBA, the IDL really did define an API.
    Do your clients do any discovery on the services, so they can determine without your interaction what the service can do?
    This idea has always sounded silly to me.

    The meat of any protocol specification is always the semantic definition, not the syntax. For example, the syntax of HTML and CSS is relatively straightforward, but the semantics require pages and pages of description, none of which can be automatically interpreted by client programs.
    Sure. Yet the question remains. Personally, I'm a huge fan of WSDL, although I refuse to ask myself why, because I know that there's no sensible reason for it. It's archaic, really.
  6. Why would you need an API for each language? That sort of defeats the purpose. Services should not have APIs as such. With the document/literal style all you need is the message format for the operation you want and information about how to reach the end point. That is what the WSDL does.
  7. Why would you need an API for each language? That sort of defeats the purpose. Services should not have APIs as such.
    Assuming someone uses the service, they'll need to use some sort of API. The program will need to produce or consume messages whether they represented as strings, the DOM, JAX-RPC, JAX-WS, JAXB1, JAXB2, some custom serialization mapping, StAX, or just a raw HttpUrlConnection (which would be painful, but it's an API.) I was assuming the protocol designer/service provider wanted to help, but it's theoretically possible to push all the responsibility on the users. At that point, though, it's almost better to just use raw HTTP and document the payload format.
    With the document/literal style all you need is the message format for the operation you want and information about how to reach the end point. That is what the WSDL does.
    Someone needs to produce the message and consume it. You can't just handwave that work away.
  8. Re: The best WSDL is no WSDL at all[ Go to top ]

    The program will need to produce or consume messages whether they represented as strings, the DOM, JAX-RPC, JAX-WS, JAXB1, JAXB2, some custom serialization mapping, StAX, or just a raw HttpUrlConnection (which would be painful, but it's an API.)
    Interestingly, you can write a REST client program using nothing more than a raw HttpUrlConnection! The HTTP envelope contains a wealth of information (request method, resource path, incoming/outgoing content types, accepted content types, content length, protocol version, cache control directives, authentication/authorization headers, query parameters, path extra info, status codes, etc. etc.) that is basically ignored by SOAP clients/services.
    At that point, though, it's almost better to just use raw HTTP and document the payload format.
    HTTP itself does a pretty good job of documenting the payload format. RESTful web services leverage this information much better than SOAP-based web services do. SOAP-based web services use what is called "overloaded POST" in REST terminology, where every request uses the HTTP POST method (semantically the same as the SQL "update" operation), but where the intent of the message could be anything at all. That's why each RPC-style web service must define a new vocabulary (a set of verbs, or service methods) using WSDL that tells clients how to call the service. Basically a layer of abstraction (SOAP) on top of HTTP is needed because the information transmitted at the HTTP level is mostly ignored.
  9. Re: The best WSDL is no WSDL at all[ Go to top ]

    Interestingly, you can write a REST client program using nothing more than a raw HttpUrlConnection!
    True, but a REST service provider should provide a reasonable client API as well. Specialized users or unusual languages might need to write their own client protocol code, but most users should be able to use a pre-tested API written by the service provider. That API jar really should be the minimum expectation for any web service.
  10. Interestingly, you can write a REST client program using nothing more than a raw HttpUrlConnection!


    True, but a REST service provider should provide a reasonable client API as well.

    Specialized users or unusual languages might need to write their own client protocol code, but most users should be able to use a pre-tested API written by the service provider. That API jar really should be the minimum expectation for any web service.
    Agreed. Actually, an excellent example of this is spinn3r, created by a person I'm glad to call my friend, Kevin Burton. You don't actually call spinn3r with YOUR code at all, unless you're a freakazoid. :)
  11. Re: The best WSDL is no WSDL at all[ Go to top ]

    Specialized users or unusual languages might need to write their own client protocol code, but most users should be able to use a pre-tested API written by the service provider.
    This suggests to me that your experience with web services are very different from mine. In my case, we were building systems that were calling many different external web services with the same information (in different formats) and hosting a services to be called by many different clients using different protocols and message formats. Writing adapters for each hosts API would be a waste of our time and make it harder for us to build infrastructure for auditing and robustness. A client API would be useless to me unless it comes with source that I can use for reference. I can see how this is useful if you are trying to make it easy for small immature organization to use your service but for 'the enterprise' this can range from pointless to extremely aggravating depending on how hard the host tries to ram the API down my throat. In my situation, I know my infrastructure works because we tested it and have been using it. I know how it behaves when there is a failure. I know how it behaves under load. All third party code has a status of 'untested' when it I receive it, no matter what claims the provider makes. The real problem I've had with host provided APIs is that the provider can put too much logic in the API and mask serious design issues with the web serivce. I'm not saying don't create one but the API should be kind of an afterthought and not part of the web service design.
  12. But what about non HTTP transfer[ Go to top ]

    The nature of HTTP is (somewhat) stateless communication with absolutely no guarantee what-so-ever (delivery, at-most-once). I often use MQ (or JMS) as transport of SOAP messages in which SOAP based services simply "work better (out-of-the-box)" with ws-addressing. But I'll give you - SOAP can be a pain in the a**. Regards, Lars Borup Jensen http://www.it-arbejde.dk
  13. The nature of HTTP is (somewhat) stateless communication with absolutely no guarantee what-so-ever (delivery, at-most-once).
    I often use MQ (or JMS) as transport of SOAP messages in which SOAP based services simply "work better (out-of-the-box)" with ws-addressing.
    But I'll give you - SOAP can be a pain in the a**.
    One of the things that people tend to be confused about with regard to serivce-orientation is that the transport protocol is the most important thing. It's probably the least important thing about a service. If you make your service accept a specific XML (or JSON, etc.) there's no reason you can't send that same message using a messaging layer. My expectation where I work now is that we will need to support any number of transport protocols. Services are not defined by their protocol, they are defined by what they do. My favorite quote about SOAP as of late comes from one of the people who developed SOAP: "Box also stressed that XML Schema is the dominant technology for Web services. 'Had XML Schema been done in 1998, we would not have done SOAP,'" http://www.infoworld.com/articles/hn/xml/02/06/06/020606hnbox.html
  14. One of the things that people tend to be confused about with regard to serivce-orientation is that the transport protocol is the most important thing. It's probably the least important thing about a service.
    I'd say that depends... It depends deeply on the semantics of the service you are providing. For instance the (cliche) example of a bank transfer where a service is invoked to move an amount between two accounts - in this example its (damn) important the message is delivered once and only once.
    If you make your service accept a specific XML (or JSON, etc.) there's no reason you can't send that same message using a messaging layer.
    Well absolutely no, but how will you know in the receiving end which service to route the message too? (unless you a receiver for each and every service). You can ofcourse look at the message you have received and make some kinda mapping like: if first element is it must be the StuffService, but to avoid having to know anything about the specific message (for each service), WS-Addressing adds header info which can be used to route messages and you do not have to know anything about the core message. IMHO the biggest problem with SOA and Web Services is the missing possibility to span a transaction across two or more services...
  15. I often use MQ (or JMS) as transport of SOAP messages in which SOAP based services simply "work better (out-of-the-box)" with ws-addressing
    I have to admit I don't get the point of "SOAP over JMS/MQ". Unlike HTTP, there is no standard binding for JMS or MQ defined for SOAP. It isn't WS-I BP conformant - in short, you can't expect any sort of interoperability across platforms/implementations. Isn't universal interoperability the main point for using web services in the first place? If you don't need universal interoperability, why not just use something simpler that both sides already support, like plain old MQ?
  16. The reason for using SOAP over JMS is that you can support multiple delivery channels for a service with one piece of code. Case 1) you can front your service with an MDB or Servlet or both and you're done. Transports can change, ESBs can change and you don't care. Case 2) If you are using something like an ESB then you don't know what transport the client is coming in on. Your service may be using JMS, but your client is using HTTP. The ESB will jump your message from one to the other transparently for you. However, without the entries in the SOAP header, the HTTP side will not know how to manage your communications if you want something like guaranteed delivery, once and only once delivery, acknowledgements, notification, etc. Case 3) Vendors are looking to the WS-* standards as a way of bridging across products and transports while supporting the communication capabilities the service required. They use the SOAP header information to tell them what to do. Case 4) ESB-based and other run-time governance and management software and devices rely on their ability to read a standard format, i.e. a SOAP header, in order to transparently monitor SLAs, enforce policies, route messages, manage itineraries, and so on. In all these cases you could argue that you could use JMS and plain XML to do the same thing - just have the ESB insert your message in a SOAP body and generate the headers from the JMS header when your message moves to HTTP or when it hits the first ESB node. I don't know if any product does that. How would you handle some of the other standards such as what WS-Security or WS-Addressing supports without a SOAP header? (WS-Security is a superset of SAML and what your MOM software probably supports.)
  17. Re: The best WSDL is no WSDL at all[ Go to top ]

    HTTP itself does a pretty good job of documenting the payload format. RESTful web services leverage this information much better than SOAP-based web services do.
    The structure and content of the message is what is important. The format of the message is really a minor detail in the scheme of things.
  18. If my message is plain XML then all I need is an XML parser which is available in most any language. I may want an XML processing framework like dom4j or jdom that provides me an XML structure that is more language friendly and easier to process. Parsers and XML processing framework such as these are generic XML, not necessarily services. Databinding if I should choose to do it is also a generic XML function not specific to services. What databinding usually needs is the schema your messages conform to either at design time (e.g. JAXB) or run-time. There is nothing service specific about any of that. As far as my physical transport is concerned, I’d like choices – JMS, HTTP, others. A big part of what SOAP is about is that it gives you a way (through WS-* elements in the header) to define all sorts of transport requirements (guaranteed delivery, events, etc.) independently of the transport you end up using for a given message. That, in theory lets services support multiple delivery channels without special coding. Clearly this vision has not yet been realized and I can think of many reasons why it may never be realized. WSDL is supposed to give us away of tying together the service, its address, its operations, the required message formats and the supported delivery channels. That’s very useful and is something that can be processed and used at either design time or run-time (e.g. WSIF). If WSDL (and Schema) did not exist we’d have to invent them. You can argue about how good they are as solutions (not so great) but I don’t see how you can argue that solutions aren’t needed which I believe is one of Joseph O’s points. I do enterprise services and I know that I need solutions for the problems WSDL, Schema and SOAP solve. Using REST instead of SOAP is fine, but you then need to define your own protocol for supporting the capabilities you require. If you don’t require much and if HTTP is good enough, then you’re in good shape. If not, you have a challenge. Someone pointed out all the things you can include in you HTTP stream to handle many of the things SOAP-based WS-* address. What they didn’t point out is that the details and specific about how you should use these capabilities and interpret others’ streams has to be defined, i.e. an application protocol. As it stands HTTP defines what you can do more than what you must do. It’s the difference between can and must that leads to interoperability problems.
  19. As far as my physical transport is concerned, I’d like choices – JMS, HTTP, others.
    HTTP is more than a transport protocol, it's an application protocol. (Technically it's not a transport protocol at all, e.g. TCP/UDP, but for the purposes of our discussion I know what you mean). Thinking of HTTP as simply a transport protocol reduces it to only a subset of its capabilities. This brings me back to my earlier point that SOAP-based web services ignore much of the information in the HTTP envelope, while RESTful web services make more effective use of it. Since REST is tied to HTTP, but SOAP is not, this comparison can only be made when looking RESTful and SOAP-based web services that use HTTP (and not JMS or other transport mechanisms).
    I do enterprise services and I know that I need solutions for the problems WSDL, Schema and SOAP solve.
    I would separate things out a bit here. XML Schema is useful in many situations outside of enterprise services (e.g. XML data processing/validation), while WSDL and SOAP are useful only in the context of enterprise services. You can do enterprise services without SOAP and WSDL. I would also add that, by design, SOAP-based web services are more flexible/general (at the cost of increased complexity) because they are not tied to the web (i.e. HTTP), but then the question is, if a web service does not use HTTP, is it still a web service? I notice you avoided the term web services and used enterprise services instead. Was that deliberate? :-)
    Using REST instead of SOAP is fine, but you then need to define your own protocol for supporting the capabilities you require.
    I disagree. If you use REST, you are using HTTP as your protocol. You don't have to define a new one. Have you ever browsed the HTTP spec? It's quite detailed, actually. You have a message format and a uniform interface for all services. One of the most striking differences between SOAP and REST is that in REST all the service methods are already defined. So you might ask, what exactly does a RESTful web service designer do then? The key point is that RESTful web services are about resources (the nouns of the application), not service methods (the verbs of the application). REST emphasizes a resource-oriented architecture, where the important question to ask is, "which resources does your web service expose?", instead of "how do I talk to your web service?". REST clients already know to talk to your web service, and what they can do with your resources — they can GET, PUT, POST, and DELETE them. So the design activity in REST is therefore centered around which resources are exposed by the web service, how to address them (URI design), and which representations (content types, e.g. XML, JSON, HTML, serialization, etc.) are supported. Since most languages have an HTTP client library of some sort, writing REST clients in any language (e.g. Java, Ruby, Perl, C/C++, even AJAX, etc.) should not be a problem.
  20. Most of my response is probably covered in my response to James Watson. My argument is not for or against REST or HTTP and it is not in favor of a particular standard or standard implementation. My argument is that there are requirements - problems to be solved - functions to perform. These requirements are legitimate though not everyone shares them but they've been requirements for the enterprises I've worked at for at least the past 14 years. SOAP, WSDL, Schema and WS-* are open standards that are attempts to meet those requirements. We are not arguing over how well they do at that.
  21. but I don’t see how you can argue that solutions aren’t needed which I believe is one of Joseph O’s points.
    A lot of services are running just fine and being used without WSDLs. I used to work on a system that supported WSDL-based services and plain XML-RPC. The WSDL really didn't add much value and actually was less successful because of vendor interoperability problems. I would turn you argument around and ask how can you argue that WSDXL is absolutely needed given that many services don't use it or any comparable protocol?
    I do enterprise services and I know that I need solutions for the problems WSDL, Schema and SOAP solve.
    Specifically, what problems does SOAP solve?
    Using REST instead of SOAP is fine, but you then need to define your own protocol for supporting the capabilities you require.
    I don't understand this. What do you mean specifically? HTTP supports a set of capabilities equivalent to CRUD which have been proven to be all you need long ago.
    If you don’t require much and if HTTP is good enough, then you’re in good shape. If not, you have a challenge.
    Can you give an example of something that you can't do with REST?
    Someone pointed out all the things you can include in you HTTP stream to handle many of the things SOAP-based WS-* address. What they didn’t point out is that the details and specific about how you should use these capabilities and interpret others’ streams has to be defined, i.e. an application protocol.
    How is it different in WSDL based services?
    As it stands HTTP defines what you can do more than what you must do. It’s the difference between can and must that leads to interoperability problems.
    I've used two tools from the same vendor that could not understand each other's WSDLs well enough to communicate. HTTP on the other hand is an extremely well-supported protocol. The only issue is that DELETE is not well supported but anyone who needs to support DELETE can make sure that they do.
  22. Re: The best WSDL is no WSDL at all[ Go to top ]

    I don't understand this. What do you mean specifically? HTTP supports a set of capabilities equivalent to CRUD which have been proven to be all you need long ago.
    If you really can't think of any other operation than CRUDs, I don't see how you guys can ever understand each other.
  23. Re: The best WSDL is no WSDL at all[ Go to top ]

    I don't understand this. What do you mean specifically? HTTP supports a set of capabilities equivalent to CRUD which have been proven to be all you need long ago.


    If you really can't think of any other operation than CRUDs, I don't see how you guys can ever understand each other.
    There is more to REST than CRUD. Sure, REST is a good fit for a web service backed by a relational database, but that's beside the point. In REST, clients and services communicate by exchanging representations (XML, JSON, binary, etc.) and by manipulating resources (maps, bank accounts, file systems, etc.) through a standard set of service methods. Say for instance you have a collection of FooBar resources that you want to share with clients. You publish a URI for the resource collection at http://somehost/FooBar and distribute this URI in an RSS feed and in online documentation. A client can GET an existing FooBar resource from http://somehost/FooBar/123, manipulate its state and POST it back to the web service. What your web service does when a modified FooBar is posted is completely up to you. Depending on the changes made by the client, the service may update a database, send a JMS message, or perform some other work. The point is that simply because resource state is transferred using a small set of verbs does not mean REST is limited. The possibilities within this set of operations are enormous. This enables a shift in focus from service methods (API) to resources (objects/data). I would rephrase your comment — can you think of how an existing SOAP-based web service API could be re-written using only GET, PUT, POST, and DELETE? Which resources would you expose? Which representations would you support? How would you design your URIs? For a real-world example of a successful web service based on REST, take a look at Amazon.com's S3 service.
  24. Re: The best WSDL is no WSDL at all[ Go to top ]

    I don't understand this. What do you mean specifically? HTTP supports a set of capabilities equivalent to CRUD which have been proven to be all you need long ago.


    If you really can't think of any other operation than CRUDs, I don't see how you guys can ever understand each other.
    If you don't understand that these are the fundamental operations and all other operations can be derived from these I suggest educating yourself on the subject before making silly comments like the above.
  25. I don't understand this. What do you mean specifically? HTTP supports a set of capabilities equivalent to CRUD which have been proven to be all you need long ago.


    If you really can't think of any other operation than CRUDs, I don't see how you guys can ever understand each other.


    If you don't understand that these are the fundamental operations and all other operations can be derived from these I suggest educating yourself on the subject before making silly comments like the above.
    James, all computing can be done on a Turing machine. All programming can be done in Assembler. Neither is a good argument for not wanting more.
  26. I don't understand this. What do you mean specifically? HTTP supports a set of capabilities equivalent to CRUD which have been proven to be all you need long ago.


    If you really can't think of any other operation than CRUDs, I don't see how you guys can ever understand each other.


    If you don't understand that these are the fundamental operations and all other operations can be derived from these I suggest educating yourself on the subject before making silly comments like the above.


    James, all computing can be done on a Turing machine. All programming can be done in Assembler. Neither is a good argument for not wanting more.
    At least someone got my point without the need of a big elaboration paragraph. Thanks Will.
  27. Re: The best WSDL is no WSDL at all[ Go to top ]

    I don't understand this. What do you mean specifically? HTTP supports a set of capabilities equivalent to CRUD which have been proven to be all you need long ago.


    If you really can't think of any other operation than CRUDs, I don't see how you guys can ever understand each other.


    If you don't understand that these are the fundamental operations and all other operations can be derived from these I suggest educating yourself on the subject before making silly comments like the above.


    James, all computing can be done on a Turing machine. All programming can be done in Assembler. Neither is a good argument for not wanting more.


    At least someone got my point without the need of a big elaboration paragraph. Thanks Will.
    Sometimes less is more.
  28. Guys, it is very simple, there are two APIs styles: RESTfull Object get(String); Status put(Object); Status delete(String); Status post( Object); Statically typed (CORBA, SOAP, RMI, various RPC so to speak): Person[] searchPeople(PersonCriteria ); store(Person); updatePerson(String id, String lastName, String firstName); and so on. The two camps just do not understand each other and there is not way to resolve the differences some like the blind restful style for the flexibility and uniformity and others like explicitness of the statically typed interface. The differences are not reconcilable, just pick your poison and move on
  29. Guys, it is very simple, there are two APIs styles:
    SOAP document/literal is not RPC. It is not necessarily statically typed either. It defines a message structure associated with a service operation. That structure definition can be as simple as a single enclosing element. There are no procedures or functions or methods that have to be named in the message. There are no function, method or procedure arguments. You send a message to the end point (URL) and, perhaps, get a message in return. Anyone still using SOAP RPC-encoded is years out of date.
  30. Guys, it is very simple, there are two APIs styles:

    SOAP document/literal is not RPC. It is not necessarily statically typed either. It defines a message structure associated with a service operation. ....
    It does not matter if the definitions are RPC or Doc style ones. As long as input message and output message/document structures are (pre)defined and explicit we are dealing with [statically] typed invocations. That is opposed to untyped REST style invocations which could be and often are statically typed, it is just communicated in obscure and unstandardized ways which give appearance of 'freedom'.
  31. Guys, it is very simple, there are two APIs styles:

    SOAP document/literal is not RPC. It is not necessarily statically typed either. It defines a message structure associated with a service operation. ....


    It does not matter if the definitions are RPC or Doc style ones. As long as input message and output message/document structures are (pre)defined and explicit we are dealing with [statically] typed invocations.

    That is opposed to untyped REST style invocations which could be and often are statically typed, it is just communicated in obscure and unstandardized ways which give appearance of 'freedom'.
    I also use William's arguments, if people are not in my camp. Works!
  32. Guys, it is very simple, there are two APIs styles:

    SOAP document/literal is not RPC. It is not necessarily statically typed either. It defines a message structure associated with a service operation. ....


    It does not matter if the definitions are RPC or Doc style ones. As long as input message and output message/document structures are (pre)defined and explicit we are dealing with [statically] typed invocations.

    That is opposed to untyped REST style invocations which could be and often are statically typed, it is just communicated in obscure and unstandardized ways which give appearance of 'freedom'.
    It does matter. With document/literal and the right/wrong schema, you can either be explicit or obscure. That depends on the schema. An example of obscure would be a single element of type String or worse, one containing CDATA or PCDATA. In any case, I like my messages to be explicitly typed, but that does not make it RPC. RPC as a style exposes operations that are based on the design of what you're invoking and not on the use case, i.e. the Actor's perspective. You can (and we often do) use RPC technology to implement a service style and, unfortunately, vice versa. I can also explicitly type RESTful services. All I have to do is send an XML document that references the schema that defines its structure.
  33. ...I can also explicitly type RESTful services. All I have to do is send an XML document that references the schema that defines its structure.
    We apparently have different definitions of "typed" interface. Specifying types on the returned XML does not make interface typed. In my play book interface like this Object get(Object) is untyped despite the fact that every returned object has very particular type, and that my parameter object has type too. The difference is between a priori and posteriori knowledge http://en.wikipedia.org/wiki/A_priori_and_a_posteriori_(philosophy) and guarantees.
  34. Let me try and understand what you are saying. When you write “Object getObject(Object)” is Object the top of the class hierarchy as in Java? If so then are you saying it is untyped because you can either adapt to any type (e.g. polymorphism) or you don’t care about the type because you don’t actually do anything with the Object’s contents? In document/literal or similar styles (REST with plain XML) I can do the same things. I can either declare (in the WSDL) separate operations based solely on differences in the message structure or I can use polymorphism and have one operation that can process all manner of variations in the message structure and content. All that WSDL requires is that the outer element is – within the context of the WSDL – is uniquely associated with an operation of the end point (URL). I can have an endpoint with one operation and a generic element which is the equivalent of “Object”. I can have multiple operations at the end point all of which accept “objects”. All that is required is different wrapper elements so I will know which of my operations you want invoked.
  35. I use “Object getObject(Object)” analogy because this type of interface tells nothing about its abilities: it does not tell if it can adopt and take any type or only certain subtypes, it doe not tell what it could return back, it does not guarantee that the returned object will be the same all the time and that it will be compatible with previously returned types. If WSDLs declares that it takes string and returns string then IMO it uses same style as REST and has the same pluses and minuses. In this case there is no need for WSDL indeed.
  36. In this case there is no need for WSDL indeed.
    WSDL does one other thing though. It describes the various transports and protocols that you can use to communicate with the service end points and provides their addresses. In other words, it provides entries into a directory. A URL does not do that. You still have to indicate your protocol, e.g. "<a href="http://" "="" rel="nofollow">http://" or "ftp://", etc. and not all protocols or transports can be used such as a MOM product (JMS). Service Registries contain WSDLs and Schemas and use them to provide the service lookup function. Its clearly more powerful than something like JNDI in that respect.
  37. Guys, it is very simple, there are two APIs styles:
    RESTfull

    Object get(String);
    Status put(Object);
    Status delete(String);
    Status post( Object);


    Statically typed (CORBA, SOAP, RMI, various RPC so to speak):

    Person[] searchPeople(PersonCriteria );
    store(Person);
    updatePerson(String id, String lastName, String firstName);
    and so on.


    The two camps just do not understand each other and there is not way to resolve the differences some like the blind restful style for the flexibility and uniformity and others like explicitness of the statically typed interface.

    The differences are not reconcilable, just pick your poison and move on
    Best post on this thread.
  38. Re: The best WSDL is no WSDL at all[ Go to top ]

    I don't understand this. What do you mean specifically? HTTP supports a set of capabilities equivalent to CRUD which have been proven to be all you need long ago.


    If you really can't think of any other operation than CRUDs, I don't see how you guys can ever understand each other.


    If you don't understand that these are the fundamental operations and all other operations can be derived from these I suggest educating yourself on the subject before making silly comments like the above.
    One might think that this was a silly comment, and I tend to agree since I didn't bother giving more details. The fact is, I thought it was simply useless to elaborate more because this was a bit out of topic. But hey ! Since you are not that grown up and you want to call me silly, I guess I'll have to elaborate. I agree on your assumption that all basic operations can be translated on their CRUD equivalent. Who wouldn't ?! But these are *basic* operations. I could think of a gazillion scenarios where you'll end up making arbitrary mappings between more complex operations and REST standard operations, leaving all your web services clients with a huge dictionnary of correspondances between what your service does and what is the arbitrary related REST operation. This takes the REST pattern right out of it's primary aim; beeing simple. Now, does that still sound silly ? Do you still beleive that ALL operations can be logically mapped to a REST call ? I've seen many disastrous systems where they aimed at simplicity, but failed in the end because they simply saw the tool as the objective to attain. They blindly followed some new hype pattern and didn't take into account the systems specs. Being RESTful is not an objective no matter how you turn it over and over. Nor is making a god out of REST. Mencius once said : If the Gods don't fulfill all beneath Heaven's needs, replace them.
  39. I agree on your assumption that all basic operations can be translated on their CRUD equivalent. Who wouldn't ?! But these are *basic* operations. I could think of a gazillion scenarios where you'll end up making arbitrary mappings between more complex operations and REST standard operations, leaving all your web services clients with a huge dictionnary of correspondances between what your service does and what is the arbitrary related REST operation.

    This takes the REST pattern right out of it's primary aim; beeing simple.

    Now, does that still sound silly ? Do you still beleive that ALL operations can be logically mapped to a REST call ?
    Yes, I do. SOAP maps a gazillion operations to a single HTTP operation: POST. If your argument makes sense then SOAP is even worse than REST. In fact that's why I believe REST to be superior. It separates these fundamental operations out in order that the need not be redefined in another place. Why should I have to specify update, add, delete and insert operations for my service? Just because I only have 4 basic operations doesn't mean that I can't do different things based on the content of a PUT or POST just like I would in SOAP. Right off the bat, REST adoption comes with value. Because REST defines queries are GETs and don't take input documents, it's very easy to build web pages that use these services. All you need is a stylesheet and you can include the content of the webservice query in a page. Compare this to the what is required to do the same thing with a standard SOAP/HTTP/WSDL serivce. There's no standard query interface for this kind of thing. There's really no reason that I see that standards providing what's useful and missing from REST can't be built on top of REST other than some misguided (IMO) opposition by the REST 'community'. I think this is much preferable to the alphabet soup mess we have with WS*.

  40. A lot of services are running just fine and being used without WSDLs. I used to work on a system that supported WSDL-based services and plain XML-RPC.
    And I would argue that XML-RPC and SOAP RPC-encoded are not service style technologies at all. (Yes you can still use them to write services.) They are remote procedure call styles which is very different. One problem with these styles is they embed their own mini-schemas in the messages. This greatly complicates integration and reuse strategies because you’ve essentially hardwired your data model and you have to support multiple copies of its fragments that exist with every remote procedure or operation you create. A separate schema can be centrally managed, reused and repurposed to define data used across the board – in services, logs, data stores, etc. - not just in one remote procedure. ( I don’t embed schemas in WSDL either.) All this complication – maintaining data model fragement copies - is one reason I see rpc programmers staying with strings. That means the either side have to hard-code any validation or databinding they want to do. Also, XML-RPC and SOAP RPC-encoded define the messages you are sending, but they do not define how you locate and access the service or procedure. WSDL is filling the role of a directory you can browse and interrogate about the available endpoints, supported operations and required message structures. Again, if all you need is HTTP than an URL maybe all you need. I need more.
    The WSDL really didn't add much value and actually was less successful because of vendor interoperability problems.
    I didn’t say WSDL, SOAP or Schemas were good solutions. I just said that the problems they were trying to address are legitimate. Vendor and technology interoperability problems do exist at all levels. One set is caused by programmers who do not work contract first. They generate WSDL’s from code they’ve already written. Besides tending to lead to a poor service interface, the generators tend to introduce programming language dependent names and conventions that create interoperability problems. A few years ago the issue of interoperability between Java and .NET implemented web services and clients was a big issue because of this. There are other interoperability problems such as the ones that WS-I is trying to address with their profiles. All of these standards tend to tell you what you can do, but they are not clear and complete enough on what you must do. That is why WS-I ‘s profile goes so far as to say how you need to encode your HTTP stream.
    I would turn you argument around and ask how can you argue that WSDXL is absolutely needed given that many services don't use it or any comparable protocol?
    I didn’t say WSDL is absolutely needed or that the problem it is trying to solve always exists. Please reread my post. I said that WSDL attempts to solve a very real problem. I also said it wasn’t a great solution for the problem it is trying to solve. My problem with WSDL is primarily its complexity which better tooling might be able to mitigate.
    I do enterprise services and I know that I need solutions for the problems WSDL, Schema and SOAP solve.


    Specifically, what problems does SOAP solve? SOAP, in theory, lets me declare my message handling and delivery requirements (via the WS-* standards) independent of the various transports that might be carrying my message. We have multiple and redundant delivery and access channels and sometimes messages cross transports. We don’t want to code to one. SOAP, et al is also supported by the supporting service on the ESB that implement governance, logging, policy enforcement, SLAs. Etc. If I role my own format I’m on my own. To be clear, these standards, especially the WS-*s are not complete enough, mature enough or even stable enough to work out of the box in a multi-vendor environment. The choice we face today is that I can either limit my technology options or I can limit my vendors because there is still now robust, complete and stable set of standards well-supported by everyone. Nevertheless, my point is that the problems being addressed are important and legitimate even if the available solutions are lacking.
    What do you mean specifically? HTTP supports a set of capabilities equivalent to CRUD which have been proven to be all you need long ago.
    You surprise me here James because you normally are one of the first to realize that there are important requirements that simple, primitive technologies are not adequate to solve. You’re starting to sound like a Ruby guy. Oops, I apologize. HTTP is client/server. It does not support events, notifications, asynchronous messaging, guaranteed delivery, once and only once delivery, acknowledgement (not responses), etc. You can build solutions for these things on top of HTTP as the implementers of the WS-* standards are doing, but why? SOAP + WS-* is already targeted toward those how want to use HTTP everywhere. So "why" boils down to your not liking the open standard or its implementation. The need for a solution still exists. (BTW, my druthers are to use JMS everywhere and forget about the underlying protocols, but that’s just me.)

    Can you give an example of something that you can't do with REST?
    Well first of all REST is a style not a protocol. Yes you can do a lot in REST, but if you are going to integrate with others you first have to set up some rules. How will you deal with security, with itineraries and routing? Handling and reporting faults? Guaranteed delivery? Once and only once delivery? Events? Acknowledgements (i.e. I received it intact and will start processing)? Notifications? Security? (don’t just assume SAML and SAML doesn’t do it all.) You could work out the details for all these things with each party you interact with or you can agree on a common standard someone else has already defined. It’s your choice, but large enterprises have been burned often trying to invent their own protocols so they tend to look to their vendors.
    I've used two tools from the same vendor that could not understand each other's WSDLs well enough to communicate. HTTP on the other hand is an extremely well-supported protocol. The only issue is that DELETE is not well supported but anyone who needs to support DELETE can make sure that they do.
    Like I said though, HTTP gives you many choices, but different people may choose differently. You cannot tell me that HTTP is so specific and so tight and so functionally complete that it is the solution for all things. Even with SOAP over HTTP where SOAP is supposed to do most of the heavy lifting, WS-I has had to provide standards for how to use HTTP to insure interoperability.
  41. I don’t embed schemas in WSDL either.
    Are you saying you don't use schemas with WSDL or you just don't embed them. If it's the former what are you doing? I want to understand.
    WSDL attempts to solve a very real problem. I also said it wasn’t a great solution for the problem it is trying to solve.
    I think this where we were not connecting. I agree with the above. My belief is that REST is a much better starting point. The problem with SOAP is that it (IMO) creates an unnecessary layer of complexity on top of XML. We don't need array types in XML, for example.
    Specifically, what problems does SOAP solve?

    SOAP, in theory, lets me declare my message handling and delivery requirements (via the WS-* standards) independent of the various transports that might be carrying my message.
    So it sounds like SOAP is not what provides the ability but the standards built upon SOAP (in theory, at least.) So is there anything about SOAP that makes these standards possible? Or more specifically, could these features be built upon standard XML?
    You surprise me here James because you normally are one of the first to realize that there are important requirements that simple, primitive technologies are not adequate to solve. You’re starting to sound like a Ruby guy. Oops, I apologize.

    HTTP is client/server. It does not support events, notifications, asynchronous messaging, guaranteed delivery, once and only once delivery, acknowledgement (not responses), etc. You can build solutions for these things on top of HTTP as the implementers of the WS-* standards are doing, but why?
    I would say because the WS* standards are so deficient and costly to support. I think we should be able to have only the complexity necessary and not make things more difficult than they need to be. I'm going go out of town so don't think me rude if don't reply to further points.
  42. Are you saying you don't use schemas with WSDL or you just don't embed them. If it's the former what are you doing? I want to understand.
    I use a document/literal style and I import the schema I use into the WSDL. The schema is in a library of schemas that define our common data types and structures in a standard way that can be used where ever we use XML (or something that binds to it) for data.
    The problem with SOAP is that it (IMO) creates an unnecessary layer of complexity on top of XML. We don't need array types in XML, for example.

    Array types and such are from the older RPC-encoded style. Document/literal does not use them. It’s just plain XML inserted into the SOAP body. WS-I and the industry in general have seen the error of their ways and have moved away from the RPC styles. RPC-encoded is explicitly not supported by WS-I.
    So it sounds like SOAP is not what provides the ability but the standards built upon SOAP (in theory, at least.) So is there anything about SOAP that makes these standards possible? Or more specifically, could these features be built upon standard XML?

    SOAP is very simple itself - at least it is if you use document/literal where your message body is plain XML. It consists of an envelope tag, an optional header tag and a body tag into which goes your message. There is a fault tag and not that much else. It is very simple. Its true purpose, as you surmised is found in the (optional) header where elements of all these other standards (WS-*) can be put and processed by Namespace handlers. (Every standard has its own Namespace.) The creation of header elements and their processing is supposed to be done by your infrastructure, not the application developer – unless he really wants/needs to. However, there has been a lag in tooling and product support due in part to the volatility and immaturity of the standards and their newness. Things need to settle down and the tools need to catch up. In reality your own code should only have to supply the plain XML to be inserted into the SOAP body and if you use data bound objects such as JAXB you’d only have to return the correct object graph which would be serialized as the XML body for you. There really is no good reason to even make application developers create the SOAP envelope or read or write the header. Things are much better now with Axis2, CXF or Spring’s new web services stuff, but it could all be made even more transparent than it is. (I wouldn’t use SOAP to the client just between services. REST with plain XML seems good enough for me.)


    I would say because the WS* standards are so deficient and costly to support. I think we should be able to have only the complexity necessary and not make things more difficult than they need to be.
    I agree with your assessment of the current state, but things have improved a lot and will even more so in the future. Interesting SCA – if it pans out – removes the entire XML, EJB and transport thing from the application space entirely. It’s still there but handled in the tooling and middleware where it belongs. One thing that has contributed to all this mess is the competition amongst the vendors, their rivalries and alliances. We have a number conflicting, overlapping and incompatible WS-* standards. Why both WS-ReliableMessaging and WS-Reliability? Why WS-Events and WS-Eventing? If SOAP + WS-* fails then it will be because the vendors focused on one-upping the others instead of finalizing these standards and supporting them in their products and tools. We shouldn’t have to be coding this stuff ourselves.
  43. I use a document/literal style and I import the schema I use into the WSDL. The schema is in a library of schemas that define our common data types and structures in a standard way that can be used where ever we use XML (or something that binds to it) for data.
    This is the kind of WSDL-based webservice I have normally worked with. And this is my point, what SOAP provides (in terms of contemporary best-practices) is trivial. What we have is this giant standard to support what, four XML element declarations? My personal experience was that protocols like RosettaNet (even with all it's flaws) were better than WSDL based services.
    SOAP is very simple itself - at least it is if you use document/literal where your message body is plain XML. It consists of an envelope tag, an optional header tag and a body tag into which goes your message. There is a fault tag and not that much else. It is very simple. Its true purpose, as you surmised is found in the (optional) header where elements of all these other standards.
    And this is what I am getting at. What's left of SOAP doesn't warrant a standard. I agree that if you just use these few parts of SOAP, it's not that bad but I still see the other parts used. I just had to integrate with such a WSDL generated by Siebel a few months ago. As far as the WS* standards go, I can see the value of standardization on these kinds of concerns for implementing an infrastructure but I don't think these concerns are something that belong in the service layer. They make requirements about implementation and would make more sense at a process management level. This is especially true for inter-organizational services. Service clients must depend on the contract the service provides and abide by it's rules and guarantees. As soon as you start allow clients to specify how you will handle their request, you lose control over your implementation at at least some level. I think we both agree that there is a need for a standardized way to describe your service in a machine understandable way. I also think, however, this need is often exaggerated. The current webservice 'standards' were basically all developed to solve the wrong problem and then retrofitted to meet what people really needed. I think that this is one of those times where it's best to cut our losses and start fresh. I'm actually more fond of WSDL 2.0 but it has such limited support (AFAICT) that it's unusable. It actually can support REST service definitions. I know that most of the REST community doesn't believe it needs WSDL and I'm not convinced WSDL is the best solution but I think we need something other than just text descriptions in the long term.
  44. This is the lesson we've learned as we've abandoned SOAP altogether...
    Fair enough! Do you do remote service invocation? How? Is it a public API of any sort? By that, I mean "do other organizations use it" as a black box?"

    If you do publish APIs, what's their nature? How do you validate inputs and outputs? Do your clients do any discovery on the services, so they can determine without your interaction what the service can do?
    Are you implying that WSDL can relate what a service can do? All it tells you is where something, how to call it, what input it accepts, and what it returns. A machine can only use this information to create some basic code for talking to the service, none of which is really all that time consuming or difficult once you get away from WS*. The machine cannot apply meaning to the message elements.
  45. Re: The best WSDL is no WSDL at all[ Go to top ]

    An api without documentation is no better than a wsdl without documentation.
  46. Art of Designing a WSDL[ Go to top ]

    A while I was looking for a best practices for Designing/Defining WSDL's. Here are my findings: http://javaswamy.blogspot.com/2007/08/art-of-designing-wsdl_16.html
  47. Re: Looking for a few good WSDLs[ Go to top ]

    I find it strange that the Wikipedia entry for WSDL includes an example of describing a RESTful web service using WSDL. This seems unnecessary, since RESTful web services are already described by the uniform interface. Since WSDL is traditionally tied to SOAP (and therefore RPC-style) web services, and since popular SOAP-based web services have been deprecated in recent years in favor of more simplistic approaches, is this an attempt by the Wikipedia author(s) to present WSDL in a more flattering way? Maybe the Wikipedia article is suggesting that the REST community could adopt WSDL as the description language for RESTful web services, or perhaps as a way for SOAP-based clients to access a RESTful web service. Richardson and Ruby recommend WADL over WSDL in O'Reilly's RESTful Web Services and mention it can be used to abstract the HTTP protocol away for REST clients. Of course, if you want to use HTTP on the other hand (what a concept, only one envelope!), your client can use OPTIONS to find out which methods the web service supports (assuming it supports OPTIONS in the first place, which I'm told is not very common).
  48. Re: Looking for a few good WSDLs[ Go to top ]

    Since WSDL is traditionally tied to SOAP (and therefore RPC-style) web services
    I think your view of SOAP is a bit dated. The preferred style for SOAP has been document/literal for some time now. Read the WS-I profiles (WS-I.org) Starting with version 1.0 they explicitly did not the support RPC-encoded style. A lot of of the complaints I read about SOAP and it's "complexity" are from people who've only use RPC-encoded and the early SOAP tools. SOAP document/literal is almost trivially simple. The complexity is what is in the headers, but those are the WS-* standards, not SOAP.
  49. Should the question really be "Looking for a few good XML Schemas"? WSDL types are the building blocks of a WSDL. At least the static part of it. They define the inputs and the outputs of the operations for a WSDL service and in a best-practice document centric approach, which is what the article calls for it's really the in/out messages that matter and not the operations. It's also a recognized good practice to import WSDL types from external, independent schema. This is why there are industry standard schemas out there (as opposed to industry standard WSDLs).