Schematron - validating web-forms and java objects

Whilst developing web applications, more than often we are confronted with the need to validate user inputs. On the client-side (browsers) we generally do that with scripting languages; and for those users who have perhaps deliberately disabled their browser script support; we perform the same set validation on the server side, and this time we write some lines-of-code to extract the user input from the HTTP request and validate the same. Well, although ironic; yet it seems to be a de-facto that - we have to specify the validation rules separately on the client and server side, for eventually validating something that is semantically same.

A technical analysis into the core reason reveals that – although the semantics of the herein discussed "thing" (i.e. the user input) are the same, yet the representations of the semantic on the client and server side are different; which enforces us to implement the extraction and validation logic differently. So going by that theory - if we can represent the semantics of the user input in a single unified format, we can potentially have a single definition and implementation of the validation rules too.

So, what should our choice of a single unified data representation format? Well, there are a plethora of data representation formats out there; and you may be attracted to choose one that best suits your industry. However, as this article intends to project Schematron as a common validation solution across the client and server; I limited my choice to XML with intent to convey the concept with simplicity.

Dear JSON lovers, here is an excellent library by Stefan Goessner, which provides helper function for converting JSON to XML and visa-versa; So, that means - Schematron can be potentially used to validate JSON representations too.

So, let’s apply the concept to practice -

Before we apply Schematron to validate the user inputs on the client side; one must first convert the web form input to XML. The following archive illustrates an approach for converting a web form to XML and validating the same against a standard Schematron based schema –

• schematron-sample.rar

Once we have validated the user input on the client, we forward the same to the server; wherein we should re-use our validation rules and this time execute the same on the server side. For many of you out there this is perhaps a no-brainer. Nevertheless, we will discuss this aspect in similar details with the next post in this series.

Until then wish you a merry Christmas and a safe holiday season.

Introducing Schematron

Schematron is a rule-based validation language for making assertions about patterns found in XML documents. It is a simple language which is based very much on XML itself and uses standard XPath to specify the assertion statements. The Schematron definations (a.k.a Schema) can be processed with standard XSL templates; which makes Schematron applicable is a variety of scenarios.

Although a Schematron defination is referred as a Schema, but one must understand that Schematron differs in the basic concept from other schema languages; i.e. it is not based on grammars but on finding tree patterns in the parsed document. This approach allows many kinds of structures to be represented which could be difficult with grammar-based schema languages. For instance - imagine how would a typical schema be, for the following XML document -

<?xml version="1.0" encoding="UTF-8"?>
<instance>
####<person>
########<fname/>
########<lname/>
####</person>
</instance>

Guess its a no-brainer! It would be something like this -

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
####<xs:element name="instance">
########<xs:complexType>
############<xs:sequence>
################<xs:element name="person">
####################<xs:complexType>
########################<xs:sequence>
############################<xs:element name="fname" type="xs:string"/>
############################<xs:element name="lname" type="xs:string"/>
########################</xs:sequence>
####################</xs:complexType>
################</xs:element>
############</xs:sequence>
########</xs:complexType>
####</xs:element>
</xs:schema>

You must be already wondering about how different would the same schema look like in the "Schematron" world, right? Well, here is the answer -

<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.ascc.net/xml/schematron" >
####<pattern name="assert validity">
########<rule context="instance">
############<assert test="person">person element is missing.</assert>
########</rule>
########<rule context="person">
############<assert test="fname">fname element is missing.</assert>
############<assert test="lname">lname element is missing.</assert>
########</rule>
####</pattern>
</schema>

Now, isn't that a much better and understandable version of a schema?

A closer look at the above document would reveal how Schematron differs in the fundamentals of validating a document; the crux herein is not to define the structure of the document (that is what the traditional schema types do), but is to assert the structure. Imagine it to be something like JUnit or NUnit for the XML world; wherein one puts assert statements to check the validity of an object's state. And just like it happens in the JUnit or NUnit world; herein with Schematron also, one can have custom messages for assert conditions.

The Schematron can render custom messages in two cases, v.i.z. -

1. "Report" the presence of a pattern
2. and "Assert" the absence of a pattern

The following Schematron document illustrates the usage of the above discussed features -


<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.ascc.net/xml/schematron" >

