I’ve been getting a lot of questions and comments about the article series (which is great, keep them coming). I got some questions from Brendan yesterday and it was clear that I really didn’t cover a very important part of the stub generation process. It’s not that I missed it; it’s just that I was primarily trying to demonstrate something and didn’t cover all of the background information you would need to use this process with your web services. 

In the example I’ve provided with this article series (Part 1 and Part 2), I’ve deliberately selected a base web service that’s simple enough to be easily consumed using the capabilities provided by JSR 172. Since the specification (yep, it’s not a ‘standard’ as was pointed out last week) was designed for mobile devices, its designers deliberately selected a limited number of data types it would support thinking that it would reduce the potential load on devices and cover a majority of implementations.

When I created the service, I created it with the knowledge that the Sun tools for creating the stub program only supported certain data types and I made sure I used them. The problem arises for those of you who want to build BlackBerry applications that consume web services that were not built with mobile users in mind. Let’s dig into the detail...

The specification for JSR 172 can be found here: JSR-00172 J2ME Web Services SpecificationJSR-00172 J2ME Web Services Specification. If you read through the final specification (on page 26) you will see that the spec only supports the following data types:

  • boolean
  • byte
  • short
  • int
  • long
  • float
  • double
  • String
  • complex types
  • arrays of primitive and complex types

 

That’s it, nothing more. Now, you can build more complex data types using the primitives listed there, but if your application uses custom data types that the stub generator doesn’t recognize, it just won’t work. This I think is the root of Brendan’s problems. Here’s a snip from the document that shows the supported data types.



So, if you’re presented with a web service that you want to consume and it uses data types that aren’t supported, what do you
do?  Well, you can:

  1. Ask the developer of the service to rewrite it using JSR 172-friendly data types
  2. See if there’s a RESTful version of the service available that you can talk to (bypassing JSR 172 all together)
  3. Create an intermediate web service that translates the incompatible data types to compatible data types
  4. Write your own SOAP handler to handle the unsupported data types
  5. Use third-party libraries such as kSOAP 2 to manage communication with the service
  6. Other options as appropriate (wouldn’t want to get poked for missing one)

 

It’s unlikely you’ll be able to get a developer to build you a new version of the service, but it’s possible. I’d suggest copious amounts of Mountain Dew and doughnuts applied liberally. 

You could use REST as a way to do this, assuming there was a RESTful version available, but since we’re talking about SOAP-based web services it’s probably reasonable to assume if there was a RESTful version available that you’d be using it and not reading my articles.
The most common solution in my experience is to create a wrapper service that makes the translation between the data types for you. There’s a Design PatternDesign Pattern for this and a Wrapper/Adaptor patternWrapper/Adaptor pattern to make it easy.  What happens then is you build the wrapper service to accommodate your needs here. The wrapper service exposes supported data types for the stub generator and behind the scenes, calls the original web service on your application’s behalf.

This method works even if you’re consuming a web service provided by someone else (some other organization). It shouldn’t care that you’re consuming their service from a service – that’s the whole beauty of web services – they’re designed to be chained together and consumed in different ways.

Anyway, that’s all I have for this installment. I know you’re expecting me to show you how to do this, but it’s really not the focus of this series – I’m merely trying to demonstrate how a Domino developer can expose Domino web services to a BlackBerry Java application. I’m sure there are a bunch of examples out there of how to use the Wrapper design pattern.

I still have to write the article on how to write the Java application that talks to the web service. I’d planned to write that article today, but thought Brendan’s predicament was a good one to address.  I should get the next article done pretty soon. I found out that I have to start looking for a new job  last week (more on that later) so I’m a little distracted, but I should be able to wrap up this series pretty soon. Stay tuned!

If you have questions, feel free to buy a copy of my BlackBerry Development book :-) then send off an email to me with your question using the ‘Contact me’ link on the left.

Overall Rating (0)

0 out of 5 stars

Post comment as a guest

Attachments

Location

Share:
Rate this article :
0
  • No comments found