Discussions

News: JAX-WebServices under attack

  1. JAX-WebServices under attack (45 messages)

    Steve Loughran and Edmund Smith recently put a paper ("Rethinking the Java SOAP Stack") criticizing JAX-RPC (which was recently renamed to JAX-WS) for trying to hide XML and being to RPC-centric, instead suggesting an alternative API called Alpine which is document-centric and doesn't hide XML. Richard Monson-Haefel and Don Box blogged agreement with it, and the JAX-WS spec lead commented that XML document manipulation is possible with JAX-WS.

    The paper begins by setting the strategic choices:
    Communication with SOAP can be viewed either as XML-based remote procedure calls, or as a way of submitting XML documents to remote endpoints (optionally eliciting responses in the form of XML documents). These two perspectives represent the RPC-centric and message-centric viewpoints. In Java, the RPC-centric model has become the primary model for SOAP APIs.
    Making their case for why JAX-RPC is ill-designed, the authors main points were:

    1) The object / XML impedance mismatch. The JAX-RPC practice of mapping XML documents to Java objects as object to XML mappin (O/X) mapping and proceeded through a number of detailed examples of how mapping XML constructs to Java objects is not possible.

    2) SOAP is not just RPC. The authors show that synchronous and RPC-styled communications don't work well as content becomes larger and network latencies increase.

    3) SOAP is not RMI. JAX-RPC is criticized for attempting to provide an identical programming model to RMI:
    While Java RMI provides convenience, the one thing it does not provide in any way is loose coupling. Interacting systems typically run from the same codebase, and each element of the distributed system contains many implicit assumptions about the rest of the system. By trying to turn SOAP into RMI, we imitate this architecture, and risk losing the very things we turned to SOAP for in the first place.
    4) WSDL: an extra complication. The authors assert that WSDL is too complex, and that typical ways WSDL is used discourages contract-driven development.

    Moving onto summarize their implications:
    JAX-RPC only superficially benefits developers who do not want to work with XML: by hiding all the details, and giving developers a model of remote method calls via serialised Java graphs, JAX-RPC makes it harder to write true, interoperable SOAP services. Not only that, but it introduces the O/X mapping problem, while retaining an invocation model that is inappropriate for long-distance networks and slow communications.
    The authors then suggest building a new API called Alpine which is pretty much the opposite of JAX-RPC in that it is designed to make XML the first class citizen, and be document-centric instead of RPC. Alpine "will be a SOAP stack reduced to its essentials: a system for managing the flow of messages through a set of handlers, and libraries to handle transport across supported the protocols."

    The authors conclude:
    This may seem somewhat ruthless: to deny the right to write web services to developers who are and wish to remain ignorant of XML. However, we have to ask: if they do not want to know XML, why are they writing web services? If the developers want to use a less portable, more brittle, remote method invocation system, they would be better off using a stable technology such as Java RMI or CORBA.
    Richard Monson-Haefel blogged his reactions, claiming JAX-RPC is bad^3, but also saying that Alpine, which is kinda like combing SAAJ and JAX-RPC handlers into one packag e is also not good enough. Instead, RMH suggested an "XML centric language created for processing XML documents and web services", which could be built on top of the JVM and interoperate with Java, like Groovy.

    Microsoft Indigo Architect Don Box also commentedproblem isn't with the wire - it's with the endpoints. The technology we use to build those endpoints needs to adapt lest this whole XML thing grind to a halt. Alpine looks like a step in the right direction, but we still haven't hit service/messaging nirvana." Don also pointed out that there is a way in .NET work with the XML documents directly.

    Perhaps most importantly, JAX-RPC co-spec lead Marc Hadely responded and demonstrated:
    However the JAX-WS EG recognized that in some (or many, depending on your perspective) cases working at the XML layer is useful/desirable and so we added a couple of XML-centric APIs that completely bypass the XML<->Object layer of the stack: Dispatch and Provider.
    Document/XML centric or RPC/object centric, or something else entirely? What do you think?

    Threaded Messages (45)

  2. isn't it obvious[ Go to top ]

    SOAP webservices blow huge chunks. It fits simple cases and is horrible for complex cases. sorry, couldn't resist slamming soap webservices. I'm half way joking, since I've had to manually create a soap message from hand and get down to the raw XML in order to figure calls cross platform are failing. for those who think, "why in the world are you generating soap messages by hand?" it's because cross platform integration using webservices still sucks.

    peter
  3. SOAP debugging tools[ Go to top ]

    I've had to manually create a soap message from hand and get down to the raw XML in order to figure calls cross platform are failing.

    Yes, a good measure of how well WS-* has solved interop problems is the fact that there are multiple SOAP debugging tools, from the simple (axis tcpmon) to the advanced (mindreef's). Nobody doing DCOM needed a DCOM wire-level debugger. Nobody doing RMI needed a wire-level debugger. Nobody other than the stack vendors needed to debug Corba on the wire.

    But when you do SOAP, you need to look at the wire. And it aint as easy as pointing a web browser at a URL.
  4. Agree and disagree[ Go to top ]

    I don't work for BEA anymore so I have no axe to grind here. And I certainly agree that the WS stack feels way too heavyweight and overdesigned for a lot of what we do on the web. I further agree that JAX RPC never seemed to me to "get it" because they were trying to hide the wire format which would be like trying to hide the HTML from a web page author. It is the contract. Trying to make it look like some well known Java class is misleading, often expensive, and sloppy. All that being said, let me defend BEA a little. The goal behind the WebLogic Workshop model was precisely not to hide the XML but rather to surface it and give the developer two reasonable choices:
    1) Explictly map, as a developer, from xml items to properties in java classes or
    2) Use XML Beans whose interfaces were isomorphic to the XML Schema.
    And the model supported both SOAP and straight XML over HTTP. In short, the goal, which was often stated, was to move developers to an XML message oriented model and away from an RPC like model.
  5. resistance is futile[ Go to top ]

    Well Peter, Isn't it time to give up now? Only in the last ten days there have been one or more articles about Web Services in TSS every day. Soon you will be the last one, to be called, "Champion of Lost Causes".
      
      June 02: JAX-WebServices under attack June 01: Sun unveils services and consulting gig: SOA Path
       May 31: Describing Web Services and SOAs As Options Proliferate May 30: Apache XML-RPC 2.0 released May 26: XINS 1.2.0 released: Simple web services May 25: Ted Neward addresses "Web + Services" May 25: JAX-RPC 2.0 renamed to JAX-WS 2.0 May 24: Designing Web Services with the J2EE 1.4 free book PDF posted May 23: "Three Minutes to a Web Service"
      
    As to RPC vs document/literal, this subject has been beaten to death a thousands times over already with all experts recommending the messaging style over the "OO" style.

    Regards
     Rolf Tollerud
  6. There is just no need for a set of API's for doing Web Services. Sorry but there is no need.

    XML schema is a cross-platform way to describe the I/O for your web service. No "Web Service" tool or API required. 100% interoperable on all platforms. HTTP is the transport.

    WSDL/SOAP is complete crap. It brings no benefit, and all sorts of bagage. The arguments for SOAP and WSDL are just like the ones for EJB's: "you're not 'enterprise' if you don't use SOAP." "Your not 'standards based' if you don't use WSDL.". What a load of bunk!

    In your implementation, use whatever tools you need to consume the XML on the serverside, and marshal a response. Personally I have found JAXB to rock. It's not a tool for "web services", just a way to produce and consume XML. Since it can do I/O directly off a ServletInputStream and ServletOutputStream, it is a great fit. It even supports XPath now. It's just fantastic.

    But whatever! I don't need to cram JAXB down anyone's throat if I define my Web Service completely in XML schema, the cross-platform, interoperable language of XML.

    'nuff said.

    -geoff
  7. document centric[ Go to top ]

    I agree with Geoff.

    I have used SOAP and I have used XML Schema.

    In my experience, what he is saying is to use your own binding to produce whatever XML is necessary, and then use XML schema for the interoperability requirements.

    To me, the point is basically that even when using SOAP, after a message is consumed - you are almost always going to have to transform it anyways. SOAP is a standard, but only for a very few industry specific application domains are there specific doc standards for XML content within the SOAP container anyways.

    And as a side note - for those that have REAL experience doing large B2B integrations - we all know that we are going to be using EDI to avoid overhead anyways!!!

    It certainly is a mess. I think a previous poster's note about how there was never any need to interrogate the wire with DCOM or CORBA is a good reflection point as well.

    Just my 2 cents.

    Good feedback all around however.

    PEACE
    ~tim
  8. unhealthy obsession with HTTP[ Go to top ]

    HTTP is the transport.

    I agree to most of your point but for the HTTP :-). I do think that there is actually very little reason to use HTTP as the major protocol. It is somewhat like "We use HTTP because the servlet container can do cool things for us".

    Quite often the interaction pattern will be rather long lived, with clients sending batches of documents rather than a just single one once a day.

    I came to relish basic socket connections lately (in an environment where I can control the tcp stack to be perfectly honest). It is extremely charming: In a WAN the client has connectivity information prior to submitting the request. Active sessions can be monitored just by locking at netstat. Clients can reconnect directly if a connection breaks rather than when they try to make a request and so on...
  9. oh come on[ Go to top ]

    Well Peter, Isn't it time to give up now? Only in the last ten days there have been one or more articles about Web Services in TSS every day. Soon you will be the last one, to be called, "Champion of Lost Causes". &nbsp;&nbsp;&nbsp;&nbsp;June 02: JAX-WebServices under attack June 01: Sun unveils services and consulting gig: SOA Path&nbsp;&nbsp; May 31: Describing Web Services and SOAs As Options Proliferate May 30: Apache XML-RPC 2.0 released May 26: XINS 1.2.0 released: Simple web services May 25: Ted Neward addresses "Web + Services" May 25: JAX-RPC 2.0 renamed to JAX-WS 2.0 May 24: Designing Web Services with the J2EE 1.4 free book PDF posted May 23: "Three Minutes to a Web Service" &nbsp;&nbsp;As to RPC vs document/literal, this subject has been beaten to death a thousands times over already with all experts recommending the messaging style over the "OO" style.

    Regards
    Rolf Tollerud

    nice try Rolf. Have you ever had to read a WSDL and write a soap message by hand? I've done it several times. More times than I care to mention, because i was integrating between java<-->.NET, java<-->gsoap and webservice<-->xml-rpc.

    do you know WSDL well enough to even do that? I'm no expert, but I have written schema compilers and I have written simple WSDL utilities to parse WSDL generated by .NET, Axis, Apache SOAP, Weblogic, gSoap, and MindElectric. If you want the proof, just go to JMeter's CVS. Rather than writing a full blown WSDL driver, I took the short cut approach and made a light helper class. If I really wanted to write a WSDL driver from scratch, I could, but having skimmed WSDL 2.0 spec, I'm not sure I want to encourage more junk.

    don't worry, be happy

    peter
  10. in case you're humor impaired[ Go to top ]

    Since I've used a variety of webservice toolkits and have spent quite a bit of time reading webservices specs, I do think they have some value. having said that, i am brutally honest about all the short comings of soap webservices and have had to write my own tools to make developing/debugging webservices easier.

    If you bothered to try all the different webservice toolkits out there, you'd see how different they are from each other. The question I ask is this. Given there are standards for webservices, why does cross platform integration with webservices still take so much time? Either the specs weren't clear, or each company purposely didn't follow the spec. In either case, it indicates there are serious issues with one of the goals of soap webservices. If the standard fails to satisfy compatability at the lowest levels, should it be considered a minor error, or a major failure.

    keep in mind that SOAP does have a compatibility test suite hosted on W3C http://www.w3.org/TR/2003/REC-soap12-testcollection-20030624/. Or perhaps all the problems developers are seeing is just a problem of the java world. Oh wait, it includes .NET integrating gSoap. Go look at gSoap's mailing list and tell me it's compatible.

    peter
  11. I love Web Services[ Go to top ]

    "Or perhaps all the problems developers are seeing is just a problem of the java world"

    What problem? Havinge read all the ten latest TSS threads about Web Services I don't get the impression that there are any problem at all. Rather WS succsess story seems more like the story of Alexander the great and the Gordian knot. MS impersonating Alexander in this case. ;)

    "In either case, it indicates there are serious issues with one of the goals of soap webservices. If the standard fails to satisfy compatability at the lowest levels, should it be considered a minor error, or a major failure"

    Of course there is a standard. Precisely as Internet Explorer is the de facto standard of Web Browsers (that Firefox has to follow), the MS/.NET implementation is the de facto standard in the WS world.

    Best regards
    Rolf Tollerud
  12. So basically[ Go to top ]

    "Or perhaps all the problems developers are seeing is just a problem of the java world"What problem? Havinge read all the ten latest TSS threads about Web Services I don't get the impression that there are any problem at all. Rather WS succsess story seems more like the story of Alexander the great and the Gordian knot. MS impersonating Alexander in this case. ;)"In either case, it indicates there are serious issues with one of the goals of soap webservices. If the standard fails to satisfy compatability at the lowest levels, should it be considered a minor error, or a major failure"Of course there is a standard. Precisely as Internet Explorer is the de facto standard of Web Browsers (that Firefox has to follow), the MS/.NET implementation is the de facto standard in the WS world.

    Best regards
    Rolf Tollerud

    Just to make sure I understand your response. You're saying you've never had to integrate between gSoap, .NET, Axis, Apache Soap, Weblogic, IBM and The MindElectric glue. To be fair, if you only have to integrate with the same toolkit/stack, then it's no problem. But if that's the case, use Remoting, or RMI instead.

    So have you ever read the WSDL spec and know how to write a soap message from scratch without a tool?

    choose the red pill or the blue pill

    peter
  13. WSDL is RPC mind trap[ Go to top ]

    So have you ever read the WSDL spec and know how to write a soap message from scratch without a tool?choose the red pill or the blue pillpeter

    WSDL is RPC mind trap.

    Java developers are lured by superficial simplicity WSDL provides.
    They think if tools can generate WSDL for their java objects then interoperation between client and server via web services should not be that hard.
    And they miss completely the reason of web services, blindly trying to implement yet another RPC solution.
    And who to blame ? WSDL of course :))
  14. WSDL isn't the worse spec[ Go to top ]

    So have you ever read the WSDL spec and know how to write a soap message from scratch without a tool?choose the red pill or the blue pillpeter
    WSDL is RPC mind trap.Java developers are lured by superficial simplicity WSDL provides.They think if tools can generate WSDL for their java objects then interoperation between client and server via web services should not be that hard.And they miss completely the reason of web services, blindly trying to implement yet another RPC solution.And who to blame ? WSDL of course :))

    I would say WSDL isn't the worse spec in existence. there are specs out there that are orders of magnitude worse. part of me thinks that if the compatibility test suite was better, interop would be better. So it's much more fun to blame W3C for not doing their job. Plus, it's so much fun to bash W3C.

    peter
  15. W3C must calm down[ Go to top ]

    Peter,

    You forget that this is a discussion of the merits of WS/SOAP and not about whom of us that is the "best" programmer. Remember what happened to your SQL Server expertise? Of course I edit the WSDL, of course I write SOAP calls by hand (but only until Indigo comes along).

    The issue here if you use WS "to call a Java object" you have not understood anything. Then you’re better of with Corba/COM. The call should be as coarse as possible with the pragmatic view that is probably will change many times.

    "So it's much more fun to blame W3C for not doing their job. Plus, it's so much fun to bash W3C"

    I do not blame W3C for not doing their job but rather for being too enthusiastic. Their reason to exist is to ratify best practice from the industry not to sit behind their desk and construct large theoretical systems.

    Regards
    Rolf Tollerud
  16. ever hear the saying[ Go to top ]

    "You say pOtatO, I say potAto"
    Peter,
    You forget that this is a discussion of the merits of WS/SOAP and not about whom of us that is the "best" programmer.
    No, I didn't forget the discussion is about the merits of SOAP webservices. I interpret all this fud about doc vs rpc to style. Either style is fine and neither style is perfect for all jobs. If SOAP webservices was really suppose to be document centric, then why not use an async protocol instead of a sync call like HTTP? Isn't that a contradiction or at minimum an inconsistency. After all, MS is moving over to Indigo driven webservices and they have HTTP Async webservice toolkit in 2.0.
    Remember what happened to your SQL Server expertise?

    I don't understand this fixation with "expertise". Just because I've done things with sql you haven't, it doesn't make me an expert and I've never claimed to be an expert. A sql server expert is someone who works at MS in redmond. I'm just a trouble maker.
    Of course I edit the WSDL, of course I write SOAP calls by hand (but only until Indigo comes along). The issue here if you use WS "to call a Java object" you have not understood anything. Then you're better of with Corba/COM. The call should be as coarse as possible with the pragmatic view that is probably will change many times."So it's much more fun to blame W3C for not doing their job. Plus, it's so much fun to bash W3C"I do not blame W3C for not doing their job but rather for being too enthusiastic. Their reason to exist is to ratify best practice from the industry not to sit behind their desk and construct large theoretical systems.

    Regards
    Rolf Tollerud

    when you get down to the core of the problem, all these techniques are attempting to make remote calls simpler. Had W3C made WS/SOAP use an async protocol to begin with, would there be less confusion and better interop? No one knows, but clearly webservices today have plenty of warts. keeping in mind of course that warts != worthless piece of junk.

    my bias opinion is the focus on style (rpc vs doc) isn't the real problem. the real problem is that if a system is trying to send large documents from point A to B, it really should use an async protocol. If a system wants an immediate response, it shouldn't be sending a huge document and expecting a rapid response from some server.

    peter
  17. ?[ Go to top ]

    "You're saying you've never had to integrate between gSoap, .NET, Axis, Apache Soap, Weblogic, IBM and The MindElectric glue"

    No I haven't. But on the other hand I used SOAP daily in real-life applications. Do you? The reason I ask is because WS is always used asynchronously. Always. Other necessary skills you need to have in your baggage is "how to call WS asynchronously not only from Java/C# but from Javascript, from legacy VB apps, from the D programming language, etc".

    SOAP/WSDL may not be the magic wand to fix everything. But it is sufficient and has proved its worth. There are now billions of dollar invested in SOAP applications, think, even Sun want a share in the business! They are starting WS consulting service ;)) Sun that has fought WS with claws and nails all along - that should ring a bell..

    To change something now would be similar to "changing the width of the American railway system".

    ”my bias opinion is the focus on style (rpc vs doc) isn't the real problem”

    It isn’t any problem if you do it right.

    Regards
    Rolf Tollerud
  18. Asynchrous paradoxon[ Go to top ]

    <The reason I ask is because WS is always used asynchronously. Always.

    WS and "calling asynchronously" is pretty much contradictary. Asynchronous without a full blown message bus means "callback" and, hey, any real world scenario, where a company will allow (or evend facilitate) such callbacks, does usually mean you are within one company and essentially within one network. Otherwise, it simply can not work. No tool in world will get you around basic of network topology. Or did you mean "Polling" or "One way" rather than "Asynchronous"?
  19. Paradox?[ Go to top ]

    Or did you mean "Polling" or "One way" rather than "Asynchronous"?

    Here is a simple example with JavaScript that adds two numbers and illustrate what I mean. It is not necessary to keep five-six calls active "hanging in the air", one is enough. The user can at any time break and to do something else but the feeling will be that the work is flowing smoothly.

    I have written out everything explicit - in real life it would be a generic procedure.

    asyncsample

    Regards
    Rolf Tollerud
  20. Paradox?[ Go to top ]

    Or did you mean "Polling" or "One way" rather than "Asynchronous"?Here is a simple example with JavaScript that adds two numbers and illustrate what I mean. It is not necessary to keep five-six calls active "hanging in the air", one is enough. The user can at any time break and to do something else but the feeling will be that the work is flowing smoothly.I have written out everything explicit - in real life it would be a generic procedure.asyncsample

    Regards
    Rolf Tollerud

    That a callback approach right. Here is a quote from an article from microsoft's site:
    Important If you are making an asynchronous call as I am here, you must set up a callback function through the onreadystatechanged property.

    the article

    Wouldn't all of this be much easier if it was just messaging to begin with? Indigo should make doing async SOAP/WS easier, but async http WS calls feel like an ugly hack to me.

    peter
  21. life is a push push business[ Go to top ]

    Thank you for the link Peter. I guess you could call it a callback even if that denotation in my book implies passing along an object/function pointer. But what the heck, as long as it work.

    "Indigo should make doing async SOAP/WS easier, but async http WS calls feel like an ugly hack to me"

    Yes but it is not available yet!

    The whole episode illustrate some deep down difference how we see the problems in life. Confronting a bug I never make a fuss - just invent a workaround. Furthermore I never have time to complain about something just make do with what I have for the moment. I am the extreme doer/pragmatist: life is not long enough for anything else.

    But there will always be people that complain.

    The whole discussion of "SOAP good vs bad" reminds me of some Palestinians discussing "shall we or shall we not let some Jewish people into our country?"

    It is a little late for that discussion is it not?

    Regards
    Rolf Tollerud
  22. Paradox?[ Go to top ]

    Well now, that is polling! So basically you are doing synchronous calls here.

    If the synchronous call hangs, the process hangs as long as your JavaScript is not multithreaded.
  23. not to mention poor scalability[ Go to top ]

    Well now, that is polling! So basically you are doing synchronous calls here. If the synchronous call hangs, the process hangs as long as your JavaScript is not multithreaded.

    Like I said in a previous post, XmlHttp feels like a hack to me. Even if it uses a callback to notify the javascript, it is still a sync call to the server. And since that's a polling approach, it will overwhelm the server as the number of concurrent clients increases. Polling may work well for cases where the application doesn't need to scale, but for all other cases, it runs into limits very quickly.

    About the only way to scale in this approach is to buy more servers and pay for more rack space. Once WS move to messaging, it will make life easier without the restrictions of sync calls to the server.

    peter
  24. First you said it was callback, now you say it is polling, what's it gonna be? It can't be both you know. :)

    The last parameter in oXMLHTTP.open ("POST", sURL, true) set the async/sync value and I never have had any problem with it. For me it is enough that it works. Then we have not covered how to make async calls in legacy VB, in Java, in .NET, in D programming language etc, all of them using quite different methods.

    Q: Why is async so important? A: Because the user is already irritated that the data is not there in 1/1000 part of a second. Then if she can not at least do some work while waiting but is forced to sit and wait before the computer she will kill you. You know how these ladies are. You will be the death's lamb child as we say in our country. Besides, this is how it works in the browser the users have been accustomed to it!

    But it is not difficult to read between the lines that you are uneasy with this type of GUI programming. Or am I wrong?

    Regards
    Rolf Tollerud
  25. I stand corrected[ Go to top ]

    First you said it was callback, now you say it is polling, what's it gonna be? It can't be both you know. :)The last parameter in oXMLHTTP.open ("POST", sURL, true) set the async/sync value and I never have had any problem with it. For me it is enough that it works. Then we have not covered how to make async calls in legacy VB, in Java, in .NET, in D programming language etc, all of them using quite different methods.Q: Why is async so important? A: Because the user is already irritated that the data is not there in 1/1000 part of a second. Then if she can not at least do some work while waiting but is forced to sit and wait before the computer she will kill you. You know how these ladies are. You will be the death's lamb child as we say in our country. Besides, this is how it works in the browser the users have been accustomed to it!But it is not difficult to read between the lines that you are uneasy with this type of GUI programming. Or am I wrong?

    Regards
    Rolf Tollerud

    glad to say I am wrong, since I didn't look at the actual API and only looked at 2 articles. neither of them were clear and i was lazy, so it's my fault. that brings up a good question though. Obviously, it's using webclient underneath, which uses a separate thread. I see no real benefit of running it in sync mode, when async provides the same behavior without polling and impacting the server.

    since SOAP/WS was suppose to be protocol agnostic, it just makes more sense to use messaging rather than http. I wouldn't call it uneasy. I'd call it "find it horrendous". If I really need to make an async call, I'll write my own client using messaging and by-pass a hack tool.

    peter
  26. "If I really need to make an async call, I'll write my own client using messaging and by-pass a hack tool"

    Of course the best thing is to use two threads, one for initiating and one for response. In the future all will be easier.

    Async is important not only with GUI but also with machine to machine communication. Actually I have seen one "distributed components" case in reality that if one network cable was unplugged the whole telemarketing system with 80 work-stations broke down. Fine isn't it? NOT! (it was a COM project, I hope that MS have fixed that little problem now :)

    Any horrors stories? I collect them..

    Regards
    Rolf Tollerud
  27. Of course the best thing is to use two threads, one for initiating and one for response. In the future all will be easier. Async is important not only with GUI but also with machine to machine communication. Actually I have seen one "distributed components" case in reality that if one network cable was unplugged the whole telemarketing system with 80 work-stations broke down. Tollerud

    This is one of the fine points where the evangelist mixes the logical call paradigm, the technical call paradigm and the application design.

    It is a matter of the client application to cope with outages. Do something meaningful. Whatever. Full stop. End of story. If the client application uses synchronous calls (technical remote call paradigm: Sync) and someone unplugs the network cable, the application should be able to register the failure and to reconnect while the user may carry on making entries (technical and logical local call paradigm: Async). In fact in various transactional scenarios, you might actually consider not allowing multiple call from the client in parallel and even block the bulk of user entries (technical local call paradigm: Async, logical local call paradigm: Sync).

    Actually , if the network is broken, it is not the worst idea to stop the application from sending network requests at all and inform the user about the unavailability. Depends on the application of course, but if you have a lot of users (say in a callcenter) using a very limited number of remote systems, it can be a lot easier (and more network friendly, easier to monitor etc.) to actually monitor and retain the connection rather than opening / closing connections http style.

    After all: This is the way we are often using databases, one of the most critical "enterprise" it components.
  28. too advanced for Rolf[ Go to top ]

    If I in the future by some chance perceive the gist of the meaning of what you are trying to say I will respond. At the moment however I have read it 3 times and understand nothing - expect that you are undoubtly very knowledgeable in your field of course!
  29. too advanced for Rolf[ Go to top ]

    If I in the future by some chance perceive the gist of the meaning of what you are trying to say I will respond. At the moment however I have read it 3 times and understand nothing - expect that you are undoubtly very knowledgeable in your field of course!

    Take a few steps further. Say you have 2 systems, which may make async or sync calls to each other. If for some reason, a construction worker happens to cut the phone line and connectivity is lost, it is critical the system handle it gracefully. In my experience, it's not uncommon for two businesses to have a dedicated link.

    If business A has lost connetion to business B, but business A still has a connection to the internet, it is still operating and doing business. That means any calls to business B need to be queued up and the system needs to be designed such that when connectivity is restored, the system detects it and begins to process the queue in batches. These scenarios are rather common. when I worked on wireless applications, we had to integrate with several 3rd parties. The systems exchanged profile information on a regular basis to stay in-sync. Some calls were synchronous, like checking the availability of flights, hotels and car rentals. But other information like propogating a user's travel plans can happen in an async manner. In other cases, 3rd party systems publish alerts, like "flight United Airlines 200 delayed". Of course, many of these technique can be applied to webservices, if you're willing to bypass the stock toolkits and write your own drivers and tools to do the job.

    peter
  30. give me some difficult to do..[ Go to top ]

    "when I worked on wireless applications"

    We surely have some interesting application/solutions to look forward to. Lucky us because it was going a little boring for a while.

    banner***This time I was not sarcastic***banner
  31. unfortunately, not in the US[ Go to top ]

    "when I worked on wireless applications"We surely have some interesting application/solutions to look forward to. Lucky us because it was going a little boring for a while.banner***This time I was not sarcastic***banner

    unlike Europe, the coverage and quality of cell signal in the US is terrible. Until that improves, there won't be any interesting wireless apps in the US. Plus, I haven't worked on wireless since 2K. though we did do a lot of SOA pre SOAP/WS. Rather than have soap faults like others mentioned, we simple defined error codes and a generic response message to encapsulate error responses. that's not to say soap fault is bad or wrong. Depending on who you ask though, the usage of soap fault may relate to SOAP format error, or application error. There's still a bit of inconsistency across the industry as far as what "constitutes" a soap fault.

    peter
  32. "The Time Has Cometh"[ Go to top ]

    In Scandinavia where I live the time is right. The whole region is covered with G3 operators and last year more G3 phones was sold that ordinary GSM phones. I just love the concept of "the occasional connected client" - at last the development has moved to my own home-turf!

    I am sure that your experience in wireless will give you a nice profit/dividend in the near future. I hope you will remember your old friends/foes when you get rich!

    Where was in the Bible that says "they that was last shall be the first" or something like that? :-)

    Regards
    Rolf Tollerud
  33. I really never thought I'd say that, even qualified.

    1 There is absolutely nothing wrong with WSDL that is not wrong with XML - WSDL uses XML schema (any XML schema) to define message parts. The WSDL specific parts only define service message exchange patterns & portTypes which should be pretty much a given for any IPC async or not. What is wrong with WSDL is how it is used at the moment - almost all machine generated from native interfaces, and soap encoded messages, two factors that as well as effectively eliminating interop give the whole thing a major RPC/OO bias.

    2. HTTP is good enough.
    HTTP defines an addressing scheme and a synchronous request response exchange of rfc822 messages over TCP. Now I don't know about you, but I have found that firewall admins take a pretty dim view of arbitary UDP packets, and even reverse TCP connection is pretty frowned upon (witness the dominance of passive FTP), so we are pretty sure that request and response are going to be on the same TCP connection. That leaves only the sync issue - which as Rolf demonstrated can be handled with better client libraries. That said perter is right one might as well use "messaging" transport, (or better a transport agnostic framework) but as like as not it will just use HTTP underneath for practical reasons (apart from firewalls/proxies stateless server processes are just easier to manage).

    3. on a more general note the complete absense of a coherent async/messaging-style document-oriented WSDL based WS framework is beginning to really piss me off. Hopefully JAX-WS (and maybe AXIS2) will help.
  34. WSDL isn't the worse spec[ Go to top ]

    I would say WSDL isn't the worse spec in existence. So it's much more fun to blame W3C for not doing their job. Plus, it's so much fun to bash W3C.peter
    I'm not bashing W3C. WSDL is probably excelent spec.
    What i'm saying that it's existence is wrong.
    For document centric communication WSDL is practically useless, and for RPC based communication Web Services are worse possible choice. You better off with RMI or CORBA.
    So what is the purpose of WSDL again ? :))
  35. survival of the fittest[ Go to top ]

    Was it 14 different WS spec/proposals existing at the moment? But WSDL is the only one widely used. Heard about Darwin?

    But of course it is not obscure enough, not far out enough, not unknown enough for the one true geek.
  36. WSDL isn't the worse spec[ Go to top ]

    The purpose of WSDL is not just the interface specification. Most important part of the WSDL is the type definition that defines the schema for the input, output and fault messages. In a Document/Literal scenario, these definitions are used to validate the data, as well as provide a contract on what to expect in terms of data format.

    PortType (Interface) and Port (End-Point) definitions are a way of listing available services.
  37. that's all good, except[ Go to top ]

    The purpose of WSDL is not just the interface specification. Most important part of the WSDL is the type definition that defines the schema for the input, output and fault messages. In a Document/Literal scenario, these definitions are used to validate the data, as well as provide a contract on what to expect in terms of data format.PortType (Interface) and Port (End-Point) definitions are a way of listing available services.

    if a system actually follows the type validation defined in the schema, what happens if the type changes? If the production server happens to deploy a webservice that uses validation and the partner system is updated with changes, the validation will likely cause a SOAP exception of some sort. To avoid that, you can turn of schema validation in production and just use in development environment.

    If it's document based webservice, you reduce the likelihood changes on the remote system will cause the application to break. I like the idea of handling the validation at a higher level, so that non-critical changes do not cause the production environment to suddenly stop working. But at that point, it would be easier to bypass soap and just use schema to define the model and wsdl to define the calls.

    peter
  38. that's all good, except[ Go to top ]

    if a system actually follows the type validation defined in the schema, what happens if the type changes?


    What happens if the type changes in other types of systems. For example CORBA IDL Changes. If the data can change that occasionally, I think people should use some generic data types like a Map of name, value pairs or some thing like that.

    In fact making it as a XSD means as long the XML validates we are OK. Which gives greater flexibility than CORBA or RMI.
    If the production server happens to deploy a webservice that uses validation and the partner system is updated with changes, the validation will likely cause a SOAP exception of some sort. To avoid that, you can turn of schema validation in production and just use in development environment.
    I think it is a good idea for that to fail, then work on some data that may not be correct any more. You should exercise care and caution when updating webservices that are used by partners. This is a general problem and is not addressed by any specification.
    If it's document based webservice, you reduce the likelihood changes on the remote system will cause the application to break. I like the idea of handling the validation at a higher level, so that non-critical changes do not cause the production environment to suddenly stop working. But at that point, it would be easier to bypass soap and just use schema to define the model and wsdl to define the calls.peter

    I think we are converging here. Because WSDL really imports the schema's and just defines interfaces, if you start from WSDL and XSD.
  39. I love Web Services[ Go to top ]

    Precisely as Internet Explorer is the de facto standard of Web Browsers (that Firefox has to follow), the MS/.NET implementation is the de facto standard in the WS world.Best regardsRolf Tollerud

    Sorry, I cannot see how can ASP.NET WS be any better than JAX-RPC in regard to being synchronous RPC centric? Are you saying the problems (RPC centric etc.) with JAX-RPC came actually from the de-facto standard ASP.NET WS?
  40. JAX-WebServices under attack[ Go to top ]

    Document/XML centric or RPC/object centric, or something else entirely? What do you think?

    Undoubtably Document/XML centric. As pointed out in the various papers, there are just too many issues with Object-to-XML binding. Personally, I would still convert XML data to object data before working with it, but if I have direct access to the XML, I can choose my own XML binding technology. That way I can tailor my binding to the problem at hand.

    It looks like the JAX-WS lead is thinking about these problems. It's interesting that they are planning on using the javax.xml.transform.Source interface as their XML propogation mechanism; it is pretty much exactly what I would have done.

    Now, it would be nice to see an API that would support RESTful as well as SOAP-based XML messaging. There appears to be nothing in the proposed Dispatch and Provider interfaces that is SOAP-centric.
  41. JAX-WebServices under attack[ Go to top ]

    Now, it would be nice to see an API that would support RESTful as well as SOAP-based XML messaging. There appears to be nothing in the proposed Dispatch and Provider interfaces that is SOAP-centric.

    You should then have a look at XINS. I've just added 1 hour ago the SOAP calling convention and the API to WSDL target.
    Note that I haven't tested it yet.
    http://xins.sourceforge.net
  42. 1. thank you all for reading our paper. It will be presented at the IEEE Web Services conference in July: http://conferences.computer.org/icws/2005/

    2. We looked at JAX-RPC2, but didnt want to criticise it directly as we lacked enough experience of it.

    Personally, I don't think having a 'raw xml' option as a get-out clause is sufficient. Not if the main thrust of the API is "our runtime will magically generate XSD and WSDL from your java classes, solve all interop problems and let you make blocking RPC calls to very distant sites".

    RPC is the wrong paradigm for long haul connectivity, pure and simple. Its OK on a single machine, workable on a LAN, great on InfiniBand, but not the right way for say, a laptop, to invoke a web service while it roams round a building with patchy WLAN coverage.

    As for automatically creating a service interface by extracting information from your source code, well, that is just a backward way of working. Those aren't interfaces you are exporting, just implementations.

    The other big problem with JAXRPC is the engineering cost of implementing. IBM can afford to do it. BEA can afford to. Maybe Sun can; they have no choice. But is it the right thing for an Open Source project to do? The more effort invested to hide the XML and networking from end users, the harder it is for those end users to transition into becoming developers who can maintain the project. Unless the OSS implementation(s) are to remain the domain of J2EE stack vendors, we need a community, and JAX-RPC, like EJB itself, is not an API designed to create communities.
  43. JAX-WebServices under attack[ Go to top ]

    There's only one problem with web services that I see.
    It's that most developers cannot think about web services in non RPC fashion :))
  44. And the winer is[ Go to top ]

    Steve, Edmund,

    I agree with allmost all of your comments. And I will slightly extend your ideas.
    As you propose, at the end we get document/literal XML message wrapped in a SOAP body with SOAP header.
    Is the SOAP crap good for something? I do not think so. No state, no security, no privacy. Just a wrapper.

    So what about REST?

    Yours,
    Cybernet Sauvignon.
  45. just wait for WS-I[ Go to top ]

    Steve, Edmund,
    I agree with allmost all of your comments. And I will slightly extend your ideas.As you propose, at the end we get document/literal XML message wrapped in a SOAP body with SOAP header.
    Is the SOAP crap good for something? I do not think so. No state, no security, no privacy. Just a wrapper.So what about REST?

    Yours,Cybernet Sauvignon.

    <sarcasm>
    it's there to look pretty and give WS-I a reason to pile it on higher and deeper.
    </sarcasm>

    peter
  46. SOAP vs Rest[ Go to top ]

    Steve, Edmund,I agree with allmost all of your comments. And I will slightly extend your ideas.As you propose, at the end we get document/literal XML message wrapped in a SOAP body with SOAP header.Is the SOAP crap good for something? I do not think so. No state, no security, no privacy. Just a wrapper.So what about REST?.

    I have to work with SOAP, (in fact WS-RF), because I have to integrate with othe Grid-related standards, WSDM, etc. Our proposed alpine stack is a form of damage limitation; lightweight technology to let you stay in the XML-space.

    There are actually some advantages to SOAP. The best part (IMO) is the SOAP fault: a standard way of encoding fault data, above and beyond HTTP error codes. It could be better with well known elements for stack traces, those http error codes etc. The other invaluable feature is the SOAP header; orthogonal data that different handlers can use. Now, sometimes that SOAP header gets over-used; it no longer very 'orthogonal' when the header includes addressing info above and beyond the URL -any more than when cookies are used in a GET request to dynamically generate different pages off the same URL.

    Returning to REST, I can see its appeal. I think we ought to have a common XML fault payload to extend the well known HTTP error code; ideally a fault with a standard CSS sheet hosted on the W3C so that end users would still see a readable message on a 5xx error.