####<!-- Render messages in case the elements are found. -->
####<pattern name="report validity">
########<rule context="instance">
############<report test="person">person element is present.</assert>
########</rule>
########<rule context="person">
############<report test="fname">fname element is present.</assert>
############<report test="lname">lname element is present.</assert>
########</rule>
####</pattern>

####<!-- Render messages in case the elements are not found. -->
####<pattern name="assert validity">
########<rule context="instance">
############<assert test="person">person element is missing.</assert>
########</rule>
########<rule context="person">
############<assert test="fname">fname element is missing.</assert>
############<assert test="lname">lname element is missing.</assert>
########</rule>
####</pattern>

</schema>


Now that we know how Schematron based schemas look like; the next obvious question is - "How to validate a document against a Schematron schema...?" Well, I already addressed that question in the first paragraph itself, with the following statement -

"The Schematron definations (a.k.a Schema) can be processed with standard XSL templates."

Following statements illustrate the basic processing involved in validating a document with Schematron -

xslt -stylesheet schematron-message.xsl SchematronRules.xml > compiled-SchematronRules.xsl
xslt -stylesheet compiled-SchematronRules.xsl TestData.xml

Now if that looks a little complex; here is a simple Schematron document validator (implemented in Java) which I developed to ease this complexity -

- Schematronize.java

The above listed validator requires the following XSL templates to be locally available -

- skeleton1-5.xsl
- schematron-message.xsl

Thats all for now... I’d leave it here for you to play. Hope you enjoyed reading this article. I will look forward to reading your feedbacks and implementation details around Schematron, so please do take a moment and drop in a note.

Adieu.

Some References -

- The Schematron Website
- The Academia Sinica Computing Centre's Schematron Home Page

Scarlet – A Scala DSL for web applications

Work in Progress The Scarlet project is currently under development. Please keep an eye on the sourceforge project site (sourceforge.net/projects/scarlets) or contact personally for updates.

Introduction to Domain Specific Language (DSL)

Domain-specific languages have lately become a hot topic and a lot is being spoken and written about them all over the internet; much of the buzz around functional languages is their applicability to (once again) put the power and control of an application in exactly the right place where it belongs, i.e. in the hands of its users.

By defining a simple language that the application users can understand, feel comfortable to communicate and use, programmers can effectively reduce their involvement in the never-ending cycle of UI requests and enhancements and can let users create scripts and other tools that allow them to create newer behavior in the applications they use. A perfect example of a wildly successful DSL is the Microsoft® Office Excel "language" used to express the various calculations and contents of the cells in the spreadsheets.

Well, some might even go far and suggest that SQL itself is a DSL, this time a language aimed specifically at interacting with the relational database (Imagine if programmers had to fetch data out of Oracle via traditional API read()/write() calls — Eshhhh! Now that’s a nightmare).

What is Scarlet…?

To be quick to the point: Scarlets is an attempt to create “platform-independent”, “compilable” and “executable” pseudo-codes.

Pseudo-codes are a kind of structured english for describing algorithms; which enables the designer to focus on the logic of the algorithm without being distracted by details of language syntax. The intent is to describe the entire logic of the algorithm with finer details so that implementation becomes a rote mechanical task of translating line by line into source code.

We have known pseudo-codes probably since the beginning of times at software engineering. And although we understand that pseudo-codes are capable of describing the entire logic of an algorithm to such an extent that implementation remains to be a simple mechanical task of translating lines of plain english into source code; yet, this so-called simple mechanical task is till date performed with human efforts.

The Scarlets project intends minimize this human intervention by defining a Scala based domain-specific language which is very much like structured english and is a narrative for someone who knows the requirements (problem domain); so that he/she can write a pseudo code and see it run with zero or minimal involvement of a programmer who knows the programming language (implementation domain).

A Sample Scarlet

The following is a sample implementation of Scarlet –

AccountApp.scala :

val userName = theParameter named "user" in request if (userName equals "nothing") { ~~~this renders "AccountUserForm.jsp" } else { ~~~theAttribute named "LoggedInUser" in session is userName ~~~val accountHolder = new AccountHolder("B123456", "Rahul", "Roy") ~~~val account = new Account("SA-001", accountHolder, 100.00) ~~~theAttribute named "AccountObject" in session is account ~~~this renders "AccountDisplay.jsp" }

