Hard Core Tech Talk with Rahul Sharma, JAX-RPC Spec Lead, Posted

Discussions

News: Hard Core Tech Talk with Rahul Sharma, JAX-RPC Spec Lead, Posted

  1. A new Hard Core Tech Talk interview with JAX-RPC Spec lead Rahul Sharma has been posted on TheServerSide. In this interview, Rahul talks about the importance of JAX-RPC for Web Services integration, how it is being used with the J2EE component model, and the use of tools for endpoint mapping; he also looks at SOAP extensions, and the potential for JAX-RPC Security and Transactional support.

    Watch Rahul Sharma's Interview Here

    Threaded Messages (15)

  2. There was no substance to this interview. Other than the fact that JAX-RPC is based on XML, which was mentioned over and over and that 'one' of the implementations will be SOAP over HTTP, there was really no information.

    Here are some comments on JAX-RPC from my limited information gathering aout and comparison to other tools (GLUE for instance which I have used quite a bit).

    1.) Why does it seem that Sun is so always so hell-bent on making things difficult? For instance, JAX-RPC has a lot of additional complexity because Sun did not want to directly tie it to SOAP. Who are they trying to kid? For practical implementation, JAX-RPC == SOAP and making it more flexible to support 'imaginary' XML based protocols of the future is to introduce unneccessary complexity with no gain. You can't predict the future. If there is a new and better imaginary protocol in the future, then address it then.

    2.) Rather than wasting incredible amounts of time writing specifications for a protocol that is already pretty well specified (i.e. SOAP, damn we got specifications on top of specifications here) Sun should just write a solid implementation, make it part of Jave and the rest of the world can get on with using it. We wouldn't need a specifcation if it was just 'part of Java'. SOAP is not rocket science, it doesn't need another layer on top of it.

    3.) Sun should just buy TME which offers the best, easiest to use SOAP implementation bar none, or at least look at it so they can get a clue about how simple and easy things 'should' be. Suns builds RPCs like it was 1975. Hello! Dynamic proxies, reflection, introspection, things you guys built but seem to forget to use when it comes to implementations. Use them.

    Cheers.

  3. >> Here are some comments on JAX-RPC from my limited
    >> information gathering

    To answer your points in order:

    1) JAX-RPC depends on SAAJ (ie SOAP). I am not sure what complexity there is to avoid tying it to SOAP - it is tied.

    Incidentally, FYI, there is some debate/opinion as to whether SOAP is really going to last as the "Web Services" protocol (check out some articles on REST vs SOAP - theres quite a few)

    2) SAAJ, JAX-RPC (and JAXM) only define the standard Java APIs for SOAP-based RPC and messaging. Although this is an over-simplification; the SOAP and WSDL specifications define the wire interoperability - the JAX specs define the vendor neutral Java binding. I dont see any overlap.

    (I personally think it would be completely crazy of Sun to make an *implementation* part of the Java platform. API's that support different vendors has been key to the successes of Java/J2EE. Implementation choice is very important.)

    3)
    >> Sun should just buy TME
    What should BEA and IBM and all the other vendors do?

    >> Hello! Dynamic proxies,
    You will find that dynamic proxies and dynamic invocation are actually part of the JAX-RPC spec. In any case, for most applications, generated proxies will be just fine.

    -Nick
  4. Nick,

    Couple of comments on your comments ;-)

    > JAX-RPC depends on SAAJ (ie SOAP). I am not sure what complexity there is to avoid tying it to SOAP - it is tied.

    In the interview Rahul Sharma says:
    "Now as far as the JAX-RPC APIs are concerned, they're not tied to any specific protocol binding. So for example there's no assumption that SOAP/Http will be the underlying protocol."

    That doesn't sound like it is tied to SOAP to me. "not tied to any specific protocol binding" sounds like it is not tied to any specific protocol binding, but maybe I am just reading that wrong.

    >Incidentally, FYI, there is some debate/opinion as to whether SOAP is really going to last as the "Web Services" protocol

    Debate is a long way from resulting in anything. Microsoft, IBM and others are currently strongly behind SOAP. Sun had to be dragged kicking and screaming into the picture and VERY late in the process. There has been a long (very long) build-up to this point. It will be be difficult to dethrone SOAP due to it's momentum (it took forever to get it going in the first place)

    <quote>
    I personally think it would be completely crazy of Sun to make an *implementation* part of the Java platform.
    </quote>

    This is a puzzling statement to me. One of the largest pieces of value of Java is the large API that is built into it (built by Sun, i.e. implementation). Threading, networking, graphics, etc, etc. Now each one of these 'could' have been defined as a specification and left to others to implement and with a 'certification' process and so on. We would then be left to buy and put together the pieces seperately. In the end we would have a nightmare of pieces that cost a lot of money and 'almost' work together.

    The specification could still be made, I'm not against specifications, specification is just design, but Sun should have a default implemenation built-in to Java just like it has done with XML parsing and encryption in JDK 1.4. Are you suggesting that Sun was foolish to put a default implementation of XML parsing and encyption into JDK 1.4? SOAP is not more complicated than XML parsing, or encryption, so why couldn't Sun do the same thing as it did with these pieces and build in a default implementation into Java that everyone can rely on. RMI is built into Java. This would just be an alternative to RMI, not significantly different really. Build it into Java. I don't think that is too outrageous.

    <quote>
    >> Sun should just buy TME
    What should BEA and IBM and all the other vendors do?
    </quote>

    They should use the default implementation (based on TME in my ideal world) just like everyone else? I don't see BEA and IBM making their own SWING or java.net.*, etc. The use the ones that are there as part of the standard API, just like everyone else.

    <quote>
    You will find that dynamic proxies and dynamic invocation are actually part of the JAX-RPC spec.
    </quote>

    I would be very surprised at this, but anything is possible I don't plan to read the spec anytime soon to find out either, because for me it is solving a problem I don't have (I'll just use continue to use GLUE like I do now).

    Cheers.
  5. <quote>
    In the interview Rahul Sharma says:
    "Now as far as the JAX-RPC APIs are concerned, they're not tied to any specific protocol binding. So for example there's no assumption that SOAP/Http will be the underlying protocol."
    </quote>

    This goes well with your own quote “You can't predict the future.”, doesn’t it?

    <quote>
    Sun had to be dragged kicking and screaming into the picture and VERY late in the process.
    </quote>

    Very late? Depends on whom you ask, I guess. Currently, 95% of our vendors (Java based and others) do not support WS in any shape or form. Most of the vendors do not have any immediate plans for WS support (it’s not a critical issue, there are other/old ways to get things done that have been working for years).

    <quote>
    SOAP is not more complicated than XML parsing, or encryption, so why couldn't Sun [...] build in a default implementation into Java that everyone can rely on.
    </quote>

    Rahul Sharma: “... there's no assumption that SOAP/Http will be the underlying protocol.”

    <quote>
    I don't plan to read the spec anytime soon to find out either, because for me it is solving a problem I don't have.
    </quote>

    Then why are you upset that the spec is not going fast enough? ;-)

    -- Igor
  6. <quote>
    In the interview Rahul Sharma says:
    "Now as far as the JAX-RPC APIs are concerned, they're not tied to any specific protocol binding. So for example there's no assumption that SOAP/Http will be the underlying protocol."
    </quote>

    This goes well with your own quote “You can't predict the future.”, doesn’t it?

    <quote>
    Sun had to be dragged kicking and screaming into the picture and VERY late in the process.
    </quote>

    Very late? Depends on whom you ask, I guess. Currently, 95% of our vendors (Java based and others) do not support WS in any shape or form. Most of the vendors do not have any immediate plans for WS support (it’s not a critical issue, there are other/old ways to get things done that have been working for years).

    <quote>
    SOAP is not more complicated than XML parsing, or encryption, so why couldn't Sun [...] build in a default implementation into Java that everyone can rely on.
    </quote>

    Rahul Sharma: “... there's no assumption that SOAP/Http will be the underlying protocol.”

    <quote>
    I don't plan to read the spec anytime soon to find out either, because for me it is solving a problem I don't have.
    </quote>

    Then why are you upset that the spec is not going fast enough? ;-)

    -- Igor
  7. I don't see BEA and IBM making their own SWING or java.net.*, etc. The use the ones that are there as part of the standard API, just like everyone else.


    Actually, I *do* see IBM making their own SWING - what do you suppose the SWT toolkit is, that Eclipse/WSAD uses?


    Andrew.
  8. Anick,

    JAX-RPC allows both statically and dynamically generated proxies. Furthermore, it allows the dynamic invocation of methods (basically via String parameters) without a proxy (= Java interface).

    You'll probably be surprised that TME plans to include JAX-RPC support in GLUE, scheduled for Q3 2002. This should not be too hard for them: Currently, they have their own service lookup and dynamic invocation class (electric.registry.Registry). Then, they will also support the JAX-RPC classes (javax.xml.rpc.Service, javax.xml.rpc.ServiceFactory).

    What I like about GLUE's way of service lookup is that you do not have to deal with WSDL ports (in most cases there will be only 1 per service anyway). You simply specify a URL to the WSDL of the service and a Java interface, the port gets selected via the given interface. In JAX-RPC, this is also supported, but you always need the Service indirection: The lookup returns a Service, a getPort call with an interface parameter on the service returns the appropriate proxy.

    It is obvious that the focus of JAX-RPC is on Web Service clients. For the server-side service implementation, there is just the "Service Endpoint Model" for servlets in chapter 10: a ServiceLifecycle interface that your service implementation class can implement, and a ServletEndpointContext interface containing HttpSession, ServletContext, etc, provided via ServiceLifecycle's init method. An EJB-based service endpoint model will follow in EJB 2.1. Note that you do not have to care about JAX-RPC at all (if you do not want to) for writing JAX-PRC-"compliant" service implementations.

    Finally, JAX-RPC 1.0 does not provide specifications for packaging, deploying, and publishing Web Service implementations. Thus, this is vendor-specific. And IMHO GLUE really shines in this respect: Simply map the GLUE servlet, and register your services in an XML file in WEB-INF\services. No WSDL or skeleton generation at all.

    Regards,
    Juergen

  9. While responding to your post is most probably a waste of time (given your most recent (facetious) post above), I will do so for the sake of humour...

    >> "they're not tied to any specific protocol binding. So
    for example there's no assumption that SOAP/Http will be
    the underlying protocol"

    I think that the point being made was that JAX-RPC was not tied to SOAP over *http* (since, after all, SOAP is not tied to http).

    >> "but Sun should have a default implemenation built-in too Java just like it has done with XML parsing and encryption in JDK 1.4. "

    I agree. They are quite welcome to supply a *default* JAX-RPC implementation (indeed they have). However, the vendor neutral API allowing pluggable implementations is a must - as is the case with RMI, security, parsing, etc, etc.

    >> "They should use the default implementation "

    Are you suggesting BEA, Systinet, Sonic, IBM, etc, etc should just throw away their SOAP implementations they have developed (and sell)?? The Axis project members should also delete their CVS tree and find something else to do?? I guess you and the TME guys will be very happy - but its rather unlikely - and rather pointless even discussing.

    >> "I would be very surprised at this, but anything is possible I don't plan to read the spec anytime soon "

    And therein lies the problem. Before posting outright criticism of the spec, you should first read it. (At the very least skim the Table of Contents!).

    -Nick

  10. could any of you give me some useful links for JMX,SOAP
    articles on the net.
    also is sun doing enough to catch up with Microsoft and IBM as far as web services is concerned.
  11. Ok. I have been humbled. I could argue further on certain points, but I will not.

    I should read the spec first before criticizing.

    I see that I am wrong about many things.

    Good luck with your career as well. As for mine I think I am ready to change. Writing tedious code for unforgiving app servers to perform 'monkey work' - extract data from DB, write data to DB - has lost any luster that it might have had.

    Cheers.
  12. Too many replies to respond to. Yes yes you are all right:

    - JAX-RPC is incredibly easy to use and nice and compact too (should run on a palm pilot or cell phone, no problem). We know from experience with RMI and CORBA that we can rely on Sun to make RPC simple.
    - Sun should never bundle anything with Java, and instead everything should be vendor specification with multiple implementations done by IBM, BEA, and a dozen other companies. Nothing improves productivity like having to work out the differences between many different implementations. Look at SQL for example. We all know that there are no difference between talking to databases thanks to the specification and therefore interoperabilty is seemless.
    - Sun was not late to the web services party. 2-3 years is not late at all. In fact Sun invented web services and just waited for everyone else to catch up.
    - JAX-RPC is both tied and not tied to SOAP and therefore is optimal in both simplicity and flexibility. It will automatically be able to take advantage of any future protocol. Awesome.

    This it great news, thanks for setting me straight.

  13. You're welcome.
    Good luck with your career.

    -Nick
  14. This it great news, thanks for setting me straight.


    First of all, I'm a bit disappointed by your cynic remark. I think I have given a quite reasonable overview of JAX-RPC that I have extracted from the spec myself, and also pointed out the relation to GLUE (that I really like!).

    I'm no defender of Sun and its specs at all. I even think that many of its J2EE specification efforts tend to grow over-complex and too locked up in their own world, like EJB and also JAX*. And all of this is backed by Sun's J2EE marketing that IMHO misplaces emphasis on EJB and Web Services.

    But after all, JAX-RPC is not that bad. That's just my opinion after skimming though the spec. It's appropriate for SOAP-based Web Services. Note that I consider SOAP itself not appropriate for many problem spaces, but that's not the problem of JAX-RPC.

    Concerning the multi vendor issue: IMHO there is no need for a lot of SOAP implementations, but I don't mind having the choice between a few. However, I consider choice between RPC protocols more important. Hence I am a fan of Caucho's Hessian and Caucho's Burlap: Slim HTTP-based protocols, simple open source toolkits... Really handy, especially for RPC between Java processes over the Internet or heterogenous LANs.

    An important issue for me is not tying my service implementations and service clients to a specific protocol or toolkit. On the server side, this is easy: Service implementations are just plain Java classes implementing the service interface, without regard to the access protocol. Publishing such a service implementation on a server is toolkit-specific, even with JAX-RPC. I don't mind that as it does not affect my application code but just the server configuration files. This works with JAX-RPC, GLUE, Hessian, Burlap, and even RMI-JRMP if you write a simple RMI publishing servlet, for example.

    On the client side, JAX-RPC is a way to write toolkit-independent but still protocol-dependent access code (caring about WSDL ports etc). Thus, I see a need for more isolation of toolkit and protocol dependencies here which is possible when using proxies and not dynamic method invocation: Client application code should just receive a proxy that implements the service interface by a very agnostic getService method with just a service name parameter (or a similar JNDI lookup). Protocols, toolkits, and service URLs should be configured somewhere outside. Switching toolkit or protocol for remote communcation or even using local implementations instead of proxies for remote services should not affect my application code, then.

    BTW, I have already thought about writing such a simple service abstraction toolkit and provide it as open source. The basic idea is similar to that of Jakarta Commons Logging: An ultra-thin bridge between different remote service toolkits, providing out-of-the-box factories for JAX-RPC, GLUE, Hessian, Burlap, RMI-JRMP, and RMI-IIOP.

    Juergen
  15. Juergen,

    Agreed. JAX-RPC is not that bad. Packaging could be improved. I also like Caucho's Burlap and Hessein. Nice and simple. SOAP is quickly becoming not so simple.
  16. hi there,

    please note that SOAP, IIOP and JRMP are on-the-wire protocols, JAX-RPC is an API, and GLUE is a product.

    GLUE will shortly include a JAX-RPC "skin" that allows you to invoke web services using either the original GLUE APIs or the JAX-RPC APIs. this gives developers the best of both worlds.

    cheers,
    graham