Just another (occasional) brain dump on technology and the technology industry...
About Me
- ax/
- I enjoy wine, laptops, walks, bicycling with the kids and long drives. I am constanly reading. In my heart I am a teacher a salesman and a technologist.
Friday, September 19, 2008
Rolodex - Interface Based Programming
Monday, September 15, 2008
The KreditInform "Web Service" and I
- Ease of use - not very easy, documentation sucks.
- Standards compliant - they call it a web service, which it is in the loosest terms. It is not WS-I compliant. I went to see a developer. There are no plans to change the current implementation to be WS-I compliant.
- Did I get it to work? Yes.
- Was it easy and intuitive. No way - be prepared to suffer!
Saturday, August 30, 2008
Introducing the Rolodex
According to
The Rolodex was invented by Arnold Neustadter in 1958...."
Why is a Rolodex interesting?
A Rolodex makes for a great example of a physical device that can be implemented as software. When one looks at it closely one can easily identify object-oriented principles.
- Abstraction - a person is a contact.
- Association (or composition or aggregation) - a person works for an organization, a person has given names and so on.
- Polymorphism - a contact's string representation will look different depending on whether the contact is a person or an organization.
What goes into a Rolodex?
A Rolodex stores contact information. A contact can have a couple of telephone numbers, email addresses and addresses. A contact may be a person or an organization. A person has given names, a family name, a gender and a birth date. An organization has a name. A person may be associated with an organization. An organization may have many employees.
What can one do with a Rolodex?
You can add, remove, find and edit contacts. You can also add, remove, edit and find telephone numbers, email addresses and addresses for contacts. You my want to update a person or an organization's information from time to time.
Why did I describe the Rolodex?
Because I want to show how to implement a software solution that can take the place of a Rolodex. Over the next couple of weeks I want to show how you will go about implementing the Rolodex mainly using Java technology. I will cover the following topics:
- Rolodex's interfaces.
- Persisting Rolodex entities in an XML file using JSE technologies.
- Persisting Rolodex entities in a relational database via JPA using JSE technologies.
- Accessing Rolodex functionality as JEE components.
- Exposing the Rolodex as a Web Service.
- Exposing the Rolodex via JSF.
- Exposing the Rolodex via SEAM and,
- using .NET and web services technologies to expose the Rolodex as a .NET client.
Monday, March 03, 2008
Sun MySQL. Wow!
I do a lot of work in the JEE space. Big Blue is pervasive. I have to put up with their technology. It is trash mostly, but sometimes they have a real gem or two in their product stack, like DB2 and MQ. AIX is ok, like it is ok to have any old car instead of walking everywhere. WebSphere is a nasty piece of work.
I really like BEA's product stack. I think that it is excellent in almost all cases. Oracle is the worlds most deployed database and for what reason I do not know. I wonder how that is going to pan out?
I started playing with the Sun Application server 9.0 a while back. I immediately loved it. I still do. In my opinion it is the best AS out there. 9.1 is even better! I also have high regard for MySQL. It looks as if Jonathan Schwartz is doing great things with Sun, I have a good feeling that he will do awesome things with MySQL.
Happy coding...
Friday, February 15, 2008
SOAP With Attachments in Java CAPS, Client
The code is as follows:
|
I used tcpmon to redirect the call to the appropriate destination to see the payload on the wire.
Have fun!
Thursday, February 07, 2008
SOAP With Attachments in Java CAPS
I figured that the SOAP with Attachments API for Java (SAAJ) would be a good place to start. I looked through the API documentation and found that I will need a byte array and the SOAP message's MIME headers to create a SOAP message using SAAJ. All I needed to do was to expose the HTTPServer's processRequest as a JCD.
Here is the implementation:
|
unmarshallSOAPMessage on line 59 shows how to reconstruct the incoming SOAP message from the WebApplication's byte array and HeaderList. The rest is fairly obvious. sendResponse on line 198 shows how to pump a newly created SOAP message back over the wire.
That covers SwA server functionality within Java CAPS. I will show the client side code in a next blog.
Tuesday, November 22, 2005
XML to POJO and back. Horses for courses.
Of the utilities I've mentioned before JAXB and XMLBeans are a notable example of the XML Schema to POJO route. I feed a compiler a schema and it spits out POJOs. So if you are given a schema, go fry your brains with one of these tools. Real easy. Because you work from the schema to a Java representation the content and format of the Java classes created from the schema are out of your hands. It means that if you get an ugly, badly designed schema, you'll end up with ugly, non-intuitive Java. In that case you might have to use a second round of transformations like dozering or hand-written Java to Java transformation. You also have to write schema-centric or XML-centric application code. You are constantly remided that there is a document at stake somewhere. Now what can I say about JAXB and XMLBeans - "XML Schema to Java in 60 seconds" I guess...
Jovolution is somewhat different from the other utilities in that it is part of a high-performance, realtime Java library. So you write your Java code first. You can then add your Java to XML serialization and XML to Java deserialization code. It allows you to produce XML that are more element centric or more attribute centric - depending on your mood or your boss' mood. It is relatively easy to use once you've figured it out. Fortunately there is an eclipse plug-in that makes your life a whole lot easier - that is if you use eclipse of course (why wouldn't you). Don't use Javolution if you have a schema somewhere that the XML needs to adhere to, you'll get depressed and stressed and might suffer a nervous breakdown... What will be a nice catch phrase for Javolution - "kickass performance after you've figured it out". The figuring is the hard part...
If you have Java and want to go to XML you can also use XStream. Boy what a pleasure. Easy as pie. Five lines of code. Really, really easy. Did you get that, simple as sneeze! You do not have a great deal of power to configure what your XML will look like but hey, who cares, with this ease of use who wants to specify in great detail what the XML is produce should look like. Ok, so now we've covered the "extremes" if I may say so - schema driven XML to POJO or Java driven POJO to XML code.
JiBX allows you complete control over the mapping of XML to Java (or Java to XML). Its flexibility may come at a price. You can end up with XML and POJOs that at face value does not look the same. You will also have to work with a mapping compiler and such. From a Java point of view it is totally non-intrusive. Nowhere in your Java will you ever know about the underlying XML (except of course in your marshaler, unmarshaler service). It also has nice functionality like having binding specifications of different versions, so if you want to provide XML for Bob, use your Bob mapping and if you want to provide XML for Sue use your Sue mapping. Very nice. What can I say about JiBX - I guess "hard work, great rewards" sums it up best. Oh yeah, forget the schema - unless you want to use some of the tools supplied with JiBX...