One aspect I've looked at in the recent past was the ability to turn POJOs into XML back into POJOs. There are a myriad of utilities out there to do just that. JAXB, Javolution, XMLBeans, XStream, JiBX and many more. Granted, some of the utilities are way smarter than others and offer different levels of functionality. With some you have to write code in your POJO. Others work of XML Schemas, you feed some sort of compiler a schema and it spits out POJOa galore which you then access using factories and such.
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...
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.
Tuesday, November 22, 2005
Tuesday, October 11, 2005
Engineering in general
I am amazed at what the human mind is capable of conceiving. I am even more amazed that humans are able to do what they think, or want to do. The pyramids were built 2000 BCE, some say 10,000 BCE. Millions of cubic meters of rock, hundreds of millions of tones of rock. Countless laborers. It took hundreds(?) of years to complete - if you do not want to believe Egyptologists that is... If I stand back however, I see that it was not really that complex - yes, yes, I know that it is remarkable that the base layer of each pyramid is as good as absolutely flat and that each building block fits perfectly in place.
If we look at high rise buildings like the Petronas Towers or the Sears Tower or the not-any-more-but-still-awesome World Trade Centre more closely we will know that each one is a miracle on its own. We've grown so used to seeing them go up that our jaws don't drop anymore every time we see it happen. Even the most massive ones are not nearly as heavy as an average sized pyramid. It is essentially many a liter of concrete, many a kilometer of steel and sheet upon sheet of glass. And yet, we are astounded when buildings partially collapse (because of human error). How do we test the new building? Do we fill it up gradually from the bottom to the top and hope that it does not cave in? No. We go right ahead and put thousands of people in a building and know that it will stand!
The most astounding fact is that the technology to build massive buildings is much older that massive buildings itself - we had to wait for the escalator/elevator to be perfected to make sky scrapers practical!
When we see a massive dam like the Hoover, Itaipu or the not-yet-but-soon-to-be Three Gorges, holding back what will be approaching thousands of billions of liters of water what do we think - "Oooh, nice view! Let's go swim!". We do not even think that the dam might break and wash us down the river into a great ocean. We trust its walls.
Massive bridges like the Akashi Kaikyo, Millau Viaduct, Lake Pontchartrain Causeway or even the awe inspiring Firth of Forth that was built in the mid 1800's are common place. How does an engineer test a newly constructed bridge? Will she take her four year old, put him on his bicycle and hope that he reaches the other side? Will she then get in her small car and drive across the bridge and hope to reach the other side? Will she then get a fair sized truck to make the trip and look on in anguish as she prays to all the benevolent forces in the universe to protect the bridge? Will she then gamble with a mini rush hour volume of traffic? No! Cut the ribbon, drive!
We did not even touch on other amazing structures, inventions and consumables that just works. Like petrochemical plants, airliners, tunnels, massive ocean liners, space stations, ocean-bound exploration platforms, domes, busses, rockets, power plants of all sorts, the space shuttle and on and on and on...
What makes all of this possible? Mathematics. Physics. Chemistry - and the understanding and applications thereof. In all the mature engineering disciplines there is a solid foundation of mathematics together with interesting applications of mathematics - thermodynamics, strength of materials, static and dynamic forces and so on.
You also have a clear stratification in skill and ability in the mature engineering disciplines. At the foundation level you'll find pure mathematitians. They figure out stuff - stuff that not even they know the application of. On top of this foundation of pure mathematics you'll find people that can see the application of the clever stuff bubbling from beneath them, we'll call them the engineering scientists. Building on top of the engineering sciences you'll find types that can use all the tools handed up from the lower layer to build predictive models. These are your engineers. At the next level you'll find individuals that can take the models and draw designs, diagrams, schemas and plans and hand it off to other individuals that can correctly interpret the designs and such. At the next level you'll get the types that can say "Ok Bob, do this, that and the other!" - according to the plans etc. And right at the top sits Bob, someone that is relatively unskilled but hard working.
What do we have that even approach this in the software engineering field? Should we be arrogant enough to call software endeavors "engineering"? What are your thoughts? More on this in a later article.
If we look at high rise buildings like the Petronas Towers or the Sears Tower or the not-any-more-but-still-awesome World Trade Centre more closely we will know that each one is a miracle on its own. We've grown so used to seeing them go up that our jaws don't drop anymore every time we see it happen. Even the most massive ones are not nearly as heavy as an average sized pyramid. It is essentially many a liter of concrete, many a kilometer of steel and sheet upon sheet of glass. And yet, we are astounded when buildings partially collapse (because of human error). How do we test the new building? Do we fill it up gradually from the bottom to the top and hope that it does not cave in? No. We go right ahead and put thousands of people in a building and know that it will stand!
The most astounding fact is that the technology to build massive buildings is much older that massive buildings itself - we had to wait for the escalator/elevator to be perfected to make sky scrapers practical!
When we see a massive dam like the Hoover, Itaipu or the not-yet-but-soon-to-be Three Gorges, holding back what will be approaching thousands of billions of liters of water what do we think - "Oooh, nice view! Let's go swim!". We do not even think that the dam might break and wash us down the river into a great ocean. We trust its walls.
Massive bridges like the Akashi Kaikyo, Millau Viaduct, Lake Pontchartrain Causeway or even the awe inspiring Firth of Forth that was built in the mid 1800's are common place. How does an engineer test a newly constructed bridge? Will she take her four year old, put him on his bicycle and hope that he reaches the other side? Will she then get in her small car and drive across the bridge and hope to reach the other side? Will she then get a fair sized truck to make the trip and look on in anguish as she prays to all the benevolent forces in the universe to protect the bridge? Will she then gamble with a mini rush hour volume of traffic? No! Cut the ribbon, drive!
We did not even touch on other amazing structures, inventions and consumables that just works. Like petrochemical plants, airliners, tunnels, massive ocean liners, space stations, ocean-bound exploration platforms, domes, busses, rockets, power plants of all sorts, the space shuttle and on and on and on...
What makes all of this possible? Mathematics. Physics. Chemistry - and the understanding and applications thereof. In all the mature engineering disciplines there is a solid foundation of mathematics together with interesting applications of mathematics - thermodynamics, strength of materials, static and dynamic forces and so on.
You also have a clear stratification in skill and ability in the mature engineering disciplines. At the foundation level you'll find pure mathematitians. They figure out stuff - stuff that not even they know the application of. On top of this foundation of pure mathematics you'll find people that can see the application of the clever stuff bubbling from beneath them, we'll call them the engineering scientists. Building on top of the engineering sciences you'll find types that can use all the tools handed up from the lower layer to build predictive models. These are your engineers. At the next level you'll find individuals that can take the models and draw designs, diagrams, schemas and plans and hand it off to other individuals that can correctly interpret the designs and such. At the next level you'll get the types that can say "Ok Bob, do this, that and the other!" - according to the plans etc. And right at the top sits Bob, someone that is relatively unskilled but hard working.
What do we have that even approach this in the software engineering field? Should we be arrogant enough to call software endeavors "engineering"? What are your thoughts? More on this in a later article.
Monday, October 10, 2005
On systems, software and salesmen
've been doing systems and software for 15 years. At times it's been a rodeo ride a river raft a cliff dive a drag race an under water breath-holding contest a space walk and dogfight. It's never quite been a hot-air balloon ride for long... Things happen - often. If you pick the wrong road or get stuck in a comfortable spot you may be dead sooner than you think.
I've seen the rise and fall of many a paradigm (did they really rise - or fall?; were they not just repackaged, renamed, repositioned?). Dumb terminals and mainframes, client-server, container based ala MTx and EJB and Servlet, services of all kinds. Procedural, OO, aspect-oriented, component-based, object-relational mapping, service-oriented, dependency injection, monolithic, service bus, distributed and on and on and on...
Unix was big, Windows flexed its muscles, DOS died, Linux was born and has come of age at the expense of all types of Unices and all kinds of Windows OS's. I did serious development with Ada, C, C++, C#, Python, Pascal, Object Pascal, Delphi, Power Builder and Java. I played with Objective C, D, Eiffel, JavaScript, CLOS, TCL, Perl and Lisp. The benevolent forces spared me exposure to COBOL, Fortran and Visual Basic.
I witnessed the demise of WordPerfect, the rise of Microsoft office, the death of Netscape's browser. I've lived through the software notation wars. I saw Coad-Yourdon, Shlear-Mallor, Booch, Objectory, OMT and some others cooked into UML. I witnessed some great work by Gamma, Helm, Johnson and Vlissides. I am now standing on the slow moving tectonic plate that is called open source and open standards. Who knows what will happen - will we see the Himalayas form? The great divide? Will we see the birth of Pangaea?
You used to pay for everything. Now it seems that we may end up paying for nothing - hmmm, we'll see...
The big constant in all of this is the lies of the marketers and salesmen. Over and over I've heard the drum-beat; better, quicker, easier, cheaper. With the advent of every new technology I see pretty people pushing pretty glossies from high profile companies stating that the slog is over, that the easy life has arrived, that the hard stuff has become easy. What bothers me no end is that the exact opposite is true. Technology becomes more and more complex. Things takes longer. It's harder. Integration is tougher. You have to absorb more. Things gets slower in the age or super fast processors. Gains in productivity is negated by the arrival of the next best thing - as soon and you know something it is obsolete. Chaos reigns, mostly.
How do we stop this? Can we stop this with the forces of profit driving systems and software technology? My views at a later stage...
I've seen the rise and fall of many a paradigm (did they really rise - or fall?; were they not just repackaged, renamed, repositioned?). Dumb terminals and mainframes, client-server, container based ala MTx and EJB and Servlet, services of all kinds. Procedural, OO, aspect-oriented, component-based, object-relational mapping, service-oriented, dependency injection, monolithic, service bus, distributed and on and on and on...
Unix was big, Windows flexed its muscles, DOS died, Linux was born and has come of age at the expense of all types of Unices and all kinds of Windows OS's. I did serious development with Ada, C, C++, C#, Python, Pascal, Object Pascal, Delphi, Power Builder and Java. I played with Objective C, D, Eiffel, JavaScript, CLOS, TCL, Perl and Lisp. The benevolent forces spared me exposure to COBOL, Fortran and Visual Basic.
I witnessed the demise of WordPerfect, the rise of Microsoft office, the death of Netscape's browser. I've lived through the software notation wars. I saw Coad-Yourdon, Shlear-Mallor, Booch, Objectory, OMT and some others cooked into UML. I witnessed some great work by Gamma, Helm, Johnson and Vlissides. I am now standing on the slow moving tectonic plate that is called open source and open standards. Who knows what will happen - will we see the Himalayas form? The great divide? Will we see the birth of Pangaea?
You used to pay for everything. Now it seems that we may end up paying for nothing - hmmm, we'll see...
The big constant in all of this is the lies of the marketers and salesmen. Over and over I've heard the drum-beat; better, quicker, easier, cheaper. With the advent of every new technology I see pretty people pushing pretty glossies from high profile companies stating that the slog is over, that the easy life has arrived, that the hard stuff has become easy. What bothers me no end is that the exact opposite is true. Technology becomes more and more complex. Things takes longer. It's harder. Integration is tougher. You have to absorb more. Things gets slower in the age or super fast processors. Gains in productivity is negated by the arrival of the next best thing - as soon and you know something it is obsolete. Chaos reigns, mostly.
How do we stop this? Can we stop this with the forces of profit driving systems and software technology? My views at a later stage...
Subscribe to:
Posts (Atom)