 |
|
 |
 |
||||||||
|
 Felipe Gaucho's BlogCommunity: Java Web Services and XML ArchivesShould I use EJB3 as web-services?Posted by felipegaucho on June 02, 2008 at 01:49 AM | Permalink | Comments (4)
Is it a good design to expose EJB3 Session Facade as web-services?Reading patterns and examples on the Internet, EJB3 + @WebService seem to be a fast and furious way to go straight to SOA with few lines of code and a good container. Despite the simplicity of annotations, I started designing an Open Source Classifieds system based on J2EE technologies and I have some observations about that. Instead of replicating here all discussions about web-services design and its technology support, I prefer to bring you a few design options and get your feedback live during Jazoon.
Some considerations about the above design options:
Using a same class to expose services interface and realizing business use cases seems a bit overlapped to me, but eventually I am missing some point here. It is up to you, see you in Zürich :) Configuration Objects: using JAXB instead of java.util.PropertiesPosted by felipegaucho on October 26, 2007 at 03:11 AM | Permalink | Comments (1)Configurable features is a common requisite of computer systems,
and the Java API provides the utility class
Special remind: properties loading using the java API just reads the key/values pair in the memory , it doesn't check its consistency or any data structure related to the configuration. And more: unfortunately the Properties class is locked in the old Properties DTD and it doesn't support nested structures or complex types. It also provides a XML validation mechanism, but it is really too simple to be useful in more complex scenarios - like the one I present below. A real world example where
| ||||||||
| Option #1: several Properties | Option #2: XML file converted in Configuration Object through JAXB |
|---|---|
 |
 |