Do we need a description for the above implementation…? Well, I’d rather leave it for you to understand. Meanwhile here is how the AccountUserForm and AccountDisplay Java server-pages (JSP) look like.

AccountUserForm.jsp :

<html> ~~~<head> ~~~~~~<title>Scarlet Sample</title> ~~~</head> ~~~<body> ~~~~~~<form action="AccountApp" method="GET"> ~~~~~~~~~Username : <input type="text" name="user" /> ~~~~~~~~~<input type=submit value="Login" /> ~~~~~~</form> ~~~</body> </html>

AccountDisplay.jsp :

<% ~~~~~~account = session.getAttribute("AccountObject"); ~~~~~~LoggedInUser = session.getAttribute("LoggedInUser").toString(); %> <html> ~~~<head> ~~~<head> ~~~~~~<title>Scarlet Sample</title> ~~~</head> ~~~<body> ~~~~~~<%=LoggedInUser%>'s Account : <%=account%> ~~~</body> </html>

I hope you found Scarlets to be interesting; anyways please do feel free to share your thoughts and comments here so that I can better it with your cooperation.

Web4J : An Interesting framework

Its been quite a while since my last post here. I understand that my sudden disappearing act must have annoyed a many of my regular visitors; especially the ones who are expecting the second part of the XRX tutorial.


Whilst you wait for the concluding part of the XRX article, I thought of sharing somethings that i found to be interesting -


As Java Web application frameworks have become more powerful and flexible, they've also become more complex. John O'Hanley's WEB4J framework in many ways flies in the face of this trend: it offers few customization options, but is easy to learn and work with. Read on to learn about the unusual (and somewhat contrarian) development principles behind WEB4J. You'll also have the opportunity to test out the framework by building a feature for a sample Web application... [more]

Part I : XRX Architecture - Unleashed

During my tenure at Software AG, I was introduced to the power of XML. To my candor, i was very impressed to see the wide range of problems that XML promised to solve. Especially, to mention the performance power-punch that XML databases unleash when combined with XQuery and REST.

A couple of years later, I moved into the consultancy world. Being back in the consultancy world and seeing business systems with my renewed XML-ized eyes (all credits to Software AG Tamino API and tools laboratory), I was highly dismayed to find that business oriented systems seldom use the real power of XML. The usage of XML herein has been more-so confined to defining application configurations and bare minimum transformation to either render interface elements or reports. I agree, there have been a few exceptions to this statement too.

After spending quite some years revolting the general underutilization of XML; apparently I found my preferred architecture – i.e. XRX (XForms/REST/XQuery).

What is so unique about XRX architecture...? Generally, web application architectures accept inputs from HTML forms, which provide the user inputs in flat key-value pairs, thereafter these data structures are converted to middle tier objects such as Java or .Net and then transformed into tabular data streams so they can be stored in relational databases. Once in the relational database, the data must then be re-serialized by doing SELECT statements, converted into objects and the objects then converted back into HTML forms. This is four-step translation architecture. In contrast to the above discussed conventional approach, XRX uses the zero-translation architecture. Zero translation implies that XML is stored in the web client, transmitted to a middle tier validation rules engine in XML and then stored in its entirety in an XML database. The storage in a single XML object is also known as a zero-shredding process since the data files are not separated into Third Normal Form (3NF) data structures. The key here is to break the myth and realize that 3NF shredding does not add any business value to the system.

Over the years, I have preached XForms as a very solid architectural composite; as it offers an order-of-magnitude improvement over other web front-end development architectures. Now, XForms when combined with the traditional XML performance power-punch i.e. REST and XQuery, defines a radical architecture that works wonders.

I'm sure you must be already wondering: how to build this magical combination of XForms - REST - XQuery (XRX)? The following architecture view depicts the approach at an abstract, to facilitate and initiate your quest -


Following are some of the distinct advantages rendered by XRX architecture -

• A web development architecture with a 10x productivity improvement over traditional Javascript/Object Oriented/RDBMS methods

• A development architecture based on international standards that is designed to minimize the probability of vendor-locking

• An architecture that gives a rich user experience without creating mountains of spaghetti procedural code on either the client or the server

• A system that leverages the REST architecture to take advantage of high-performance and simple interfaces using web standards

• Portability on both the client and the server using a variety of forms players and XQuery databases

