Next Challenge: Serializing Blobs

So, I’ve successfully implemented a couple of WS operations, but both of them return pretty simple data types.   I used the “Start from Java” method using annotations and such.  Now I have a different scenario:  a Blob return type.  I tried wrapping it a different class…nope.  I always get an exception during the serialization/marshalling process.

exception message:

javax.xml.bind.JAXBException: class oracle.sql.BLOB nor any of its super class is known to this context.

I suspect it has to do with java.sql.Blob being an interface, but I’m not sure how to solve this problem.  My reading on the subject leads me to believe that the “Start from Java” development model may not handle certain types very well (more support for the “Start from WSDL and Java” model).  Here’s the code for my wrapper class that doesn’t do the trick:

 Failed Blob Adapter Code (fig. 1.4)

And the journey continues!

Proper Mapping Annotations: A Step in the right direction?

Quick recap

Last Friday…10 minutes till quitting time, I come across some info on “Mapping Annotation”. I’ve been using the @XMLElement annotation for most of my bean properties, and sometimes they work…but not in this one particular bean. (yes, I’d been taking the Java to XML approach) First, you have to understand how I was using this annotation. My bean code looked like this:

Bean Code (Fig 1.1)

Now, at some point, it seemed necessary to use a wrapper class so that I could return an Array of these beans. So a built this little guy:

Bean Array Wrapper (fig 1.2)
Although this strategy was successful in another case, it failed at deserialization in the web service client application. Here’s a little bit of …

NEWS BREAK…I INTERRUPT THIS BLOG TO BRING YOU THIS IMPORTANT AND PERHAPS MEANINGLESS INFORMATION

ARRRRGG!!! In an attempt to reconstruct this crime scene, my old code worked! This is very frustrating. I was going to give you this cool little post about how I solved my little problem by adding the “name” attribute to the @XMLElement annotation, but when I removed the name attribute, redeployed to Glassfish, regenerated/recompiled/redeployed my client…it $@$%ING WORKED!

Despite this confusion, I believe I will continue annotating my bean properties like this:

@XMLElement with name property for better mapping (fig. 1.3)

…because it got things working.

Glimmer of hope for my Serialization issue!

I’m seeing my first glimmer of hope in solving my serialization/mapping issues mentioned in my previous post “First Major issue to tackle:  Serialization”.

The Static WSDL feature of the JAX-WS toolset promises the capability “for you to publish WSDL based on existing schemas (e.g., your existing po:purchaseOrder element definition) rather than JAXB-generated types.”  (SOA Using Web Service, Mark Hansen, p. 45)

This is a technique for the “Start from WSDL and Java” development model mentioned in the previous post.

Development Models – Be a fundamentalist?

I may be a tree-hugging, new-age, liberal, United Methodist, but when it comes to computer programming I’m a hard-core, right-wing fundamentalist…or at least I used to be. It really all goes back to my early days of little league baseball. My dad was the coach and his coaching model put a heavy emphasis on the fundamentals of the game: throwing, catching, and hitting. Everyone played and everyone had fun. We were never the best and we were never the worst. While other teams recruited talent, played talent, threw curve balls, and benched liabilities, we were getting a thorough schooling in the fundamentals of the game. These values really informed my approach to learning java. I’ve taken 4 courses on the fundamentals of java and I would take another if I had the chance. My experience is that the “advanced” stuff comes easier if you have a strong foundation to build on.

So, why have I become such a backslider these days? As I’ve mentioned, Netbeans has really made things easy. Netbeans has become my new tech religion. Why should I trudge through the ‘Old Testament’ of java when the Messiah has come with the ‘Good News’ of wizards, debuggers, code editors, and powerful drag-and-drop graphical abstractions? I’m SAVED! Praise Netbeans! Hallelujah! But like with any religion, some unprecedented issue comes up, and it is no longer clear which way to turn. We have to go back to the source to find the answers.

And so, I’m grateful to Mark Hansen for reminding me to get back to the fundamentals when it comes to JWS Development models.

He presents three models:

  1. Start from Java – “assumes that you create a Web service by starting with the development of a Java class”
  2. Start from WSDL – “you take a preexisting WSDL and use a WSDL compiler…to generate a set of Java program elements that implement the WSDL”
  3. Start from WSDL and Java -”you reference a preexisting WSDL from the @WebService annotation on the Java class intended to implement it. The annotations on this class must map the class to the referenced WSDL.”

Does one of these three options seem a little (or a lot) more complicated than the others? If you chose #3, then your with me, and Mr. Hansen. But let’s face it, folks, life is complicated. So much of what we do as programmers involves integrating existing systems. We spent the last 10 years developing all these great systems, and now we’re expected to get them to talk to each other. The promise of SOA is that our existing systems can benefit from other existing systems by consuming their web services. How often, practically speaking, will we get to write the WSDL for someone else’s system, and how often will they be able to fully anticipate the data models for our system? #3 is about the real-world work of mapping data models from one system to the data models of another system. Hansen contends that there is no silver bullet yet for doing this. The current tools do not do this work for you. No special compilers or generators.  You have to really understand WSDL mapping fundamentals to make #3 work.  He writes,

