|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 18
Messages: 18
Messages: 18
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Pragmatic XML Services: TheServerSide Video Tech Brief
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
|
|
|
Message #236606
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Object == Message // !?
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?
|
|
|
Message #236613
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object == Message // !?
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/
|
|
|
Message #236615
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object == Message // !?
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
|
|
|
Message #236625
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object == Message // !?
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/
|
|
|
Message #236628
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object == Message // !?
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.
|
|
|
Message #236636
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Object != Document && Document == Tag Soup // !
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".
|
|
|
Message #236637
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Everything is just an Object
I actually think this is not a new proposal. It is just the way it should be from the definition, is nothing new. +1
|
|
|
Message #236642
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object != Document && Document == Tag Soup // !
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 > 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
|
|
|
Message #236643
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object == Message // !?
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
|
|
|
Message #236662
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object != Document && Document == Tag Soup // !
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
|
|
|
Message #236666
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
guildo.rex@gmail.com
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.)
|
|
|
Message #236668
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object != Document && Document == Tag Soup // !
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. :-)
|
|
|
Message #236672
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What is a message?
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?
|
|
|
Message #236701
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object != Document && Document == Tag Soup // !
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
|
|
|
Message #236715
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object != Document && Document == Tag Soup // !
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)?
|
|
|
Message #236724
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object != Document && Document == Tag Soup // !
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
|
|
|
Message #236739
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Object != Document && Document == Tag Soup // !
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