|
|
Implemented solution: binding XML properties to Configuration Object through JAXB 2.0
The full source code I used to implement my JAXB based properties mechanism is available at the Footprint SVN repository - including the ANT task required to create the XML<->Object binder using XJC. I strongly recommend you to download the footprint source code and try it a bit before checking my conclusions at the end of this blog. Inspecting the code you will start seeing how clean is the application regarding to its configuration properties. I don't have hard-coded String representing the configuration acronyms, and I don't need to verify if the values in the properties are consistent with the values required by the code, it is implicit since we are calling the methods of the Configuration Object that are homonymous to the properties names. Other comfortable feature: if I modify the XML schema or try to change the code in a way both sides become inconsistent, the IDE will notify the problem, avoiding me to crash my own code - the code will not compile before the classes and the properties model become consistent to each other, even under that stressful deadline :)
First step: you first need to create a XML Schema, and then use an ANT task to generate the XML<->Object binder classes, like the one below:
<taskdef name="xjc" classname="com.sun.tools.xjc.XJCTask">
<classpath refid="classpath.base" />
</taskdef>
<target name="compileschema">
<echo message="Compiling the Curriculum XML Schema..." />
<mkdir dir="${jaxb.classes.dir}" />
<xjc schema="${schema}" extension="true"
classpath="${build.dir.classes}" target="${generated.dir}"
package="${jaxb.bindingclasses.package}">
<produces dir="${jaxb.classes.dir}" includes="**/*.java" />
</xjc>
<javac srcdir="${generated.dir}" destdir="${generated.dir}"
debug="off" source="1.5" />
<jar destfile="lib/footprint-config.jar" basedir="${generated.dir}"
excludes="**/*.java" />
<delete dir="${generated.dir}" />
</target>
Before discussing the pros and cons of the JAXB adoption, let me show some code fragments. What we need to do is to load and to use the configuration properties, what is quite easy with the newest version of JAXB. The validation of the XML against its schema is automatic, but I can also implement a finer verification of the properties data using the Event Callbacks mechanism provided by JAXB.
- A code for reading the XML properties file:
@SuppressWarnings("unchecked") public JAXBElementread(InputStreamReader inputStream) throws Exception { JAXBContext jc = JAXBContext.newInstance( AbstractJaxbFootprintStream.FOOTPRINT_CONTEXT, this.getClass() .getClassLoader()); Unmarshaller unmarshaller = jc.createUnmarshaller(); unmarshaller.setEventHandler(new FootprintConfigValidationHandler()); unmarshaller.setListener(listener); SchemaFactory sf = SchemaFactory .newInstance(javax.xml.XMLConstants.W3C_XML_SCHEMA_NS_URI); Schema schema = sf.newSchema(getClass().getClassLoader().getResource( AbstractJaxbFootprintStream.SCHEMA_FILE)); unmarshaller.setSchema(schema); JAXBElement footprintProperties = (JAXBElement ) unmarshaller .unmarshal(inputStream); return footprintProperties; // That's it! From this point I have a Java Object I use to retrieve the configuration values } - After binding the properties to Java Object, I can manipulate
its attributes as any other class:
private void DemoMethod(FootprintProperties properties) { ConfigEmail email = config.getEmail(); setMsgFrom(email.getMsgFrom()); // GOODBYE hard-coded strings like prop.get("msg.from"); } - An optional Unmarshal
Event Callbacks, to check what is being read. Observe in the code below
that I can inspect every element of my configuration, which means I can
stop the application loading if I detect something inconsistent. I am
using this listener also to log what is being loaded. And since I have
a model, I know what any fragment of my configuration file is
about and I can do extra verification on the config values. Eventually
I can also modify the created Object based on custom requirements.
@Override public void afterUnmarshal(Object target, Object parent) { if (target instanceof ConfigEmail) { validateEmailData((ConfigEmail) target); } ... } // Observe I don't need to check if themsgToattribute is present or not // in my property file, the model guarantee that. private void validateEmailData(ConfigEmail email) { String msgFrom = email.getMsgFrom(); Pattern p = Pattern.compile(".+@.+\\.[a-z]+"); Matcher m = p.matcher(msgFrom); boolean matchFound = m.matches(); if (!matchFound) { severe(FootprintConfigUnmarshallerListener.I18N_KEY_EMAIL_MALLFORMED, new String[] { msgFrom }); } }
Conclusions
The implemented code works fine, and despite I didn't stressed too much the tests, I have some observations:
- The loading performance is good, since a regular configuration file is never more than hundreds of values.
- Memory impact: large sets of configuration can cause an explosion of Objects in the memory, and that is a good thing to keep in mind: each element of the XML will instantiate a different Object.
- The complexity of the reading/writing algorithm is similar do
the one required by the
java.util.Properties, and after creating it once you can reuse it later. - The validation and verification of the configuration data are sound and robust processes - much more elegant and safe than using properties files.
- Open the configuration example XML in your preferred IDE, and you will notice the helpful support available there, including highlight and auto-complete features.
- Think about the natural match between the XML structure and the beans editors code out there. It is quite easy to create a GUI that presents to the user a tree with all configuration elements and its respective editors. I started a Swing prototype here, but it is still a pending task. Eventually I will use the NetBeans platform, that gives me a wonderful beans editor support, or even try JavaFX to produce the configuration editor GUI.
A polemic topic is about the large amount of Objects loaded in
memory, what is controversial if you consider what happens when you load
values using java.util.Properties. The properties are
loaded as Strings, what in the worst case means one String object to
each value. Even considering Strings are lightweight objects compared to
complex types, all Strings will be used to instantiate an Object at some
part of your code. One can suggest JAXB is much heavier since it loads
all objects at once, while properties being used by demand will rarely
cause all objects being loaded together. I agree in terms, but I think
JAXB provides a better productivity - reducing the chances of mistakes
and facilitating the verification of the configuration and the code.
Imagine a developer using auto-complete for loading the properties,
instead of checking constants somewhere or including weird hard-coded
String all over the code. It is up to you to think about that.
My overall feeling about using JAXB instead of Properties is very good, I am feeling much more confident to code based on Objects than based on collection of Strings. At the end, both approaches are quite similar in terms of logic, but since I am an Object Oriented developer, I prefer to manipulate objects than lists of values - the old fashion procedural approach.