Scala has performed admirably in the first major task in which I've employed it. In my previous post I mentioned the XML virtualization framework I'm building. It's part of an Xpath equipped web service. The system will enable its clients to treat each mortgage as a giant XML document and use Xpath to select the part of that document in which they are interested. That Xpath query will invoke the specific functionality needed to perform queries against an existing database to construct the document fragment requested by the client, and nothing else. This is an important feature considering the massive amount of data contained in just a single loan. The document couldn't be generated in full every time someone wanted to grab the borrower's last name. I think this document-centric view of our data will be very powerful. The treelike nature of XML makes it a good way of defining ontologies, giving us an opportunity to break the many fields of each loan into a logical hierarchy. This is good for developers, because the data they'll work with will be presented coherently. It's also going to be excellent for systems integration and our ultimate upgrade path. We are basing our organization scheme on a collection of industry standard documents called schemas. Schemas are documents that describe the structure of other documents, in this case the documents involved in various stages of the mortgage process. Very soon now, many companies that we work with will be accepting documents based on these schemas, so by mapping them to our existing database, we'll gain this sort of interoperability for free. Because the schemas were developed by a mortgage standards organization which worked on them over a period of years, they are very complete. Most information that we'd need to include in a mortgage system is present in these documents, and what's missing can be added with extensions to the standard. The standards represent a stable assumption about the structure of loan information, and that makes them a good point for a software interface. We can write software that interacts with our back-end systems by treating the information they store as an XML document that conforms to the standards. A new, more robust back-end system will later be brought online to replace the existing one, but it will continue to support this standard interface. This means we can route any interactions destined for the old system to the new one as well, making a gradual transition.

I just wanted to post something short to get the ball rolling again on writing here. Sometimes it seems like the longer I go without doing something, the more resistant I feel to doing it. Tomorrow I'm starting to work in earnest on a pretty cool project for work, constructing an abstract interface to their legacy database that conforms to an XML document type definition. I'm going to construct a data structure mirroring the grammar specified by the DTD, attaching programmatic functionality to it at different points of the tree that will query the legacy database and return a fragment of XML representing that portion of the document. I will then support Xpath queries against the imaginary document, which will locate the functionality to generate the XML being requested, restricting database access and document construction overhead only to the portions of the document that are actually requested. I'm going to try to use a functional programming language called Scala, which integrates pretty tightly with the Java platform, compiling to byte code and using Java classes directly within programs. I'm a little uncertain, especially because I'm going to write my own parser using a Java parser generator, and I'd like this parser to construct classes specific to Scala called case classes, which can be pattern matched, making decomposition of the parsed data simple. I'm not so sure I can instantiate these specialized classes in Java even though they are written in Java bytecode, so it remains to be seen how much impedance I'll feel between the two languages.