• The option of avoiding costly shredding (and reconstitution) of complex XML documents into RDBMS tables

• A community of standards/tools and a "complete solution" ecosystem that can give you a proven ROI on IT investment

The forthcoming post in this series, i.e. "Part II : XRX Architecture - Illustrated", will walk you through an elaborate tutorial on building a sample application that implements the XRX architecture.

Adieu for now...

NLBean - Make your database understand English

Natural language processing (a.k.a. NLP) is a stream of artificial intelligence and computational linguistics. In theory, it is the most attractive method of human-computer interaction; but as natural language recognition seems to require extensive knowledge about the outside world and the ability to manipulate it, implementing Natural Language Processing has infact been one of the most sought after conundrums in the computing world. This article presents an abstract introduction to natural language processing and further discusses implementing the same to query databases.

What is a Natural Language Processing (NLP)…?

Natural language processing is the collection of techniques employed to enable the computers to understand the languages spoken by humans. The concept linguistic analysis and processing originated with efforts in the United States in the 1950s, wherein the intent was to use computers to automatically translate texts from foreign languages into English. Since computers had proven their ability to do arithmetic much faster and more accurately than humans, it was thought to be only a short matter of time before computers demonstrated the remarkable capacity to process human spoken languages. When computer based translation failed to yield accurate translations even after recurring efforts, automated processing of human languages was concluded to be far more complex than originally assumed. Hereafter natural language processing was recognized as a new field of study, devoted to developing algorithms and software for intelligently processing language data. Over the past 50 years, the field of natural language processing has advanced considerably and several algorithms have been developed, which process language grammar and syntax.

What is Natural Language Database Query (NLDQ)…?

Thinking a little innovative around the implementations of natural language processing, one can imagine a plethora of its applications, including a natural language processor to query databases. Natural language database query (NLDQ) is a subset of natural language processing (NLP) that deals with natural language inquiries against structured databases. The quintessence of natural language database querying (NLDQ) is to transform natural language requests into SQL or some other database query language, which could be further used to perform extractions from standard databases. As of today, there are quite some implementations which transform regular English sentences into well-formed queries. Following are some of the viable options in this segment – Commercial

• Semantra
• ELF English Query

Educational

• Nchiql - a Chinese natural language database querying system
• TELL-ME - a VAX/VMS based prototype natural language database querying system

Another workable option and one of my favorite open source projects in the arena of natural language database querying (NLDQ) is NLBean. Although the code is very much crude and experimental, yet it does work fairly well. The implementation could be extended, customized to identify varied organizational domain terms and used to render an easy to use interface for our business users who struggle to understand standard database query languages. The following screenshot depicts the standard interface rendered by NLBean v5.0 –

(Click on the image to zoom)

References

• Download the latest version of NLBeans here.
• Further details on NLBeans can be found here.
  

VirtualBox – Simple and Sweet Virtualization

I have been experimenting with virtualization since quite sometime now. My interest towards hypervisors or virtualization was sourced from the need to enhance the productivity my development and testing staff, by enabling them to switch between multiple operating systems on the very same box, without having to reboot the entire system.

Although virtualization has been around since many years now, but my search for better and cost-effective hypervisors recently seems to have been complimented with a plethora of them available at zero cost.

VMware is finally giving away its Update 2 for VMware Infrastructure 3.5 along with a lightweight edition of its market leading hypervisor, ESX 3i, for free. Read more about this new here.

Another competitive product is this segment is VirtualBox; which is a powerful x86 virtualization products for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL).

My personal experience with VirtualBox so far has been good. VirtualBox is simple to configure and use. The best part of VirtualBox is that the images are very portable. Additionally, the VirtualBox snapshot technology provides the same basic functionality as the VMware, that is, they can be taken while the virtual machine (VM) is running or offline.

Here is a screenshot of what we achieved with VirtualBox; it depicts three operating systems instances (v.i.z. Windows Vista, Windows 95 and Ubuntu) running in parallel, right on the same box; wherein each of those instances could be distinctly accessed over the network.

(Click on the image to zoom)

The term "cost-effective" doesn't necessarily always mean "free". Yesterday whilst chatting with Prashant, a friend and technology evangelist, I got introduced to Amazon Elastic Compute Cloud (Amazon EC2), which is an amazing virtual computing solution that costs nominal. Further research on this topic lead me to an open source Google-code project, namely Scalr.

