• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Portable J2EE 1.4 Web Services?

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd appreciate some advice from anyone who has had to develop Java-based web services that can be deployed on a wide range of J2EE Application Servers.

I'm using a WSDL-first approach with document/literal WS-Basic Profile style services, because interoperability is important to us.

My chosen approach has been to auto-generate the JAX-RPC mapping files and interface and value types using JWSDP (not sure which version to use, I've tried 1.3, 1.5 and 1.6?).

However when I test my initial code on a range of Application Servers (ones that don't need additional vendor-specific descriptors), they all fail with *different* errors, all resulting from the WSDL, JAX-RPC mapping or interface/value types.

Am I taking the wrong approach? Am I better writing the mapping files and types by hand (something I'd like to avoid)?

All articles on this subject mention use of using vendor-specific tools on each platform (e.g. the recent IBM developer works article). This would mean we would have to create a different application distro per vendor, which again we'd like to avoid?
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The generated classes generally depend on other tool-specific classes. One option would be to use a tool (like Axis) for which all the required libraries can be shipped along with the client classes.
 
Chris Nappin
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the suggestion.

I'm using the JSWDP "wscompile" Ant task in "import" mode, i.e. it just generates the interfaces and value types rather than full Stubs which aren't portable. The interafaces and value types only depend on the JAX-RPC 1.1 library.

I'm not using Axis (even though I'm much more familiar with Axis) because I know from personal experience that it's very difficult to get Axis working on some app servers (e.g. ones that don't allow overriding the default XML parser or Web Service implementation).
 
Ulf Dittmer
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So if the interfaces and value objects only depend on the JAX-RPC library, what errors are you getting? Are there different versions of JAX-RPC on the different servers?
 
Chris Nappin
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
They are all "J2EE 1.4 certified" app servers, so they must contain a compatible JAX-RPC 1.1 implementation.

WebLogic 9.2 threw errors about parsing the WSDL (no element name found, even though I don't have any elements without names in the WSDL?).

Oracle 10gAS threw errors on the Exception class generated by wscompile (that map to the SOAP fault in the WSDL) - it expects a no-arguments constructor and a setter even though Exceptions are usually immutable in Java.

JBoss 4.0.2 threw errors on the JAX-RPC mapping. JBoss 4.0.4 with JbossWS 1.0.2 threw other errors related to the XML Schema bindings.

Obviously I can progress each issue with the specific vendor. The thing that concerned me is that these are all "J2EE 1.4 compliant" servers, my WSDL has been validated by various tools as "WS-Basic profile compliant", and I'm auto-generated JAX-RPC 1.1 compliant code. Yet so many issues?
 
Chris Nappin
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
OK, maybe this thread is turning into an uninteresting rant rather then a useful discussion. I'll try to get it back on track...

Feedback from JBoss is that they are very keen for the service to use the "Doc/Literal wrapped" convention. Looking at the JAX-RPC spec I'd like to use the "wrapped" approach to simplify the parameters and return types of my services at a Java level.

Is anyone aware whether this approach is widely supported by the various J2EE vendors? Would this help my service be more portable?
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Chris Nappin:
I'd appreciate some advice from anyone who has had to develop Java-based web services that can be deployed on a wide range of J2EE Application Servers. I'm using a WSDL-first approach with document/literal WS-Basic Profile style services, because interoperability is important to us.


In my judgment the problem is that you are trying to solve two entirely different problems with one joint solution and the existence of that joint solution may not even be mandated by the J2EE/JAX-RPC spec. You are looking for:
  • A web service component that is deployable on all J2EE servers.
  • A web service that is interoperable.


  • Both of these goals do not necessarily meet. Using document-literal, WSDL-first approach (which includes designing the exchanged XML-document (schemas)) is a great step towards interoperability - at the web service interface level. However there is nothing in the J2EE / JAX-RPC spec that will ultimately force identical Java-to-XML and XML-to-Java translations to be generated by all the different tools that are associated with the different application servers - yes, there are some basic rules that have to be followed, but as your XML-documents become more complex the generated Java-equivalents will begin to diverge. Basically the J2EE/JAX-RPC spec gives each application server the tools to deal with "interoperable web service definitions" but there is no guarantee that each of these application servers will use the facilities in exactly the same way.
    So if in fact you do actually need a web service component that is deployable on all J2EE servers, that has one unified Java interface, then you will need to find one tool that generates output that can be accommodated by all the application servers - rather than using each of the application server's own tools. This may very well lead you down the path writing your own servlet that is your web service component, that obeys your WSDLs and XSDs. You may be able to use JAXB for the (common) generated Java-to-XML and XML-to-Java Mappings, and you may be able to find a SOAP-library to support you in all things SOAP. All-in-all it may be a bit of work to meet your goal of a generally deployable web service component that obeys an interoperable web service contract.
    [ August 09, 2006: Message edited by: Peer Reynders ]
     
    author and deputy
    Posts: 3150
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Peer Reynders:

  • A web service component that is deployable on all J2EE servers.
  • A web service that is interoperable.



  • Hi Chris
    With an endless fight between web service interoperability and specifications, i would stick with Ulf's suggesstion here.
    Many b2c, b2b sites have started shipping their own light-weight client packages(the popular ones were for java and .net and sometimes php).
     
    Chris Nappin
    Ranch Hand
    Posts: 36
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks to Peer for your recent reply to my attempt to re-open this discussion, and for your previous lengthy reply which I didn't see at the time.

    As for JSE 6, I'm afraid we need to develop this product now, not in a couple of years time! We're only just looking into the possibility of moving to JSE 5.

    Your previous lengthy reply suggests that the world of Java Web Services is a lot less mature than I had hoped. Implementing my own Web Services stack is not a realistic option for us, neither is embedding a standard implementation (e.g. Axis, XFire etc) because of Application Server classpath clashes. The lack of replies from anyone else that has managed to achieve this makes me think I'm breaking new ground, which I'm sure I'm not?

    > So if in fact you do actually need a web service component that is
    > deployable on all J2EE servers, that has one unified Java interface,
    > then you will need to find one tool that generates output that can be
    > accommodated by all the application servers

    That's why I am using Sun JWSDP. In "interface-only" mode, it generates Java code that only depends on the JAX-RPC 1.1 classes, so is completely portable (at least that's the theory!).

    As I haven't been able to find a solution to the WebLogic-specific issue of supporting "unwrapped" services, I've reverted back to using JWSDP in "wrapped" mode. This approach is portable accross JBoss 4.0.4 (with JBossWS), BEA WebLogic 9.2 and Sun App Server 9. I'm currently trying to resolve an issue with Oracle on 10gAS.

    Once I get all this working, if this really is breaking new ground, perhaps I should publish an article with the details?
    [ October 26, 2006: Message edited by: Chris Nappin ]
     
    reply
      Bookmark Topic Watch Topic
    • New Topic