I'm glad to announce that the world has got yet another (tiny!) open source project, Apache JaxMas. JaxMas is basically a very, very incomplete JAXR implementation.
Why another JAXR implementation? The world has already got plenty of them, for example Apache Scout. My job is mainly about CentraSite, my employers implementation (there's more to it than a simple JAXR implementation, of course). But they all share a common problem: It is basically impossible to use them for unit testing and non-trivial, to use them within integration tests.
The problem is that they all require a running server. And, what's more, it is difficult to start from a predefined set. That's where JaxMas comes into play. JaxMas is running on HSQLDB. The embedded mode of HSQLDB is obviously ideal for unit tests. JaxMas is based on the assumption of an initial schema, that is created by the unit test. The schema is basically a set of SQL commands, but a macro processor allows to create taxononmies and other registry objects relatively easily.
Btw, you might ask me why I didn't choose Apache Derby as the engine. Well, I did initially, but DERBY-338 was blocking me. This issue prevents that two foreign key references exist between the same tables with different ON DELETE clauses. However, I need that feature for deleting even complex registry objects with a simple DELETE statement.
Showing posts with label JAXR. Show all posts
Showing posts with label JAXR. Show all posts
Thursday, July 31, 2008
Friday, July 18, 2008
JaxMas?
I am currently preparing a proposal for the Apache Labs. It will be something like an absolute minimal registry for writing JAXR based unit tests, running on Apache Derby. The idea is, that with existing registries (in my case CentraSite) you'll rarely be writing unit tests, because the overhead is so high, that nothing below integration tests makes sense.
Like any child, this one needs a name. With names, however, I am as inventive as the former federal german phone company. (The companies current successor is inventive, in particular with new ways to bill you for things that have been free in the past.) Usually, a projects name would be discussed on the corresponding mailing list.
In this case, however, it is more than likely, that I'll be the only user. So I though to ask here: As far as I know, this blog has at least two users and thats more than one, isn't it? So far my only idea was JaxMas, in honour of my former child JaxMe and due to the fact, that I had the idea on christmas. Better suggestions more than welcome!
Like any child, this one needs a name. With names, however, I am as inventive as the former federal german phone company. (The companies current successor is inventive, in particular with new ways to bill you for things that have been free in the past.) Usually, a projects name would be discussed on the corresponding mailing list.
In this case, however, it is more than likely, that I'll be the only user. So I though to ask here: As far as I know, this blog has at least two users and thats more than one, isn't it? So far my only idea was JaxMas, in honour of my former child JaxMe and due to the fact, that I had the idea on christmas. Better suggestions more than welcome!
Monday, August 20, 2007
History Repeating
In the nineties, I used to work as a freelancer, typically in small one-man projects. At that time, Perl was by far my favourite programming language. Some relicts can still be found. Perl was the proper tool for the job: I had the oversight. I knew any single line of code. If changes were required, then I knew exactly what to do.
When I started to work in larger projects, with two or more members, I felt the weak sides of Perl immediately. Even as the lead developer, I began to lose control. Even if I knew how sources had been, I didn't know exactly, how they were. For example, I could no longer change a methods signature without the risk to break things. The larger the project, the more overwhelming the problem. Java with its type safety and strictness was much more appropriate. I was again able to respond quickly to changed requirements. (Today, I really wonder how large PHP projects are managed and how much time is lost when dealing with these things.)
Of course, that wasn't the end of the story. Code is more than Java, Perl, or any other programming language. I began to become aware of that in my first XML projects, around 1999. The initial version was always based on DOM. The application programmers were fumbling around from node to node, reproducing algorithms again and again. Of course, DOM (or SAX, or pull parsing) was (and still is), the proper tool for generic XML processing. But it is extremely unusable for application programming: As soon as the data model changes, you are lost. Once more, the concept works for small projects. But in a large project, things are quite different: There's absolutely no reliable way to find all locations in the code, that need to be changed.
My reply was the predecessor to JaxMe 1, an early Java/XML binding tool. The binding compiler converts the DTD, or XML schema, into Java beans. By using these beans, the Java compiler controls your use of the data model. If the data model changes, then the compiler tells you exactly what breaks. Ideally, the application programmers will be able to implement about 80% of the projects code by working on the beans and the project becomes manageable again. Of course, the JaxMe predecessor, JaxMe 1, and even JaxMe 2 are very limited tools, compared to modern and full blown Java/XML binding suites like JAXB. But that's not the point, in contrary: It's quite telling, that even my self-made tool could boost a project. The fact, that there have been so many similar projects (Castor, Zeus, XML Beans, to name a few), also goes to show the concepts value.
Two, or three years later, I felt a dejavu: For the first time, I was working in a large SQL/JDBC project. It was the same story again: As soon as we had implemented the first 50 or so queries, some of them quite complex, we felt again, that the growth began to become uncontrolled. An action as simple as changing a column type from boolean to integer could break the project and result in hours of bug tracking. As Hibernate, OJB, and other object-relational mappers (not to mention JDO) weren't available or not really recommendable at the time, I began to implement my own nonsense again. It was sufficient as the base of two large projects. A similar tool, not implemented by me, but by another very capable programmer (Hello, Winfried, should you read this. :-), was the foundation of a third project. The success in relation to the simplicity proves again, how important mapping of loosely coupled entities (tables) to structures controlled by the Java compiler can be.
Well, history's repeating. Nowadays, I am working in a large project again, feeling my own unability to keep the projects parts together: This time the entities are called registry objects, classifications, or associations, they are stored in a registry and accessed via JAXR. The project is getting larger, the pain caused by data model changes is growing. This time, we do not even have a schema language, not to mention a binding compiler, that translates structures into accessors.
But maybe, we can learn from history. I promise that I search for other peoples solution much longer this time. :-)
When I started to work in larger projects, with two or more members, I felt the weak sides of Perl immediately. Even as the lead developer, I began to lose control. Even if I knew how sources had been, I didn't know exactly, how they were. For example, I could no longer change a methods signature without the risk to break things. The larger the project, the more overwhelming the problem. Java with its type safety and strictness was much more appropriate. I was again able to respond quickly to changed requirements. (Today, I really wonder how large PHP projects are managed and how much time is lost when dealing with these things.)
Of course, that wasn't the end of the story. Code is more than Java, Perl, or any other programming language. I began to become aware of that in my first XML projects, around 1999. The initial version was always based on DOM. The application programmers were fumbling around from node to node, reproducing algorithms again and again. Of course, DOM (or SAX, or pull parsing) was (and still is), the proper tool for generic XML processing. But it is extremely unusable for application programming: As soon as the data model changes, you are lost. Once more, the concept works for small projects. But in a large project, things are quite different: There's absolutely no reliable way to find all locations in the code, that need to be changed.
My reply was the predecessor to JaxMe 1, an early Java/XML binding tool. The binding compiler converts the DTD, or XML schema, into Java beans. By using these beans, the Java compiler controls your use of the data model. If the data model changes, then the compiler tells you exactly what breaks. Ideally, the application programmers will be able to implement about 80% of the projects code by working on the beans and the project becomes manageable again. Of course, the JaxMe predecessor, JaxMe 1, and even JaxMe 2 are very limited tools, compared to modern and full blown Java/XML binding suites like JAXB. But that's not the point, in contrary: It's quite telling, that even my self-made tool could boost a project. The fact, that there have been so many similar projects (Castor, Zeus, XML Beans, to name a few), also goes to show the concepts value.
Two, or three years later, I felt a dejavu: For the first time, I was working in a large SQL/JDBC project. It was the same story again: As soon as we had implemented the first 50 or so queries, some of them quite complex, we felt again, that the growth began to become uncontrolled. An action as simple as changing a column type from boolean to integer could break the project and result in hours of bug tracking. As Hibernate, OJB, and other object-relational mappers (not to mention JDO) weren't available or not really recommendable at the time, I began to implement my own nonsense again. It was sufficient as the base of two large projects. A similar tool, not implemented by me, but by another very capable programmer (Hello, Winfried, should you read this. :-), was the foundation of a third project. The success in relation to the simplicity proves again, how important mapping of loosely coupled entities (tables) to structures controlled by the Java compiler can be.
Well, history's repeating. Nowadays, I am working in a large project again, feeling my own unability to keep the projects parts together: This time the entities are called registry objects, classifications, or associations, they are stored in a registry and accessed via JAXR. The project is getting larger, the pain caused by data model changes is growing. This time, we do not even have a schema language, not to mention a binding compiler, that translates structures into accessors.
But maybe, we can learn from history. I promise that I search for other peoples solution much longer this time. :-)
Subscribe to:
Posts (Atom)