My poor head. The day before yesterday it was Java. Yesterday it was Java and C++. Today it’s C++, Java and Ruby! But today’s language soup is down to SOAP and its evil sidekick WSDL. It’s great when it works. You can just run Axis2 over the WSDL to generate your beans and off you go but today I have a major headache with the library system at $WORK. I’m looking into plumbing it in to the account creation system and it has a nice SOAP interface, which doesn’t conform to WS-I. It uses RPC/Encoded. That’s ok as Axis2 supports it now but the WSDL itself is “broken”:
[java] Caused by: org.apache.axis2.AxisFault: Part 'fault' of fault message
must be defined with 'element=QName' and not 'type=QName' (more...)
I’ve been playing around with Zoto and Facebook, using Zoto’s XML-RPC service. They give a Python example on the developers’ page but I couldn’t get it to work, so I dug out some old Java XML-RPC code I had and tried that instead. It worked just fine. Then I had an idea. I did a quick Google, in fact I did 4 googles: (more…)
I was accessing the Fedora API-A web services using XMLBeans that I’d created from the WSDL (more on that later) but I kept getting weird errors: (more…)
With the expected influx of new applications to build our emerging Web2.0 structure, more and more demans will be placed on the existing structural provisioning framework. We’re planning trials of Elgg and Sakai, linked via Shibbleth but the current Just In Time Provisioning (JITP) model doesn’t fit with how tutors use these types of applications. So I’ve published my vision of the next generation provisioning framework for UHI. It utilises SOA, JBI and BPEL among other things.
You can read the document on our Confluence.
I’ve been writing some web services for the ASK project, which involve putting the CollectionManager interface online as a web service. As it’s rather large I thought I’d split up the WSDL into modular parts. Why create WSDL manually and not generate it from the implementation class? Well, the interface has method overrides in it, which aren’t allowed in WSDL2.0, so to keep on the right side of the standards, I modified the interface to remove the overrides and created the WSDL by hand. I could have just coded up a dummy impl class for the modified interface but the trend these days is to use WSDL as your API and to design from the ground up using WSDL. Plus it would be good to keep my WSDL skills sharp.
The following diagram shows what I did. There’s a root WSDL, which just defines the service name and location. It then imports the root XML schema that defines the WSDL message types. That in turn imports the domain XML schema for the ASK web service data objects. The root WSDL also imports the bindings from another WSDL file. The bindings file then imports the portTypes WSDL file, which in turn imports the messages WSDL file. So if I want to, say, offer the CollectionManager service over another type of protocol, I just have to import a different bindings file. If I want to change method signatures in the service, I just modify the messages types XML schema file.
Modular WSDL. Click on image for bigger size
When I ran it all through Axis2 wsdl2java, it blew up with the error:
org.apache.axis2.AxisFault: First Element must contain the local name, Envelope
So I put the whole lot into one WSDL file and it worked. I then went back to the modular WSDL and changed the way the XML schema were imported. The root WSDL imported both XML schema files, for the WSDL messages types and the ASK domain types. However, it transpired that the ASK domain types were not visible to the WSDL messages types and that’s what was causing the problem.
So I refactored by removing the ASK domain import from the root WSDL and importing it from the WSDL messages types schema instead.
Now it all works.
In the past I’ve had handshake exceptions when doing web services over SSL and at least you can fathom what’s going wrong, as handshake means, well, a handshake. Now, the crappiest error I’ve seen yet for SSL has appeared in Guanxi:
org.guanxi.common.GuanxiException: javax.net.ssl.SSLException: java.lang.RuntimeException: Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
I traced the problem to a bug in the Guanxi Guard that only manifests itself when the Engine and a Guard are running in the same webapp. The Guard probes for the Engine’s certificate then marks it in the servlet context. However, the Guard uses its own ID as the marker. The Engine uses the Guard ID as a marker too. So the problem occurred when the Engine’s WAYFLocation service tried to connect to the Guard’s verifier service over SSL. As the Guard had already marked the wrong entity in the servlet context, the Engine thought it had already probed for the Guard’s certificate. It hadn’t, as it had been fooled by the Guard setting the wrong ID in the servlet context.
So the exception was caused by the Guard’s certificate not being in the Engine’s truststore.
With all the tinkering I’ve been doing with Axis2 and only using trunk builds as I need my xsdconfig support, I get this error now and again when a client is calling a service:
AxisFault: “ServiceClass does not implement required method of the form OMElement”
The problem is the client and service are built using Axis2 trunk but the actual web application in which Axis2 is embedded is running Axis2 1.1.1
Upgrading the web application to Axis2 trunk sorts it. Hopefully this error will disappear once the next version of Axis2 comes out, with my xsdconfig patch.
I’ve been using Axis2 in the ASK web services and as I love XMLBeans, I use that data binding. So when I design the WSDL I include all the domain type definitions and I’ve got an instantly useable set of web services that work in the ASK domain model. Well, almost useable. I still have to implement the skeletons.
I’m also writing an Axis2 tutorial and one thing I found was that Axis2 wsdl2java didn’t support xsdconfig files when using the XMLBeans data binding. So I added it and submitted the patches. It was a case of extending Axis2′s XMLBeans code generator to support the BindingConfig methods:
- lookupJavaNameForQName(QName name)
- lookupPackageForNamespace(String uri)
and adding a new XSDConfig class that parses the xsdconfig file and stores the mappings in an easy format to let the Axis2 XMLBeans code generator get them.
I’ve added two new options to wsdl2java:
- -xsdconfig FULL_PATH_TO_XSDCONFIG_FILE
- -xc FULL_PATH_TO_XSDCONFIG_FILE
i.e. there is a long and a short option, in keeping with other wsdl2java options.
So now I have xsdconfig support in Axis2 and I can get on with my tutorial. For the moment it can only be used if you download from trunk but it should be in the next release after 1.1.1.
Following on from the previous post, I’ve decided to get into the spirit of the web services and SOA revolution and rename my blog. It’s been the cakeBlog from the start but the name is getting a bit long in the tooth and I don’t eat a lot of cakes now anyway. Why did I? Read this post.
So what’s the new name? Well, if you read the previous post you’ll see I’ve found mashups to be very useful indeed, especially the ones favoured by rollnecks, i.e. the ones devoid of XML. It was the word recombination that did it for me. My eyes were opened and I discovered a rich seam of analogies with atomic physics that could be mined to describe mashups and web services.
Basically what one must do to join the mashup/SOA revolution is analyse your information output, how it’s displayed, how it’s generated, where it’s content is stored. Are you reinventing the wheel? Then use mashups.
Ionise your information.
Join the SOA revolution by putting your information in a particle accelerator and smashing it against the wall. See what the fragments are. Gather those fragments and turn them into web services. Go shopping for better versions of the ones you’ve identified, then recombine the final set of services with your original, streamlined information.
I’ve done this with my blog, using webcam services from other sites and weather information parser services I’ve written myself. The dashboard of my blog uses information services from wordpress.org.
My blog has been ionised.
Welcome to the ionisationBlog.
I was reading this interesting article from OCLC on mashups, where they’ve included the content of external “web services” into their library web pages. The term they use is “recombination” and as you can see from Wikipedia the more familar term, for me as a Physics graduate anyway, is:
“recombination refers to an electron becoming bonded with an ionized atom”.
In the case of mashups, the web page is the ionized atom and each web service whose output the page consumes is an electron. Now I understand mashups! In fact, I’ve even been using them on this blog, with the webcam images and weather information. All those “electrons” are recombining with my ionized blog to make it more feature rich. And all without a hint of SOAP, XML, Axis or SAML. Wonderful! I’m seriously thinking of renaming my blog along the lines of this epiphany. So watch this space.
Another example of a mashup is over on my eBothy blog. I’ve “recombined” one of my videos from youtube using their embeddable player. You just copy/paste the HTML they give you when you upload a video and you can play the video from any web page. Again without any sign of XML.
The atomic physics analogy is great for understanding web service granularity. Electrons are fundamental particles. They have no structure and so are standalone entities in the web services world. However, other fundamental particles are Quarks and they can be used to build bigger entities. So you can see where I’m heading with web services granularity.
A web service that just reverses a word sent to it would be an electron type service. It just does it’s work within it’s own structure. It doesn’t need to use the services of other web services.
A web service that verifies a credit card would have lots more structure though. It would take the credit card information and use the services of other financial type web services to make a decision.
There are lots of analogies I could start drawing with the particle physics world and that’s just what I’m off to do. And to think of a new name for my blog.