aspose file tools*
The moose likes Web Services and the fly likes Design Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Web Services
Bookmark "Design" Watch "Design" New topic
Author

Design

Joe Pardi
Ranch Hand

Joined: Oct 03, 2001
Posts: 47
My group has extensive experience with XML, but are new to Web Services. We've been tasked to expose 10 or so API's so that our business partners (banks) can call them over the Internet. Sounds like some Web Services.
We've come up with three options to do this.
1. Expose each API as its own Web Service. We will hand author the WSDL since we need maximum interoperability since our partners are on a wide set of platforms. We like this approach since it makes the most of the whole WS frameworks and tools, but are worried about interoperability problems and other things such as versioning.
2. Use a Command pattern. Expose only one API (.execute) as a Web Service in which all calls are made. execute() will take 1 parameter, a String that will be an XML document and return a String (again, an XML document). This neutralizes the WSDL versioning and also any potential interoperability issues.
3. Just use XML over HTTP/Servlets. Surely will work, but not too sexy.

Any suggestions / thoughts on the options? One thing that would be nice would be to reduce the amount of XML parsing code that our business partners would need to write.
- Joe
Howard Kushner
author
Ranch Hand

Joined: Sep 19, 2003
Posts: 361
Hello Joe,
  • What tooling are you using? I am partial to WebSphere.
  • Granularity is important. That said, you can expose a stateless session EJB wth multiple methods, to perform a related set of tasks. You write WSDL by hand? That is not strictly necessary for interoperability, but that may be the limitations of your tooling.
  • Command pattern is cool.
  • Parsing ain't so bad, but you do have choices, so without getting too deep too quick, the is the Remote Procedure Call RPC approach and the Document approach. If you need to exchange Documents with your partners then you probably have to parse, and if you can settle for an RPC then you probably don't have to do the parsing since your endpoint will do that for you. And it may still wind up that your tooling will have some bearing on your decisions.


  • Wishing you much success. I just finished teaching Web Services at Wachovia Bank in Charlotte, North Carolina, and also teach the IBM courses as well since my company is an IBM partner. I suppose you could say that my interest in Web Services is intense.
    [ November 08, 2003: Message edited by: Howard Kushner ]

    Howard Kushner<br />IBM Certified Enterprise Developer - WebSphere Studio Application Developer V5.0<br />IBM Certified Advanced System Administrator - WebSphere Application Server V5.0<br />IBM Certified Solution Developer - Web Services with WebSphere Studio V5.1<br /><a href="http://www.amazon.com/exec/obidos/tg/detail/-/1931182108/" target="_blank" rel="nofollow">Developing J2EE Applications with WebSphere Studio</a> my Certification Study Guide for IBM Test 287
    Kyle Brown
    author
    Ranch Hand

    Joined: Aug 10, 2001
    Posts: 3892
        
        5
    Originally posted by Joe Pardi:
    My group has extensive experience with XML, but are new to Web Services. We've been tasked to expose 10 or so API's so that our business partners (banks) can call them over the Internet. Sounds like some Web Services.
    We've come up with three options to do this.
    1. Expose each API as its own Web Service. We will hand author the WSDL since we need maximum interoperability since our partners are on a wide set of platforms. We like this approach since it makes the most of the whole WS frameworks and tools, but are worried about interoperability problems and other things such as versioning.

    This is the best option by far. By the way, there's a definition issue here. A "Web Service" is described by the WSDL document. If you have 10 API's you have one Web Service if they are all contained in the WSDL document.
    You are right that this fits best with the tools on all platforms. So long as your WSDL is compliant with the rules defined in the WS-I Basic profile (www.ws-i.org) you should be fine with most interoperability issues. My advice to you is DO NOT GET FANCY. Follow the WS-I profile slavishly.
    However, you are right that versioning will always be with you in this approach. However, it's STILL there in the other approaches as you will see...

    2. Use a Command pattern. Expose only one API (.execute) as a Web Service in which all calls are made. execute() will take 1 parameter, a String that will be an XML document and return a String (again, an XML document). This neutralizes the WSDL versioning and also any potential interoperability issues.

    Cool In Java. LOUSY in Web Services. So you'd have one API that takes an xsd:Any, huh? Rotten idea. Now you've put it in the hands of the clients to generate the valid XML documents. If you wanted to avoid having to expose your client programmers to that, you've missed the boat. Now the XML encoding rules are in the hands of the developer, not the tools, and I'll guarantee that the number of mistakes will go up.
    Also, versioning is STILL an issue here. Just processing raw XML does not solve that problem. Think about it. Your XML changes -- they still have to change their XML generation and parsing code to deal with that, unless it's a "trivial" change like an add of a new optional document. If you change the structure of a message, their code must change since their parsing/generation code expects the XML to meet a certain structure.

    3. Just use XML over HTTP/Servlets. Surely will work, but not too sexy.

    Really bad idea. Now you've put even more onus on your clients, and you're not even attempting to follow a standard.

    Any suggestions / thoughts on the options? One thing that would be nice would be to reduce the amount of XML parsing code that our business partners would need to write.
    - Joe

    Kyle


    Kyle Brown, Author of Persistence in the Enterprise and Enterprise Java Programming with IBM Websphere, 2nd Edition
    See my homepage at http://www.kyle-brown.com/ for other WebSphere information.
    Joe Pardi
    Ranch Hand

    Joined: Oct 03, 2001
    Posts: 47
    Thanks for the replies. Some additional info / thoughts:
    - As for tooling, we're an IBM shop. So it's WAS 5.0.2 and WSAD. Most developers are using WSAD 5.0.x, but those writing these API's will use 5.1 since we understand it to be JSR 109 compliant. We don't have a solid grasp on the tooling of our business partners, but we know there are lots of platforms in the mix (Windows, HP/UX, Solaris, Tandem, MVS, Linux). On our side, we anticipate fully testing for .Net and J2EE web service clients.
    - The majority (75%) of these API's are also currently offered via a FTP-type batch file exchange. We currently allow our customers an option to send and receive XML files. In this regard, we have lots of XSD's and SAX parsing logic for the business entities.
    - I understand what you mean regarding the versioning. We will definitely be faced with XSD versioning anyway because of our batch interface. But the thought was that Web Service versioning would add an additional layer to that picture. We saw the need to supply versioned WSDL files, JavaBeans or EJB's, etc.
    - Also with respect to the existing XDS schemas, another goal would be to reuse the schemas (as much as possible). Not sure how feasible this would be with the WSDL since the existing XSD's were not designed with Web Services in mind. Didn't see it as easy as importing the definitions in the type section of the WSDL.
    - If you could, please expand on what you see as an issue on the encoding piece. In option 2 that was mentioned, the parameter and return type would be String, not Any, no? Where is the encoding complexity coming into play. I will mention that we do need to exchange TIFF images in some of the messages.
    - Oh, we anticpiate these being purely RPC type services. No one-ways or async stuff. Not wure about RPC vs. Document yet. I was leaning more toward Document style given its flexibility.
    Thanks for the feedback and advice.
    P.S. Kyle, since you're with IBM, an chance you know Kerry Holly, Stu Lipshires, Dave Jones (COE), or Paul Glezen (COE)? Just curious ...
    Kyle Brown
    author
    Ranch Hand

    Joined: Aug 10, 2001
    Posts: 3892
        
        5
    Why yes, I do happen to know Kerry. In fact we just had lunch together last week at the OOPSLA conference. If you'd like to follow up, a higher bandwidth mechanism would probably be a conference all. Ask Kerry to set it up and I'd be happy to participate.
    Kyle
    Joe Pardi
    Ranch Hand

    Joined: Oct 03, 2001
    Posts: 47
    Kyle,
    Had a discussion today with a certain individual that is directly paired up with Kerry in helping our company define a Web Services strategy. The work is primarily strategic in nature, and they are looking towards my project to use a reference implementation.
    In pairing the efforts up, it was recognized that we'd like to get access to some IBM'ers that had a little more practical experience with Web Services as to tap into some best practices.
    So I mentioned your name as a potential to provide some consulting. Not too sure if it will materialize given your schedule, but now you'll know where this comes from if it actually occurs.
    P.S. I work for a large credit card company based in San Francisco.
    - Joe
    Kyle Brown
    author
    Ranch Hand

    Joined: Aug 10, 2001
    Posts: 3892
        
        5
    Originally posted by Joe Pardi:
    Kyle,
    Had a discussion today with a certain individual that is directly paired up with Kerry in helping our company define a Web Services strategy. The work is primarily strategic in nature, and they are looking towards my project to use a reference implementation.
    In pairing the efforts up, it was recognized that we'd like to get access to some IBM'ers that had a little more practical experience with Web Services as to tap into some best practices.
    So I mentioned your name as a potential to provide some consulting. Not too sure if it will materialize given your schedule, but now you'll know where this comes from if it actually occurs.
    P.S. I work for a large credit card company based in San Francisco.
    - Joe

    Oh, and I wonder who that might be... I was out there doing a review on an app along with Kerry and a group from IGS and the High Volume Websites team last year about this time...
    Kyle
     
    Consider Paul's rocket mass heater.
     
    subject: Design