Discussions

News: The True Nature of Web Services

  1. The True Nature of Web Services (15 messages)

    In the year 2000, many marketplaces did not achieve the results that had been announced. Suddenly, the enthusiasm that was buzzing around B2B has cooled. Every new trend always has an even newer one hot on its heels, and as the excitement in the marketplaces fizzles out, a new notion is already gaining ground with the media: Web Services.

    Read the rest of this paper at:
    http://www.techmetrix.com/s/rd.php3?url=tmk0501/tmk0501-2.php3:6301

    Threaded Messages (15)

  2. I do not understand why the author calls SOAP "a lightweight protocol"... Is it really lightweight? What does he mean? IMHO RMI and CORBA are more effective because they are binary and do not need all that parsing.

    I cannot see how writing RMI applications might be painstaking... I cannot imagine an RPC protocol with a simpler API and a comparable functionality.

    Besides, I hate when somebody claims that SOAP is good because it "naturally crosses firewall boundaries". This is true but IMHO using HTTP for RPC is a paranoia. If somebody lets HTTP through his firewall, he expects it to contain WWW content, not RPC, which might do anything in his local network. When SOAP gets popular and all services are accessible with it, we will return to old good times, when everybody has access to everything. A natural consequence will be to establish a kind of HTTP-level firewalls, which will be filtering out everything except several services. It looks familiar, doesn't it?

    SOAP is not bad, it has its value - it is open. But must it really go through HTTP? Why not open another TCP port? It would be easier to set up filtering rules in firewalls and control network traffic.
  3. The True Nature of Web Services[ Go to top ]

    The final answer is :
    a XML-document is self descripted ;-)

  4. I do not understand why the author calls SOAP "a lightweight protocol"... Is it really lightweight? What does he mean? IMHO RMI and CORBA are more effective because they are binary and do not need all that parsing.

    I cannot see how writing RMI applications might be painstaking... I cannot imagine an RPC protocol with a simpler API and a comparable functionality.

    Besides, I hate when somebody claims that SOAP is good because it "naturally crosses firewall boundaries". This is true but IMHO using HTTP for RPC is a paranoia. If somebody lets HTTP through his firewall, he expects it to contain WWW content, not RPC, which might do anything in his local network. When SOAP gets popular and all services are accessible with it, we will return to old good times, when everybody has access to everything. A natural consequence will be to establish a kind of HTTP-level firewalls, which will be filtering out everything except several services. It looks familiar, doesn't it?

    SOAP is not bad, it has its value - it is open. But must it really go through HTTP? Why not open another TCP port? It would be easier to set up filtering rules in firewalls and control network traffic.
  5. The True Nature of Web Services[ Go to top ]

    You can call just a service me method by passing XML data rather than
    remebering the frustrating API list, language-dependent protocols(RMI, Corba).

    I am still confusing,

    1) How is it compared to use Messaging(e.g JMS) for B2B integration?
    2) The writer said, "Does this mean that web services are just another trend
       that supplier are trying to get us to swallow?". His answer is "NO" without
       detail explanations. Can anyone tell more on that?
       Now that eMarketplace is shrinking as intermediary because of business
       hesitation. Why XML on SOAP to UDDI described by WSDL solution will not suffer
       from it?

    Citystory
  6. The True Nature of Web Services[ Go to top ]

    Hello All-

    Web services is very important. The hard part about this technology is that there is no real definition of what the scope of web services is. The broadest definition seems to be "Anything accessible with an XML interface." That's kind of broad.

    In either way web services is NOT a replacement for J2EE. Rather, they are complementary bedfellows. Web services is just going to become a standard way to expose, advertise, and access a service via XML. This is critical because this is the largest percentage of companies in the enterprise space that have conciously agreed to support these protocols in an open standard.

    SOAP has two benefits: RPC-style invocation over XML and a document transport protocol. The confusion that I've heard so far is around people thinking that SOAP is a replacement for RMI invocations. I really don't think this is in the intent of SOAP.

    SOAP servers could potentially be embedded in many other places OTHER than an application server. SQL Server's release later this year will have a SOAP interface, for example, and you will be able to modify the schema and the data through SOAP invocations. Granted, an argument could be made as to why SQL Server just didn't support a COM interface, but an XML-based interface over SOAP will allow people who are non-developers to construct XML queries that interface with the database. If SQL Server had an RMI interface, that couldn't happen.

    Another benefit that SOAP provides is the ultra-thin client for an application server. For example, in WebLogic Server, if you want to have a client that accesses an EJB directly, there are approximately 300K worth of class files that have to be packaged into a JAR file and accessible to the client. Some of these classes would have to be WebLogic-specific. If that Java client were converted into a SOAP thin client, the Java client would only the client-SOAP library class files (these would be standard and not proprietary).

    However, I agree that SOAP is pretty rudimentary and not the utopia of web services. SOAP doesn't have state, security, or transactional awareness. This only makes it possible to do SIMPLE web services. I predict that as web services becomes more prevalent, the need for COMPLEX/BUSINESS web services will be necessary. Business web services will be transactionally aware across the enterprise, have single sign-on security, support business process management, have stateful behavior, etc.

    So, as you can see, web services has a long way to go.

    Tyler
  7. I'll have to agree with Bartosz here.

    The true nature of SOAP only relates to us as software developers being lazy.
    When we develop our applications using RPC (RMI, CORBA ...), it is kind of hard to debug what's happening onnthe wire because of the binary nature of data.

    So we figured it out that with XML we can grab the packages and figured it out easily.

    Of course we could write better tools for CORBA or just buy existing ones, but it's easier for us just to use SOAP, whithout really thinking of the consequences for the software system.
    So for the system SOAP is bad, but for us it is definitely soimething good.

    This is the only real difference that favours SOAP.

    The rest is just vapourware.

    CORBA has a complete typeing system capable of transporting no matter how complex data, also have RMI and COm and old style RPC.
    So how can somebody in godd faith say that XML is necessary in order to transport complex data in RPC ?

    Client libraries size, oh yes, so because Weblogic uses a proprietary protocol, then CORBA also is at fault ?

    SQL Server does not use XML because of a technical necesity, but because it the HYPE, not to mention that any serious DBA has to disable the XML query interface because of security issues,.

    SOAP has a fundamental problem, it uses text to transport nomatter how complex data, worse XML is a redundant structure by its nature, and it wastes space in order to gain understandability by humans.

    RPC is essentially a conversation between computers, not humans.
    If programmers are not good enough to let computer speak their own language (which should be binary and optimized as in CORBA, DCOM), then yes, we can accept our failure and go with SOAP.

    Already people are writing compression tools for XML data and SOAP packages , so we're going back in circles.
  8. I have to admit that the human readibility of SOAP is something that does not interest me at all. I have no interest in ever debugging what goes accross the wire. As an application developer, that aspect is something that is bought from a middleware vendor and it is assumed it just works (or you get your money back).

    For RPC, all I want to know about is that I make a method call on object and that gets executed on a remote object. How this is achieved is again no interest to me so long as it works - its the middleware vendor's responsibility

    The fact that SOAP can be over HTTP is of some benefit in that HTTP is open on just about every firewall there is. But as mentioned above, IIOP can be tunnelled over HTTP. But mention "tunnelling" to a security guy and wait for the reaction. But SOAP, for me, is just another form of tunnelling. The only difference is that is is text, it is easily filtered (albeit that to filter to any detail is non-trivial).

    Where using XML for marshalling is somewhat interesting is to reduce the sensitivity of interfaces. CORBA developers will know only too well how much weight rests on the poor old IDL file. If you need make even a small change to a critical IDL file, it is a monumental operation.

    XML on the other hand does allow the unsuspecting party (to the interface) to just elegantly ignore the stuff in the RPC call that it knows nothing about and is no expecting. So backward compatibility between interfaces is possible (so long as you dont go removing stuff). However, as mentioned above, this is at some cost.

    The rest of the arguments regarding the "lightness" of SOAP (absence of proxies etc) I dont buy.

    However, the fact remains that as Microsoft are heavily supporting it - SOAP is the obvious choice for M$ <-> J2EE integration.

  9. Router manufactuers are already looking at building SOAP blockers/filters in to their products. No company wants uncontrolled RPC going through a firewall.

    As for XML reducing the brittleness, I have mixed feelings. If you look at the green pages aspect of Web Services, it basically implies a known interface. Parameters to method calls can be XML documents but you can do this with Corba anyway, use a string parameter.

    Given, the interface in WebServices is fixed/known (the green pages) what does the XML marshalling really buy you besides bulkier messages and a more expensive marshalling process?

    You can add methods to a Corba object without recompiling existing client stubs. The method name is just a string in the IIOP packet. Change the parameters is trickier but you can always pass an XML document as a string or use property lists (sequences of anys or name/value structs).
  10. Whoever complains that in CORBA you have to recompile everything has definitely forgotten that CORBA supports both DII and DSI.

    In CORBA you can choose everything you need, from dynamic/static on the client, dynamic/static on the server, and combine that with synchronous/asynchronous/one-way invocation and you have far better flexibility than in the systems which are reinventing the wheel.

    Remember there is also a Corba Scripting, which is definitely not compiled and totally dynamic.

  11. Hi Tyler,
    Agreed for all, I can see a role for Web Services but I don't buy the thin client reason.

    I don't think that a SOAP client is any thinner than an RMI/IIOP one. You need a SOAP client runtime, the XML parser, a decent HTTP client (the one in the JDK has bigtime limitations, see my articles on TSS about SOAP for more details) or other transport. Programmers won't be happy using raw SOAP so people will make client stubs generators and thus add to the bulk.

    Thin clients should make sparing use of memory and all this XML marshalling and strings manipulation takes more memory and cpu cycles than the corresponding RMI/IIOP equivalent. Surely for pervasive devices this is an argument against using SOAP at all or any technology layered on top.

    With 1.3 RMI/IIOP is supposed to be bundled with the JDK and XML parsers etc may not be 'standard', i.e. bundled in the JDK. It's also not clear whether vendors will in any case use custom versions of anything provided in the JDK thats middleware related as they may need to work around bugs/issues etc as IBM did with the ORB for WebSphere so that may also increase the bulk of the client footprint.

    I see it mainly as an integration technology for building B2B or Portal type applications. It can be applied between different companies eBusiness's or as an integration technology between large applications in a single company (a company builds a portal on top of existing applications for example).

    I think companies like BEA, IBM etc need to start evolving towards service brokers. Web Services are just a fascade on a service broker. I've written an article on service brokers that should be available on TSS shortly describing what they are and why their important.

    Thanks
    Billy (billy at ejbinfo dot com)
  12. Granted, web services may have a way to go, but has
    anyone checked out GLUE yet? :)

    The Mind Electric
    http://www.themindelectric.com

    Main GLUE page
    http://www.themindelectric.com/products/glue/glue.html

    User Guide:
    http://www.themindelectric.com/products/glue/releases/GLUE-BETA-2.2/documentation/userguide.html#installation

    GLUE discussion group:
    http://groups.yahoo.com/group/MindElectricTechnology

    Eileen Sauer
    eileen@middleware-company.com
  13. GLUE is very cool....
  14. The True Nature of Web Services[ Go to top ]

    You can call just a service me method

    > by passing XML data

    First off one just wants to generate XML and send it, but then one's needs will increase and one will want to be able to use regular method call semantics, automatic marshaling and so on. Eventually one will get CORBA or RMI rewritten from scratch but with higher overhead. Note, that some people already proposing compressing SOAP messages using gzip, in complience with HTTP standard, or compiling them according to DTD into binary XML representation.

    > rather than remebering the frustrating API list

    One needs API's to access SOAP, CORBA and RMI.

    > , language-dependent protocols(RMI, Corba).

    CORBA is not language dependent, RMI maps onto CORBA through RMI over IIOP. And, by the way, IIOP can be layered on top of HTTP (see Borland's VisiBroker Gatekeeper or IONA's OrbixWeb).
    And IIOP is as open standard as SOAP.

    > 1) How is it compared to use
    > Messaging(e.g JMS) for B2B integration?

    SOAP is wire protocol for remote calls.
    JMS is message oriented midleware infrastructure.
    In pricniple one can use JMS implementation that uses SOAP as message transfer protocol.

    > Can anyone tell more on that?
    > Now that eMarketplace is shrinking as
    > intermediary because of business hesitation.
    > Why XML on SOAP to UDDI described by
    > WSDL solution will not suffer from it?

    They will suffer short term but flourish, in some form, long term. Because businesses will save money in procurement using these technologies.

    Artem
  15. SOAP will be used as a message transfer protocol for homogeneous & heterogeneous environments. Such as, currently we r using SOAP as a bridge between .NET & Java Networking.
    JMS will be used as a message oriented middleware for homogeneous environments. In any Java Applications, we can use this for message transfer.
    SOAP is relatively simple *to use and develop* (It is subjective) as compared to JMS. Also SOAP is extensible.
  16. logic[ Go to top ]

    i am using logic:iteraror tag to display data from a arraylist
    i am usign like this
    first i set the data in action file like this
    request.setAttribute("userdetails",userdetails);
    in the jsp i am usign like this

    weight loss programs for women