I’ve not yet had an opportunity to play with Scalr, but with the first look at it, i must say that i am impressed. I am looking forward have my hands on it soon and i would definitely share the experience here. So keep an eye on this blog, for more on virtualization in future.

Thats all for now... Hope you enjoyed reading this article. I’d love to read your feedbacks and details about your virtualization experiences, so please do take a moment and drop in a note.

Adieu.

Shard – A Database Design

Scaling Database is one of the most common and important issue that every business confronts in order to accommodate the growing business and thus caused exponential data storage and availability demand. There two principle approaches to accomplish database scaling; v.i.z. vertical and horizontal.

Regardless of which ever scaling strategy one decides to follow, we usual land-up buying ever bigger, faster, and more expensive machines; to either move the database on them for vertical scale-up or cluster them together to scale horizontally.

While this arrangement is great if one has ample financial support, it doesn't work so well for the bank accounts of some of our heroic system builders who need to scale well past what they can afford.

In this write-up, I intend to explain a revolutionary and fairly new database architecture; termed as Sharding, that some websites like Friendster and Flickr have been using since quite sometime now. The concept defines an affordable approach to horizontal scaling with no compromise at all.

For instance Flickr handles more than 1 billion transactions per day, responding in less then a few seconds and can scale linearly at a low cost.

What is sharding...?

While working for an auction website, somebody got the idea to solve the site’s scaling problems by creating a database server for a group of users and running those servers on cheap Linux boxes. In this scheme the data for User A is stored on one server and the data for User B is stored on another server. It's a federated model. Groups of 500K users are stored together in what are called shards.

The advantages are:

• High availability. If one box goes down the others still operate.
• Faster queries. Smaller amounts of data in each user group mean faster querying.
• More write bandwidth. With no master database serializing writes you can write in parallel which increases your write throughput. Writing is major bottleneck for many websites.
• You can do more work. A parallel backend means you can do more work simultaneously. You can handle higher user loads, especially when writing data, because there are parallel paths through your system. You can load balance web servers, which access shards over different network paths, which are processed by separate CPUs, which use separate caches of RAM and separate disk IO paths to process work. Very few bottlenecks limit your work.
  

How is Sharding different from traditional architectures...?

Sharding is different than traditional database architecture in several important ways; following are the key factors -

Data is denormalized. Traditionally we normalize data. Data are splayed out into anomaly-less tables and then joined back together again when they need to be used. In sharding the data are denormalized. You store together data that are used together.

This doesn't mean you don't also segregate data by type. You can keep a user's profile data separate from their comments, blogs, email, media, etc, but the user profile data would be stored and retrieved as a whole. This is a very fast approach. You just get a blob and store a blob. No joins are needed and it can be written with one disk write.

Data is across many physical instances. Historically database servers are scaled up. You buy bigger machines to get more power. With sharding the data are parallelized and you scale by scaling out. Using this approach you can get massively more work done because it can be done in parallel.

Data is small. The larger a set of data a server handles the harder it is to cash intelligently because you have such a wide diversity of data being accessed. You need huge gobs of RAM that may not even be enough to cache the data when you need it. By isolating data into smaller shards the data you are accessing is more likely to stay in cache.

Smaller sets of data are also easier to backup, restore, and manage.

Data are more highly available. Since the shards are independent a failure in one doesn't cause a failure in another. And if you make each shard operate at 50% capacity it's much easier to upgrade a shard in place. Keeping multiple data copies within a shard also helps with redundancy and making the data more parallelized so more work can be done on the data. You can also setup a shard to have a master-slave or dual master relationship within the shard to avoid a single point of failure within the shard. If one server goes down the other can take over.

It doesn't use replication. Replicating data from a master server to slave servers is a traditional approach to scaling. Data is written to a master server and then replicated to one or more slave servers. At that point read operations can be handled by the slaves, but all writes happen on the master.

Obviously the master becomes the write bottleneck and a single point of failure; and as the load increases the cost of replication increases. Replication costs in CPU, network bandwidth, and disk IO. The slaves fall behind and have stale data. The folks at YouTube had a big problem with replication overhead as they scaled.

Sharding cleanly and elegantly solves the problems with replication.

