Discussions

XML & Web services: Why Web-Services Aren't All That

  1. Why Web-Services Aren't All That (3 messages)

    Having developed web-services on multiple versions of BEA WebLogic and JBoss and converted web-services from Oracle AS to JBoss for several years now, I have come to a startling conclusion. The web-services development process and standards are not necessary. That’s right. After 15 years of professional software development in multiple languages (including Java) on multiple platforms, including working as a consultant for several years, I have come to the conclusion that web-services are not only unnecessary but inhibit the development process. I would like to make an initial proposal here to the community at-large that will no doubt infuriate the major software vendors, who stand to gain the most from the current environment that I and many others have found to be unnecessarily complex and problematic. For developers I believe that you may find this to be a breath of fresh air that can simplify what is currently a quagmire of steps and complexities for making objects talk to other objects across the network. I won’t go into the details in this initial posting about why I think web-services are what they are today. That I will hold off on to see how much traction this post gets. However, I will say that web-services have several core problems. Namely: 1) Web-services require vendor tools to generate efficient skeletons/stubs (e.g., from code for the service side or from a WSDL for the client side). Many of these tools don’t work well when you get into complex data types, arrays of complex types, etc. This has spawned huge discussions around POJOs for web-services, etc. There have been multiple efforts to generate a truly dynamic web-services client (that can on-the-fly read a WSDL and generate the client stub) and I have tried every one published plus tweaked them to try to make them work myself. None of them work 100% for anything beyond very simple data types with no array parameters. I aim to put all of this debate and complexity to rest. 2) Web-services are inherently ambiguous. The nature of the specification is based on the “Simple Object Access Protocol” (SOAP). This means objects talking to objects through method calls. This is NOT analogous to an “enterprise service” in support of a “Service Oriented Architecture” because business services are not based on low-level method calls and parameter lists. They are based on business document exchanges (Purchase Orders, Invoices, Status Requests, etc). Instead, web-services (many published and many more developed internally at companies) are parameter-based including such clear signatures as “String, String, int”, etc. The WSDL doesn’t help because while one can put in comments to specify that the first parameter is indeed a customer name, this requires that someone actually took the time to document this and that a programmer then read the documentation on every parameter. Finally, it isn’t clear which parameters are required, how they relate to one another (if at all) and what the constraints are (e.g., enumerations, length restrictions, etc), if any. 3) Web-services are grossly inefficient. Consider the process: Once the pain of developing the skeletons and stubs subsides, the client code calls a stub class that converts language-specific objects/types into the SOAP (XML) types for each individual parameter. Then the SOAP envelope/header/body is built and transmitted via HTTP (only protocol actually specified in SOAP documentation) to the server. The server then un-marshals the XML parameters and casts each into the server-side language-specific object types. The business “service” code then has to do GET type methods (in Bean-type model) to get each of the parameters, execute the service, etc. Then the response is built in much the same way, un-marshaled in the same way on the client side, etc. So this brings us back to why web-services (or at least the concept if not the implementation) are a good thing. In a word: UBIQUITY. This is what makes the web work – everyone has a browser that supports HTML. So here I offer a better solution that retains the ubiquity but makes web-services development much faster, simpler and better: The problem in business-to-business or application-to-application exchanges isn’t so much the transport. Let’s assume as the SOAP specification does that HTTP is the defacto transport protocol. That being said, all that is left is the data and the process. For the data, instead of using parameters that were exposed by objects (which isn’t very business-friendly now is it?), what if we increase semantic interoperability by using XML documents (business documents) defined by W3C XML Schemas? Now we have a business semantic that is well-defined and can be concurrently worked by both the service consumer (client) and provider (server). That is, since both sides have agreed on the protocol and the model for the business document in the exchange, they can both get to work. No waiting for the server to generate the service, create a (useless) WSDL, client create the stub from the WSDL, etc. With the business document-centric model (and I am not saying web-services “document literal” versus “RPC-style” – one isn’t a dramatic improvement on the other) discussed above, the semantics of the data can be defined by the schema and all that remains is for the client to do an HTTP POST to the server, providing the XML. The server can then VALIDATE the XML against the schema (something not possible in the web-services model without a lot of pain) and process it (using XPATH or other very powerful, flexible and usable technologies). Likewise, the response (if it is indeed a request/reply pattern) would be an XML document that conforms to a schema and the client can likewise use XPATH or other technologies to consume it. No vendor-specific tools. No bugs relating to complex data types that different vendors cannot handle equally. No stubs, no skeletons, no limits on defining the data exactly the way the business functions. I have used the above model very successfully at a large multi-billion dollar company. I didn’t just come up with this simple idea when I hit my head during a fall off the banana truck. I think a lot of very smart people have done some good work with SOAP (at least the Envelope XML schema) but I think if you study this topic you will find that we can all achieve a higher level of interoperability faster and with less complexity by going to the business document model discussed versus using the web-service model currently being pushed by the major vendors. I look forward to your responses. Darrell Teague Enterprise Architect Darrell.Teague@cox.net
  2. Web services have a time and a place, like all technologies. If you are integrating disparate applications from various manufacturers, its the best way to go. Yes there is plenty of padding but the abstraction demands it. Your proposal is not new, I've seen a couple of systems that are live and doing this - one which started with SOAP and switched to XML over HTTP, the other which uses AXIS - so not quite SOAP. They both work very well but critically they are internal to their application. In summary, I believe both approaches have a valid place. SOAP is good for vendor-agnostic communications, XML over HTTP is better if the interface is never likely to exposed to a third party. In that case you could wrap your XML document exchange in a straightforward SOAP exchange. Phil Haigh Technical Architect, EDS
  3. Re: Why Web-Services Aren't All That[ Go to top ]

    The solution you describe sounds like a RESTful service. How is it different from REST?
  4. Re: Why Web-Services Aren't All That[ Go to top ]

    This is effectively a RESTful model - is completely asynchronous as in a message model, etc. My approach however specifies that the request/reply pairs (if indeed there is a reply) be based on W3C XML Schema standards so that the contract is clear. Google recently indicated that they are deprecating their SOAP API (a gold-standard for web-services) in lieu of an AJAX API (which is more like a RESTful model but, again, doesn't specify the request syntax through a schema - though the response is standardized). Yahoo follows a similar model. In both cases, the only transport protocol supported is HTTP - which differs somewhat in the model I have presented that separates the transport protocol completely from the data (based on schema).