The Simple XML serialization framework has released version 1.2. Simple is a serialization framework for Java that intends to provide an XML serialization framework that requires no configuration or mappings to serialize objects bi-directionally; i.e. to and from standard XML. Below is a list of some of the capabilities of the framework.
Simple framework with powerful capabilities
The framework used to provide XML serialization is simple to use and revolves around several annotations an a single persister object used to read and write objects to and from XML. Both serialization and deserialization are fully supported.
It requires absolutely no configuration
Unlike many of the XML frameworks for Java there are no mappings or configuration required to serialize objects regardless of its complexity, not even code to establish mappings. Everything is done at runtime, only annotations are required to perform the object to XML structure. The XML schema is represented using field and method annotations.
Converts to and from human editable XML
A primary goal for the framework is that the XML data used to deserialize and serialize objects is human readable. All XML elements and attributes take a simple structure that can be easily created with a text editor. Also the serialization format is compatible with the C# XML serialization format.
Contains an XML templating system
As part of the deserialization process template markers within the XML elements and attributes can be replaced with variables. This allows the system to be easily adapted for use as a configuration system with dynamic value substitution. Stock template filers include OS environment variable substitution, system properties, as well as an API that enables custom filters to be introduced.
Provides persister callback methods
During serialization and deserialization an object can recieve persister callbacks, to validate and prepare data during the process. Each callback allows the object to manipulate the persistance session, which allows values to be passed in to and out of the templating engine, and allows arbitrary attributes to be passed between the persisable objects.
Allows XML to drive composition
The serialization and deserialization process is controlled by an exensible strategy API, which allows objects to be created based on custom XML attributes. This allows interception of the object creation in order to delegate instantiation to object factories.
Fully self contained
For Java 6 the framework has no external dependancies and is completely self contained. For Java 5 two external JAR files are required, the StAX API and the StAX implementation, both are provided with the download.
Open source
Released under the LGPL and so can be fully integrated or adapted for both commercial and open source projects.
The Simple Home : http://simple.sourceforge.net
Is Java String really immutable...?
In many texts String is cited as the ultimate benchmark of Java's various immutable classes. Well, I'm sure you'd have to think the other way once you have read this article.
To start with, let's get back to the books and read the definition of immutability. The Wikipedia defines it as follows -
'In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.'
I personally find this definition good as it mentions that an immutable instance's state should not be allowed to be modified after it's construction.
Now keeping this in the back of our minds, let's decompile Java's standard String implementation and peep into the hashCode() method -
A detailed look at the above code reveals this to be a classic implementation of the 'lazy evaluation' pattern; i.e. the String class instead of computing the hash value [1] during an instance's construction or [2] computing it each time the hashCode() method is called; computes it once, i.e. on the first call to hashCode(), and saves the computed value in the hash attribute.
Now, here is a test to prove the above quoted statement -
Anxious to know what the output would looks like? Here it is...
So this infers that for a given String instance which we create, but for which we never call hashCode(), the private hash field will remain to be zero. It is only changed when we call hashCode().
Well, don't you find this in contrast with the basic definition of an object's immutability?
One might argue that we can not observe a String instance in a different state without a reflective read of String's hash field and because the call to retrieve the state actually modifies it; if we can't observe it changing.
Well, if one doesn't observe a change does that mean it never happened...?
This reminds me about the other day when i scratched my new car, from below, against an irregular speed-breaker and my friend Manish said that I should not be worried about that because if a scratch is not visible its never been there. Well, is it really never there...?
However it seems like String is not immutable. Although it seems safe, ignoring reflective access, it definitely looks incorrect.
Post me your views around this...
To start with, let's get back to the books and read the definition of immutability. The Wikipedia defines it as follows -
'In object-oriented and functional programming, an immutable object is an object whose state cannot be modified after it is created.'
I personally find this definition good as it mentions that an immutable instance's state should not be allowed to be modified after it's construction.
Now keeping this in the back of our minds, let's decompile Java's standard String implementation and peep into the hashCode() method -
public int hashCode() {
int h = hash;
if (h == 0) {
int off = offset;
char val[] = value;
int len = count;
for (int i = 0; i < len; i++) {
h = 31*h + val[off++];
}
hash = h;
}
return h;
}
A detailed look at the above code reveals this to be a classic implementation of the 'lazy evaluation' pattern; i.e. the String class instead of computing the hash value [1] during an instance's construction or [2] computing it each time the hashCode() method is called; computes it once, i.e. on the first call to hashCode(), and saves the computed value in the hash attribute.
Now, here is a test to prove the above quoted statement -
String string = "MyDearString";
Field field = String.class.getDeclaredField("hash");
field.setAccessible(true);
System.out.println("Before: " + field.getInt(string));
string.hashCode();
System.out.println("After: " + field.getInt(string ));
Anxious to know what the output would looks like? Here it is...
Before: 0
After: -1554135584
So this infers that for a given String instance which we create, but for which we never call hashCode(), the private hash field will remain to be zero. It is only changed when we call hashCode().
Well, don't you find this in contrast with the basic definition of an object's immutability?
One might argue that we can not observe a String instance in a different state without a reflective read of String's hash field and because the call to retrieve the state actually modifies it; if we can't observe it changing.
Well, if one doesn't observe a change does that mean it never happened...?
This reminds me about the other day when i scratched my new car, from below, against an irregular speed-breaker and my friend Manish said that I should not be worried about that because if a scratch is not visible its never been there. Well, is it really never there...?
However it seems like String is not immutable. Although it seems safe, ignoring reflective access, it definitely looks incorrect.
Post me your views around this...
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.
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 –
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.
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. |
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 –
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
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]
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).
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 -
Adieu for now...
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
Adieu for now...
Subscribe to:
Posts (Atom)