The most recommended approach to implement database shards is using the Hibernate Shards framework. The said framework offers critical data clustering and support for horizontal partitioning along with standard Hibernate services. Which enable the businesses to keep data in more than one relational database without any add-on complexity whilst building the applications.

Other than Hibernate; shards can also be implemented with any of the following toolkits –

• Apache Slice (supports distributed XA transactions)
• Websphere ObjectGrid

Well, thats all for the starters folks. Hope this was an useful read and has provided enough thoughts for your brains to work quite sometime now...

Symptoms of an aging software

Most product development starts with a good design in mind. The initial architecture is clear and elegant. But then something begins to happen. What really happens is that the programs, like people, get old. However, unlike (in most cases) people there is no guarantee that software will mature as it grows old. Even worse, if we aren’t taking care of standard Software Quality Assurance (SQA), our system is not only ageing, but infact it is rotting. A Software undesirably grows old for two major reasons –

1. The product owners have failed to modify the software to meet changing needs.
2. The changes are made that yield poor results.

It is SQA that determines the way we can check and improve our software quality. SQA is a planned and systematic approach to evaluation of the quality and adherence to software product standards, processes, and procedures. It includes the process of assuring that standards and procedures are established and followed throughout the software acquisition life cycle.

So, who is responsible for SQA...? Well, everyone has an influence on quality - independent of his or her status and position in the project. What developers can do is focus their eyes on the excellence of defect detection, and removal as well as on design improvements wherever feasible. Now, in case of a horrendous design wherein every component seems to be dependent on every other, it could be a nightmare to even think of changing any of them. In such a case it’s all together a different war game. But in the case of a typical day-to-day scenarios, before we look closer at defect detection and analysis, we must first look for the standard symptoms of "ageing software".

You should keep an eye out for these characteristics, especially when your software is getting older.

1. Architecture and design can't keep up - As software ages, it grows bigger and bigger, but architecture and design will get flushed down and one would clearly see some kind of design erosion.
   
   
2. Unused or dead code - Another phenomenon that occurs in growing software is, incorporation of features that are not explicitly requested, but are mainly incorporated by enthusiastic software engineering staff members (especially agile techniques try to avoid these "eloping features"). This surely leads to unused (dead) code. This phenomenon can also be result of inadequately performed reuse.
   
   
3. Poor modularization - Programs are not divided into meaningful subsystems.
   
   
4. Confusing workflow - The program's dynamic work flow cannot be derived by a static code inspection.
   
   
5. Hidden redundancy - Duplicated code is infact the worst enemy of quality software.
   
   
6. Inaccurate scope - The scope, or visibility, of data and methods is inaccurate and more extended than necessary (e.g., "public" instead of "protected").
   
   
7. Semantic issues - Class names, variables and methods of non-framework class names are semantically worthless or irrelevant to the context of what it does (for example, the most famous "int i;”, by its mere name wonder who would tell you what it does; similarly “void doProcessing()” or “class DataHandler").
   
   
8. Poorly documented code and design - Documentation might even be ignored because it is considered inaccurate. It's hard to maintain and modify code that follows the maxim "If it was hard to write, it should be hard to read." Unfortunately, there are no incentives for programmers (at least not a practice that I’ve come across) to document their code or write clear and understandable programs. In fact, it's usually the opposite; developers are urged to quickly turn out code, mainly because of unrealistic schedules (thanks, to the project managers who fail to anticipate and setup the right expectation for their team deliverables); this can even happen in agile projects.
   
   
9. Exponentially increasing code changes - There is more and more code to change to incorporate new features or to fix detected errors. It is difficult to find the modules and components that must be changed and to preserve the original design when doing these changes.
   
   
10. Reliability decreases - As the software is maintained by the so called workarounds or hacks, more than often the complexity of keeping track of changes may result in new bugs. Even with minor changes, known and unknown dependencies among parts of the software are likely to impact and cause problems.
    
    
11. Lack of scalability - There is a lack of scalability, mainly revealed as reduced performance, as poor design (or often direct implementation) cause performance bottlenecks.
    
    
12. Lack of reusability - This may concern the reuse of modules from the product itself or even from other products or platforms developed by the organization.

Now, being familiar with the symptoms of rotting software, and having seen what can turn good software into a bad one, we will look at possible corrective actions which will be hosted here sometimes soon in future…

