You do not learn 'Webservices' in one day...

The past few days have been a bit difficult for us, that is, we discovered that we may have moved a bit too fast...

Being new to the whole 'Webservices-thing' makes it difficult at times to see the forest through the trees. Webservices and more specifically the J2EE stack provide a LOT of ways and methods (all with their own accronym) to do certain things. Moreover, in many cases, there are several ways to accomplish the same goal, each needing its own set of tools and techniques.
Although we initially made a good start, we realized after a while that we were using certain techniques without actually knowing 'why' we necessarily used those (and more importantly: why we weren't using other, similar techniques). In particular, we were using Apache's axis ADB to parse incoming SOAP messages to Java objects. While learning more about the subject, we discovered that there are other libraries/techniques which provide similar features (XMLBeans, JiBX, JAXB, AXIOM, POJO's, etc).
Not knowing any of these libraries (except for JAXB, which we have used before), we didn't really know what their differences (strengths/weaknesses) were.
Others Axis/Webservices related libraries also needed some further investigation (WS-*, Spring, EJB's, JAX-WS among others).

That is why we decided to postpone the 'prototype-deadline' which was scheduled for this Friday; we really need some more time to investigate, so that we can make good decisions (we should at least know why we choose to use technique X and not technique Y).

Today, we already did a lot of extra research on various topics, and some concepts are already a lot clearer. (E.g.: we will probably use POJO's instead of ADB, or any other XML-parser/binder, since this prevents us from having to manually parse SOAP messages).


On another note, we've examined the SVN protocol more closely, and decided we'll replace the RA-layer in SVNkit with a custom (soap)implementation. In doing so, we only change the way svn communicates with a server, and do not change svn's mechanics for storing changes made to files.

Hopefully, we've made a better start now, and won't run into similar problems in the future...

You'll hear from us soon !