Pragmatic XML Services: TheServerSide Video Tech Brief

Home

News: Pragmatic XML Services: TheServerSide Video Tech Brief

  1. Ted Neward is an authority in Java/.Net integration and co-author of several books on enterprise integration and server-side programming. Ted explains why the traditional way of building web services is essentially flawed, describing it as "very CORBAesque." Instead, he proposes a message-oriented rather than an object-based approach, one that will allow services to run over multiple transports like JMS, SMTP, or HTTP. No one transport will solve every problem, but developers and architects should think of all of them and not lock themselves into limited approaches. Leave the WSDL/XSD generation to the tools, including transport bindings. (Click here if you can't watch the video.) Ted is the principal consultant at Neward and Associates. He expresses his views about technology and other topics in his blog. Watch other Tech Briefs
  2. Object == Message // !?[ Go to top ]

    Instead, he proposes a message-oriented rather than an object-based approach, one that will allow services to run over multiple transports like JMS, SMTP, or HTTP.
    I don't get it. What's the difference between an object and a message?
  3. Re: Object == Message // !?[ Go to top ]

    In the object approach your return 'object' is an object with properties as defined by the service's wsdl. This could be quite a complex nested structure. You could use a tool like Axis to create the stubs of such an object for you from the WSDL. The return object for the message approach would just be a string - most likely representing the details as an XML document. The advantage is you can change the message, e.g. the XML doc without changing the web service's signature, e.g. WSDL. The downside (if any) is that the web service is far looser typed and the WSDL does not contain the full contract. However nothing stops you from using XML schema inside the message for contract validation instead. Ingo http://goldentoolbox.blogspot.com/
  4. The return object for the message approach would just be a string - most likely representing the details as an XML document.
    No, that's document style. (Don't mix it up with documnt RPC/encoded, RPC/literal, Document/encoded and Document/literal binding)
    The advantage is you can change the message, e.g. the XML doc without changing the web service's signature, e.g. WSDL. The downside (if any) is that the web service is far looser typed and the WSDL does not contain the full contract. However nothing stops you from using XML schema inside the message for contract validation instead.
    My laziness stops me from schema validation. For Axis2 use XMLBeans data binding, to have a "looser typed contract".
  5. Interesting. Using a string as a return object to contain XML has several drawbacks (imagine a large XML, with all the encoding/decoding of and such characters). But it is one of the simplest object implementation for undetermined parameter composition. A string can hold whatever you want. And in some tests it performed faster that passing SOAPElement objecto or even an DOM Element. A true Document/Style will have a schema in the types for WSDL and a port to deliver. No method to call, it should be inferred from the port URL and the schema sent. The implementing framework will map that to a method in an implementation class, and pass a suitable object type for XML processing, like JAXB, XMLBeans, DOM Element or even a stream. But that method and the type used is not in the WSDL, it is totally agnostic of it. William Martinez Pomares
  6. A true Document/Style will have a schema in the types for WSDL and a port to deliver. No method to call, it should be inferred from the port URL and the schema sent. The implementing framework will map that to a method in an implementation class, and pass a suitable object type for XML processing, like JAXB, XMLBeans, DOM Element or even a stream. But that method and the type used is not in the WSDL, it is totally agnostic of it.
    Well, not in my world. I call that "Document Interaction". See http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns/index.html. In my world document style means to use String or Any types for a RPC (your and my world) web service. See http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns/index4.html The reason to use document style (my world) was to be "less coupled" to changes in params and return types. But if you consider this guidlines and use XMLBeans data binding everything works fine. BTW: JMS transport support of Apache CXF seems to be great. Disclaimer: Sorry for confusing web service veterans. ;-) Sorry for posting jaxrpc stuff. :-)
  7. Well, not in my world. I call that "Document Interaction".
    In my world document style means to use String or Any types for a RPC (your and my world) web service.
    Ok, I agree and I disagree. I would call "Document Interaction" to your approach to use RPC with one anytype parameter. You are simulating document style using RPC. One clear difference is RPC is inherently a request-response thing (even when void is returned). A Document style is a simple post, and to obtain a response you need another document posted back. I read the JaxRPC patterns long ago when doing a comparison project. It was clear at that time in the white paper published by BEA based on that comparison that jaxrpc had no true document/style. Neither does .NET (it uses the "wrapped" trick to simulate an RPC SOAP call using Document/Style WSDL). Those patterns also mention the use of JAXB, just as Axis 2 is now using XMLBeans. So it is the same pattern done again. Now, I'm talking about Document/Style version of Web Services. Could it be a new Document/Style concept is emerging from usability? William Martinez Pomares
  8. It's a pleasure to discuss with you. :-)
    Well, not in my world. I call that "Document Interaction". In my world document style means to use String or Any types for a RPC (your and my world) web service.
    Ok, I agree and I disagree. I would call "Document Interaction" to your approach to use RPC with one anytype parameter.
    Ok, lets call it "Pretend RPC style", "Document via RPC stlye" and "Plain Old Document Style". That reduces the confusion.
    You are simulating document style using RPC. One clear difference is RPC is inherently a request-response thing (even when void is returned). A Document style is a simple post, and to obtain a response you need another document posted back.
    Also a post via HTTP is a request/response thing. I see no difference (especially if void is returned, as you mentioned). If I got it right, Apache CXF makes it possible to have asynchronous transport (JMS) for any service, no matter what kind of RPC or Document style.
    Those patterns also mention the use of JAXB, just as Axis 2 is now using XMLBeans. So it is the same pattern done again.
    XMLBeans is lenient to compatible changes, JAXB is not.
    Could it be a new Document/Style concept is emerging from usability?
    What does that mean (I still love my Pretend RPC style)?
  9. It's a pleasure to discuss with you. :-)
    Same!
    Ok, lets call it "Pretend RPC style", "Document via RPC stlye" and "Plain Old Document Style"
    Ok, just to be sure: - "Pretend RPC style" is .NET using document style to call RPC - "Document via RPC stlye" is Rex using rpc style to do document work - "Plain Old Document Style" is William talking about old document style concept. Did I get it right?
    Also a post via HTTP is a request/response thing
    Totally agree. HTTP is a commodity to overcome firewalls. But since it is a request/response in nature, it causes an impedance mismatch effect. Actually, JMS is more natural to work with messages. For HTTP, the response is used in RPC to obtain the actual response. In Document, the HTTP response is just to signal the message was delivered! HTTP is just a transport, not a message system. Interesting, huh?.
    XMLBeans is lenient to compatible changes, JAXB is not
    I agree. JAXB used as an XML to Java Class binding was presented in the patterns. XMLBeans will represent the same idea, but for some reason it was selected over JAXB by Axis, don't you think?
    What does that mean (I still love my Pretend RPC style)?
    I mean: I new one concept of document style, the one where a service is called with messages that contained XML documents (Web Services original). Frankly, I've seen so few of those implementations, and so many of plain old RPC calls using web services, that I may think people is accepting more your vision of document style using RPC, so it is a de facto standard due to extended use! Does it make sense? William Martinez Pomares
  10. Ok, just to be sure: - "Pretend RPC style" is .NET using document style to call RPC
    Actually I don't know how the .NET guys do their RPC calls (at least I hope they have even less fun with it ;). What I mean is just RPC, I don't care what happens under the hood. I call it "Pretend" because I can even use it to send asynchronous, one way calls (in my world function has a return value, procedure not). I hope this is what Ted Neward meant, when he talked about messages. And I hope this is what Apache CXF supports.
    - "Document via RPC stlye" is Rex using rpc style to do document work
    Please replace "Rex" with "The Others, Them, The Natives, The Hostiles".
    - "Plain Old Document Style" is William talking about old document style concept.
    Ok. Until now I use "Plain HTTP RPC" web services in my projects.
    But since it is a request/response in nature, it causes an impedance mismatch effect.
    I hope it's not infectious. ;-)
    For HTTP, the response is used in RPC to obtain the actual response. In Document, the HTTP response is just to signal the message was delivered! HTTP is just a transport, not a message system. Interesting, huh?.
    For both the effect in time and space is the same. I belive that any public HTTP transaction is stored by the NSA. So, also HTTP is a message system. ;-)
    I agree. JAXB used as an XML to Java Class binding was presented in the patterns. XMLBeans will represent the same idea, but for some reason it was selected over JAXB by Axis, don't you think?
    XMLBeans is not the default data binding in Axis2. It's my humble recommendation.
    I mean: I new one concept of document style, the one where a service is called with messages that contained XML documents (Web Services original). Frankly, I've seen so few of those implementations, and so many of plain old RPC calls using web services, that I may think people is accepting more your vision of document style using RPC, so it is a de facto standard due to extended use!
    No, no, it's badly enough we gave it name here. I'm a RPC warrior.
  11. No, that's document style.
    (Don't mix it up with documnt RPC/encoded, RPC/literal, Document/encoded and Document/literal binding)
    Document style is closer to what Ted proposed in his talk. It's still defined by XML schema within the soap contract. Ted's proposal was not to do this at all. All validation, if any, is due to the message consuming code.
    My laziness stops me from schema validation. For Axis2 use XMLBeans data binding, to have a "looser typed contract".
    Fine - as I said, you can. If you need/wish to validate - schema is there!
    Sorry, Ingo, but I don't see "wrong" word in my post.
    If one approach is called correct it implies that not using the correct approach is incorrect. Semantics ... Even changed to elegant, my point stays the same - let's not value approaches per se but only in context to a particular use-case. There are no right tools - there are only right tools for a specific job! Ingo
  12. guildo.rex@gmail.com[ Go to top ]

    If one approach is called correct it implies that not using the correct approach is incorrect. Semantics ...
    +1
    Even changed to elegant, my point stays the same - let's not value approaches per se but only in context to a particular use-case. There are no right tools - there are only right tools for a specific job!
    No, document style is always wrong! ;-) (It was good with Axis1, but not with Axis2/XMLBeans data binding. Don't know much about Apache CXF, but they also have XMLBeans data binding.)
  13. damn[ Go to top ]

    damn! damn! damn!
  14. What is a message?[ Go to top ]

    Document style is closer to what Ted proposed in his talk.
    That's also my impression. If it's true, then he's wrong. So, what is a message finally?
  15. BTW...
    The advantage is you can change the message, e.g. the XML doc without changing the web service's signature, e.g. WSDL.
    A services's signature sounds funny. In the ideal world, WSDL is not signature but a service description. If it is document literal, there is a schema in types, and the service provider may change that schema any way it wants, and the port implementation and client implementation will not vary their signature. They are totally loose coupled. If the WSDL describes an RPC style, then changing the schema or parameter is actually changing the implementation signature. But in that case, the semantic of the service stays the same. So... Document Style allows loose coupling, and RPC tights it in. William Martinez Pomares
  16. Re: Object == Message // !?[ Go to top ]

    This goes far beyond the difference between those two things. It is actually related to how you see the service. Normal Case: A service is an object that exposes a method to the web. Correct Case: A service is a set of functionality that is exposed to the web through a port, using messages. In the first, the usual tools need to expose the method name, and a way to serialize the parameters into XML. This is the object way. You have a mix between the service definition and the implementation. The second case. You don't care how the service is implemented. It could be an object, or a procedure if you don't have classes, or even a trigger to a database. Who cares? What I need is a port where I can deliver a message, (it could be an XML document). You can deliver to the port using any transport you want: HTTP, mail, message queue... I actually think this is not a new proposal. It is just the way it should be from the definition, is nothing new. BTW, WSDL has the possibility to offer description of messages, it is built-in. It is extensible so you can add any transport (only the HTTP has been defined so far ,that is why http is used instead of the more natural message queue approach). William Martinez Pomares
  17. This goes far beyond the difference between those two things. It is actually related to how you see the service.
    Normal Case: A service is an object that exposes a method to the web.
    Correct Case: A service is a set of functionality that is exposed to the web through a port, using messages.
    Why do we always have to be so opinionated to call things correct vs. wrong? Correct to me spells the easiest way (and, if required, most extensible) to get the job done. Both methods have a valid place inside my repertoire. Your customer wants a clearly defined contract exposed in your WSDL, allowing him to create his stubs from the WSDL, great. The 'object exposing a method' works a treat. You don't and the message approach has a lot of advantages. Actually in the latter case you might review, whether a SOAP web-service is the right way forward or whether REST or similar might be more appropriate ... Ingo http://goldentoolbox.blogspot.com/
  18. Why do we always have to be so opinionated to call things correct vs. wrong?
    Sorry, Ingo, but I don't see "wrong" word in my post. Doing normal case is not doing wrong services. That is why I called normal and not wrong. It is perfectly fine, although you are not creating a service but something like a distributed object. That was the original SOAP all about, a Simple Object Access Protocol. Correct (or perhaps the word is "Elegant") way of constructing services is using messages. A Service is not an implementation, but a functional element. Now, if your client wants a clearly defined contract, don't use services. Too much complexity. You can use distributed objects. Web Services is a way to implement calls to those objects, although I would use them in very specific cases. Again, Web Services is one thing, and implementation using SOAP vrs using REST is another. Two different layers. William Martinez Pomares.
  19. Everything is just an Object[ Go to top ]

    I actually think this is not a new proposal. It is just the way it should be from the definition, is nothing new.
    +1