“Precisely because of the difficulties it presents to the JWS tools, I feel strongly that the best way to understand Web Services development and deployment is to assume that you have existing WSDL and Java artifacts to work with. As a developer, if you learn to solve “Start with WSDL and Java” problems, the other two development modes are much easier to deal with.”

I’d been attempting the “Starting with Java” approach because it seemed like I wouldn’t have to learn all this WSDL junk.  Netbeans w some success, but when problems arose, I found that I was ill-equipped to solve them. So….it’s back to the fundamentals for me!

First major issue I’m hoping to tackle: Serialization

The central idea behind Java Web Services (JWS) is the serialization of java classes into XML schemas and the deserialization of XML schemas into java classes. This is really cool…theoretically. The issue (I’m reserving the word “problem” at this point for later) I’m encountering is that the class going in is often different than the class coming out. It’s like some funky Willy Wonka version of serialization. Sure it’s really cool that Wonka can teleport a chocolate bar, but how practical is it that the chocolate bar is about a 1/4 ton to begin with and is only 3 ounces coming out?! wonkavisionThe deserialized version of the java class is indeed wonky (weird method name morphs, Lists that turn into arrays, or just a bunch of errors)…at least the way I’m doing it. Of course, if I knew what the hell I was doing I wouldn’t be having to actually LEARN this crap! At least when Mike Teevee got all stretched back out, he was looking at a brilliant career in the NBA!

The first hint in SOA Using Java Web Services (Mark D. Hansen) that Willy Wonka may have actually been on the JWS team is when he writes:

“One interesting point to make here is that only the [SOAP request/response] is specified by the WSDL. The Java method invocations at either end are completely arbitrary from a Web Services perspective. In fact, you have one Java method signature on the client side and a completely different method signature on the server side. In most cases, the method signatures are different…”

[WARNING: This portion of the blog you are reading is starting to resemble a rant]

I realize that in many cases, the client may be written in a different programming language than the service, but if they’re both written in Java shouldn’t they have the same method signatures?!! WTF?!!! He goes on to point out that if “both sides were working with the same Java class libraries, this invocation could occur via Java RMI”. Ummm…true, but what if one client is java and another is not? What if one java client doesn’t have the class libraries? Am I going to write handling for RMI and Web Services for the same business resources just because I can? I thought the whole point of this mess is so that I don’t have to distribute my class libraries! If I’m following the bean pattern and doing my annotations correctly, I expect the same tasty morsel to be delivered at my client’s doorstep, not a half-digested piece of crap! I want the serialization system to work like Pizza Hut delivery, not my lower intestine!

Dave Podnar’s Five Stages of Dealing with Web Services

Near the beginning of Hansen’s book he offers this helpful bit of wisdom from Dave Podnar.  I don’t know who Dave Podnar is, but I want to thank him for saving me from needing a checkup with my shrink! 

1. Denial – It’s Simple Object Access Protocol, right?

2. Over Involvement – OK, I’ll read the SOAP, WSDL, WS-I BP, JAX-RPC, SAAJ, JAX-P,… specs. Next, I’ll check the Wiki and finally follow an example showing service and client sides.

3. Anger – I can’t believe those #$%&*@s made it so difficult!

4. Guilt – Everyone is using Web Services, it must be me, I must be missing something.

5. Acceptance – It is what it is, Web Services aren’t simple or easy.

A little background…

Netbeans.  Love it!  I shed my text editors and command prompts about 3 years ago and I’ve never looked back.  And now my greatest fear about using an IDE has come true:  I’m a lazy, know-nothing, IDE-dependent programmer!   Ok, that was a little rough.  Nothing wrong with being an IDE-dependent programmer.  I’m more productive than ever now because of Netbeans…especially in my Swing programming!  But I’m becoming very comfortable (hence the lazy/know-nothing…or should I say learn-nothing).   So, I decided to switch my current project from having a Swing interface to a browser-based app using all this cool, shiny, new crap (JSF, AJAX, Spring, Hibernate, and…….Web Services).

Ok, well JSF is a bugger, but at least it does a lot of the heavy lifting for you.  IDE support is getting better every month.   Spring and Hibernate…I’ll be getting to that later, so I don’t want to comment on it, yet.  And then there’s Web Services.   Remember how hard it was to learn OOP, Java, Swing, and all that? (or maybe it was a walk in the park for you…not me).   Well, Web Services is like that.  It’s hard.

First I thought, “Netbeans has got my back.  I’m not going to have to learn SHIT!   Drag, drop, fill-in-the blank, and BAM…Web Services.  Hello World?  No problem.  What’s all the fuss?  This is easy.  First real-world web service?  A little Googling, a little reading, not easy, but it works.  I’ve got it.  I’m da MAN!   Second real-world web web service? RRRRRRRRRRR CrashHHHH!”

So I’m sitting here with SOA Using Java Web Services by Mark D. Hansen and it’s clear to me now that there is no short-cut here to mastering Java Web Services (JWS).  I’m just going to have to learn it.   REALLY learn it.  My goal is to learn this stuff and figure out how to do it with Netbeans so that I can forget it all over again….and I’ll write about it here!