The musical world of Java

Recently whilst browsing through Geertjan’s blog, to keep myself abreast with the technological happenings of Netbeans; I stumbled upon an interesting write-up which discussed about a Java API for music, namely JFugue. Being inclined to music since my early days, the short write-up immediately caught-up my attention. I didn’t have enough time in hand to investigate it in detail; however, least I had a look at the API’s “programming” guide and was really astonished to find that now one can define musical scores, notes etc. and program an entire virtual orchestra to play and record the same in standard MIDI format.

Following are some more musical Java APIs -

• JFugue
• Drum++
• JMusic

Now that’s definitely music to ears for all the programmers out there who have a musical predilection.

Rest aside your web services

If you've been thinking of web services and feeling scared of that XML mess in the web service description (wsdl) files. Well, rest aside that scare now. And, by rest I mean, Representational State Transfer (REST).

Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. And thus invariably it could be also implemented in the world of web services as another revolutionary way of communication with web services. In REST, resources have URIs and are manipulated simply through HTTP header operations. Therefore, now one can imagine having a web service without all that WSDL clutter.

REST works around a very simple principle, i.e. HTTP methods POST, GET, PUT and DELETE can be compared with the CREATE, READ, UPDATE, DELETE (CRUD) operations associated with database technologies or any application model objects.

The following table associates several common HTTP verbs with similar database operations, however the meaning of the HTTP verbs do not correspond directly with a single database operation. For example, an HTTP PUT is used to set the value of a resource and may result in either a creation or update as needed.

HTTP	CRUD
POST	Create, Update, Delete
GET	Read
PUT	Create, Update
DELETE	Delete

I hope thats enough for a theoretical introduction. Now for those who are eager to try cooking some code, here is the recipe.

The Netbeans Tutorial - Getting Started with RESTful Web Services

FAINT - Search for faces

Lately, I've been playing around a bit with facial pattern recognition algorithms and their open source implementations. I came across many reference implementation but a very few were implemented in Java, and the Eigenfaces algorithm by far happens to be the best amongst them all. During my research around the said topic i happened to stumble-upon an implementation called FAINT (The Face Annotation Interface - http://faint.sourceforge.net). Faint by far the best facial pattern recognition API and as you must have already guessed, it implements the Eigenfaces algorithm.

Now enough of theory talks, how about implementing an example with faint...? Here is one for all you face-recognition enthusiasts. The following example simply searches for faces in a given photograph and thumbnails them. Now, I know thats not face recognition; but be a little creative here. Once you have the facial thumbnails extracted, its never a big deal to look further in the Faint API and find methods which can help you do the real recognition. :) Now, i was a little lazy to set up a pattern recognition database to left the example to the point of facial extraction only.

The Simple Class which extracts thumbnails -

import de.offis.faint.controller.MainController;
import de.offis.faint.model.ImageModel;
import de.offis.faint.model.Region;
import java.io.File;
import java.io.IOException;
import java.util.Random;

public class Main {

private static final String Imagedir = "C:\\images\\fr";
private static final String faintDir = "C:\\Documents and Settings\\roy\\.faint";
private static final String saperator = "\\";
private static final Random randomGenerator = new Random();
private static final boolean moveThumbnails = true;

/**
* @param args the command line arguments
*/
public static void main(String[] args) throws IOException {
MainController controller = MainController.getInstance();
if (controller != null) {
controller.setScanWindowSize(1);
ImageModel imageModel = new ImageModel(Imagedir + saperator + "mgrp.jpg");
Region[] regions = controller.detectFaces(imageModel, false);
if (regions != null) {
System.out.println(regions.length + " people in the image...");
for (int i = 0; i < regions.length; i++) {
Region region = regions[i];
region.cacheToDisk();

if (moveThumbnails) {
String cacheFilename = region.getCachedFile();

File file = new File(faintDir + saperator + cacheFilename);
File dir = new File(Imagedir + saperator + "faces");
boolean success = file.renameTo(new File(dir, "face_" + randomGenerator.nextInt() + ".png"));
if (!success) {
System.out.println("Error occured whilst moving " + cacheFilename);
}
}
}
}
}
}
}

Hope somebody out there takes the example further and does something interesting with the learning.