Anteo Java News: Spring 2005
The last edition of Anteo Java News, the newsletter for the Java Professional, was even more of a success than the launch! More than 50% of the subscribers read the email with 40% click throughs and no opt outs, so the email is not only being read by qualified readers, but so are the articles! As always, we appreciate and welcome all of your comments and submissions as we are tailoring the newsletter for you. Please send any comments and/or submissions for future articles to Anteo Group Marketing. To receive Anteo Java News by email, contact us.
Thanks and enjoy!
Modern Day Java
By: Marty Trujillo
Modern day Java/Web development contractors face a multitude of challenges every day. In my experience, many of the more complex challenges are a direct result of professionals from different disciplines contending for access and making modifications to common resources. Simply stated, it’s rarely a good thing to have artists and authors mucking around in the source code or having programmers writing content or fiddling around with the layout.
Anyone not familiar with web development might ask why in the world do these people from different professions step all over each other’s work. Well, unlike most mature technologies logical, artistic, and contextual resources are often tied directly together in JSP or ASP files. For the purposes of this article the following definitions apply.
Web Content – The text you read on a web application. In most web applications this includes labels, instructional text, icons, and informational text.
Web Design – The aesthetics of an application. In most web applications, this includes the layout, color, and imagery (logo and such).
Web Logic – The brains of an application.
The problem with all three of these functional areas being implemented in a single file is that the programmer may spend countless hours implementing business logic into a file, just to have the logic inadvertently modified by a well meaning author or designer. This common file issue can be very frustrating and create very complex problems for all involved. Fortunately, there is a relatively straight forward solution to this problem.
By carefully implementing four technologies into web applications the functional areas described above can be separated from each other. This separation allows content specialists, designers, and programmers to work in harmony. These four technologies are Java Beans, JSTL (Java Standard Tag Libraries), JSP Custom Tags, and CSS (Style Sheets).
If implemented properly:
- All logic will be in the Java Beans and Custom Tags (along any other Java Objects the beans and custom tags use).
- The design will be found in the CSS where the layout, colors, fonts, and positions of web elements can be controlled.
- The content will be found in the JSPs or possibly various configuration/properties files.
In this article, I described a typical problem and identified the technologies that can be used to avoid the problem. In future articles, I will describe each technology on their own and then sum up with some successful strategies for blending them together and separate the content, design, and logic from each other.
Deliverable Artifact and Build Management with Maven
By: Matthew Daniel
In the last issue of Anteo Java News, we saw how Maven uses a declaration to identify the output artifact. Now let's expand that bit more and talk about Maven's concept of a deliverable artifact. In the most basic terms possible, a deliverable artifact is one JAR file or, its renamed children: WAR, RAR and EAR. There have been some pretty heated arguments in the forums about whether this is a Good Idea(tm) or not. Chances are, if you ard/or your organization does not subscribe to this theory, then you probably won't like the rest of Maven, either, since it's relatively strict about its view of software engineering best practices. Maven also separates actual Java sources from non-deliverable code, such as the testing sources (more on this later) and any AspectJ [http://aspectj.org] sources.
The default behavior for Maven is to identify the role a particular file plays in the build process via its location in the project's filesystem hierarchy. As a concrete example, EJB sources live in "src/java" but its "ejb-jar.xml" lives in "src/ejb/META-INF" and any testing sources live in "src/test". This facilitates finding exactly the right file in any project built by Maven, across projects and even organizations.
Build management is not simply getting your sources to compile and copying them to the right place, otherwise makefiles would be more widely used. If you or your organization strives for CMM, or even just being a software engineer instead of a programmer, there is more to declaring "success" than just getting your command prompt back. You want to be able to assert that the code you've produced does what you said it would in the way you said it would. You want your project to be as self-managing as possible so you can get on with solving hard problems and less time writing reports and copying files all about.
Maven really shines here and this paragraph is probably how you're going to get buy-in from your manager. Maven considers a successful build to be one where the sources compile, all the unit and automated integration (if defined) tests pass, the most current documentation is built, the code is committed to the change management system and all output artifacts are deployed to their proper locations.
Maven will run all of these steps, automatically, repeatably and almost all of these steps will be driven from about 20 lines of XML in its project descriptor. Maven will generate not only JavaDoc for your sources, but tons of reports that describe the state of your deliverables from many perspectives. Some especially interesting reports include which unit tests executed, optionally including the test coverage, file activity by developer, source cross-reference and finally (whew) build the website describing what your artifact is/does and any usage documentation that is not really appropriate for JavaDoc. Using about 20 lines of XML. Spend less time hacking on shell scripts and more time solving problems.
Here we have seen how software engineering tools are not just about modeling tools and pretty pictures. Software engineering is about repeatability and validity assurance. Maven is one of many tools that will help you achieve those goals and much higher ones. It moves the more mundane parts of development out of your way, but not out of your process. In many ways, Maven will make you a better software engineer since it will not let you skimp on running unit tests when you compile and will announce to the world how far along your project currently is. It has been the author's experience that switching from Ant to Maven is very similar to the transition from procedural to object-oriented programming: once you've tasted the Kool-Aid, you can never go back.
Supporting Applications Using Service Oriented Architectures: Part II
By: John Neal
A Real World Example
After reflecting on the various aspects on delivering these services lets concentrate on a real world example on how to pass information from one system to another. In this example we are going to use JAXB to marshal and unmarshal XML that is sent from the requesting system via JAX-RPC.
In figure 2 we see an example snippet of an XML schema containing data that we want to pass through the service delivery plane and be consumed by the activation and discovery layer. This example passes information needed to provision a UNIX server with various services such as DNS, User and Group Permissions, directory structures and other information needed for a data center to properly configure this server (the schema is not the complete schema that is used in the real system).
What we need to solve this problem is a new generation of platforms designed to support these distributed and changing applications. We want to first take a generic approach to supporting these systems by introducing application and content based services. We next need to look to open source and third party approaches such as found in the J2EE and open source projects, i.e., frameworks such as struts and Java Server Faces, web services such as SAAJ and JAX-RPC and the like. We also have to go one step further and look for an introduction of network based services to support our underlying J2EE infrastructure.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
jaxb:extensionBindingPrefixes="xjc"
jaxb:version="1.0">
<xs:annotation>
<xs:appinfo>
<jaxb:globalBindings generateIsSetMethod="true">
<xjc:serializable uid="12343"/>
</jaxb:globalBindings>
</xs:appinfo>
</xs:annotation>
<xs:element name="cscape" type="CscapeType"/>
<xs:complexType name="CscapeType">
<xs:sequence>
<xs:element name="request" type="Request"/>
</xs:sequence>
<xs:attribute name="version" type="xs:string" use="required" />
</xs:complexType>
<xs:complexType name="Request">
<xs:sequence>
<xs:element name="solution" type="Solution"/>
</xs:sequence>
<xs:attribute name="guid" type="xs:string" use="required" />
</xs:complexType>
<xs:complexType name="Solution">
<xs:sequence>
<xs:element name="vtier" minOccurs="1" maxOccurs="unbounded" type="Vtier"/>
</xs:sequence>
<xs:attribute name="guid" type="xs:string" use="required" />
<xs:attribute name="name" type="xs:string" use="required" />
<xs:attribute name="version" type="xs:string" use="required" />
</xs:complexType>
.
.
.
Figure 2
To create the actual Java classes needed for JAXB to turn the data into XML we need to run our schema through a generator that will generate a hierarchy we can load with data to then call a command to marshal this data into XML. To do this we use ant to call the JAXB compiler found in the Java Web Services Developer Pack in the package com.sun.tools.xjc.XJCTask giving it the package name we want our classes to end up being created in. The JWSDP contains examples of the ant build files to use to generate the Java classes.
At this point we are ready to actually fill our classes up with data and then we can create the xml by marshalling the data. To do this we need to know the URL of where we want to call the web service that we will pass our data forward to. Some of the packages needed to perform these calls are java.net, org.apache.xmlrpc, and org.xml.sax. The first step is to tell JAXB what package we are using to marshal the data.
JAXBContext jc = JAXBContext.newInstance("com.test.xml.request")
Next we must create the XML Object tree. In this example we are passing in the solution ID, which is a UUID generated from the java.rmi package, and the vtier ID which is also a UUID.
Object xmlObjectsTree = createXmlObjectsTree(solutionId, vtierId);
Inside the method we must create the objects needed to be filled up with our data. In this case we get the object factory and we create the high level object CScape and then the request and solution objects objects that we found in our XML schema.
private Object createXmlObjectsTree(int solutionId, int vtierId)
throws JAXBException, Exception
{
ObjectFactory objFactory = new ObjectFactory();
Cscape cscape = objFactory.createCscape();
Request request = objFactory.createRequest();
Solution solution = objFactory.createSolution();
.
.
.
We then fill up some components with data.
request.setSolution(solution);
solution.setGuid("0c8b8c00-0100-11d9-9669-0800200c9a66");
solution.setName("test solution");
solution.setVersion(1);
.
.
.
After we set our objects data we then have to create the xml. The following method call returns the XML as a string.
String xmlString = createXml(xmlObjectsTree);
We first have to create our Marshaller which will allow us to get back our xml. We then tell it to give it back in a specific format and then we take that tree, pass it into the marshal method and return the output as follows:
private String createXml(Object xmlObjectsTree)
throws JAXBException
{
Marshaller m = jc.createMarshaller();
m.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT, Boolean.TRUE);
StringWriter buf = new StringWriter();
m.marshal(xmlObjectsTree, buf);
return buf.toString();
}
The xml created will look something like this (figure 3).
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<cscape version="1.0">
<request guid="1fc4bec:10023ec03c4:-7ffX">
<solution guid="0c8b8c00-0100-11d9-9669-0800200c9a66"
name="test solution"
version="version">
<vtier guid="0c7b7c00-0100-11d8-9669-0800200c9a99"
envtype="prod"
hostname="wslenv08"
platform="IBM-7025-F50"
vtiername="q5dplyw1"
operation="create"
serveripaddr="10.85.104.146"
netdns=""
hostalias=""
vtieripaddr="10.108.13.10">
<hacluster clustername=""
hatype=""
primaryserver="prc-srv-23"
resource="d1kjso1-res"
resourcegroup="d1kjso1-rg"
diskgroup="d1kjso1-ds">
<failoverserver>wsp1cm02</failoverserver>
</hacluster>
<account acctname="d1kjso1ro"
homedir="~/d1kjso1ro"
primarygroup="d1kjso1ro">
<addtogroups>d1kjso1or</addtogroups>
</account>
<directory directory="~"owner="d1kjso1"
dirgroup="d1kjso1"
permissions="755"/>
</vtier>
</solution>
</request>
</cscape>
Figure 3
Next we have to then call a method that will use JAX-RPC to send our xml over the network to a web service waiting for that request.
sendRequest(xmlString);
We firstcreate an XmlRpcClient passing in the url of our web service. We then create call the execute method giving it the method name we want to call and pass the xml to it.
private Boolean sendRequest(String xml)
throws IOException, XmlRpcException, SAXParseException, Exception
{
// Specify the service location
XmlRpcClient client = new XmlRpcClient("http://localhost:8080/");
// Make a request
return (Boolean) client.execute("ScdeService.setRequest", xml);
}
As we can see, we can create all these elements with Java and send the data across our networks. We only need the schema and WSDL and UDDI's complexity is not needed. It is a simpler approach to sending data to our service consumers. You can find out more about JAXB and JAX-RPC by following these URLS:
JAXB at http://java.sun.com/xml/jaxb/
JAX-RPC at http://java.sun.com/xml/jaxrpc/index.jsp
Current Openings
For our most current openings, click here.
back to newsletters >
For more information about the Anteo Group, contact us.
