Sunday, December 30, 2007

JCP approved JPA 2.0 (JSR-317)

JCP (Java Community Process) has approved next version of Java Persistence API (JSR-317). Here is the link: JSR-317 (JPA 2.0).

The scope of JPA 2.0 is :

  1. Expanded object/relational mapping functionality, including greater flexibility in combining existing mapping options, support for collections of embedded objects, multiple levels of embedded objects, ordered lists, combinations of access types, etc.
  2. Additions to the Java Persistence query language
  3. An API for "criteria" queries
  4. Standardization of sets of "hints" for query configuration and for entity manager configuration
  5. Standardization of additional metadata to support DDL generation and "Java2DB" mapping
  6. Expanded pluggability contracts to support efficient passivation and replication of extended persistence contexts in Java EE environments
  7. Standardization of additional contracts for entity detachment and merge, and persistence context management
    Support for validation

Its good to know that JPA 2.0 would include criteria API. I've been using Hibernate for last couple of years and have always liked criteria-API.

Almost all leading companies (including IBM, BEA, Oracle, Red Hat Sun etc.) have voted 'Yes' for this specification. Apache has voted 'No' on the ground that this spec lead - Sun - is in violation of the JSPA http://www.apache.org/jcp/sunopenletter.html and therefore shouldn't be allowed to start another JSR until the above matter is resolved. (Link: Voting Result)

Link: SUN's presentation on JPA 2.0 in JavaOne Conference 2007

Saturday, December 29, 2007

Watch out for JBI 2.0

Currently, JBI 2.0 specification is in progress. It is expected to be finalized in Q1 of 2008. The JCP reference for JBI 2.0 is JSR 312. [Link to JSR 312]

The scope of JBI 2.0 includes followings:

  • Enhancements to facilitate the use of JBI in clustered or distributed environments, principally with respect to administration rather than the clustering/distribution mechanism itself.
  • Enhancements to clarify and enhance the use of JBI in a SOA-based approach to the creation, deployment and runtime support of Composite Applications.
  • Enhancements to support requirements stemming from WS-Policy.
  • Enhancement to support Web 2.0 technologies and usage models.
  • Introduction of a Message Exchange handler/interceptor model.
  • Enhancements to facilitate performance optimizations by component and container implementers.
  • Improved alignment with Java EE (e.g. use of transactions).
  • Recoverability of Message Exchanges.
  • Improved readability of the specification to clarify the needs of container, component and application developers.
  • Alignment with the Service Component Architecture (SCA) specifications (see www.osoa.org) with the goal of making JBI 2.0 a standard Java runtime for SCA .
  • Enhancements to support full compatibility with OSGi, without necessarily requiring OSGi.
  • Technical issues stemming from implementation experience using the JBI 1.0 specification (e.g. life-cycle of components, error handling, interop profiles, examination of the utility of WSDL definitions for non-Web Services deployed components, component attributes, threading, NIO use, classpath or endpoint activation)

The above list is taken from the proposal of JSR 312. I am more interested in the highlighted items. One of the most important drawback of JBI 1.0 is that its Normalized Message Router (NMR) is not based on a messaging system, but it is an in-memory router. It makes it a single point of failure in the system. I hope that the scope named as "Recoverability of Message Exchanges" address this issue.

Friday, December 28, 2007

Is JBI 1.0 true ESB?

Sun has taken a big leap with new integration specification JBI 1.0. The JCP reference for this specification is JSR 208. The specification is available here for download: JBI 1.0 Specification.

One of the key component of JBI 1.0 is Normalized Message Router (NMR). It routes normalized messages from the source component to its destination using some kind of routing policy.

In a true ESB based architecture or product, the integration is based on a messaging system, which acts as a message broker. The role of this message broker is to provide abstraction between application components. It routes the message from one component to another component, and the components are not aware of location of each other. It provides following functionality:

  1. Reliability: In case of failure or unavailability of any component, the messages are persisted in a queue.
  2. Scalability: The end point of ESB can be deployed on multiple servers. These servers are linked together with the messaging system. The ESB knows the location and type of services deployed on each server. It uses this information to route the messages to its destination.
  3. Security: Transport level or message level security can be provided by the messaging system while transporting the messages from one server to another server.

In JBI 1.0 specification, the Normalized Message Router (NMR) is expected to play the role of message-broker for the ESB. However, the NMR in JBI 1.0 is designed as in-memory message router. It is not based on any messaging system. Therefore, it does not provide all the functionality of the message broker of a true ESB. Moreover, it becomes a single point of failure. In case JBI 1.0 based server crashes, the in-transit messages are lost.  In my opinion, JBI 1.0 based product does not qualify for a true ESB solution.

David Chappell paper : Introducing SCA

David Chappell has written a nice paper on SCA technology: Introducing SCA

The paper explains the concept of SCA and its attributes (components, composite, domains etc.). It includes samples of new SCA components. To learn SCA, this paper is a good starting point, which covers all the basics of this new technology.

The SCA specification defines:

  1. A new programming model to create services. For example: creating EJB is a programming model, which the developer defines classes & configuration files following EJB standard. The EJB is deployed in an EJB container, and the ejb-attributes (security, transaction etc.) are defined in the deployment-configuration file. In similar way, SCA defines a new programming model to create classes and configuration files. These classes and configuration files are deployed on SCA runtime (Example: Tuscuny).
  2. Composition of components: SCA specification a new method to create composite components. This is very much similar to orchestration. The orchestration is defined using BPEL like language. In this case, it is defined in the configuration file of SCA. One component gets reference to another component using inversion of control pattern. So, if one component composes of another, it is defined with annotation  "@Reference". The reference is defined in the configuration file. It is the responsibility of SCA runtime to create the object and make it available to the parent class using getter/setter.

However, it briefly touches some advanced (but important) aspects of any services. Well, this paper being the introduction, the advanced topics is out of scope for this papers. The topics, which I am referring, are:

  1. Transaction Handling
  2. Security Implementation
  3. Development Tools
  4. Runtime
  5. Monitoring (SCA does not specify standard MBeans)

A new SCA transaction-policy specification (draft version) is published on 3rd December 2007 (Link: SCA Specifications). I have not reviewed it so far.

Thursday, December 27, 2007

Is Agile Software Development process effective for large projects?

Recently, I worked on a project following Agile development process. The size of the project was big including a J2EE Web application, integration using an ESB product and Web-Services. The development teams were located at two places in USA and one in offshore (India). Before start of the project, the client decided to use Agile process for this project. I had worked on other development process such as RUP, SDP, Waterfall etc. This was my first experience with Agile process.

Principles of Agile Process

Following principles of Agile Process were followed:

  1. The requirements were captured in the form on user stories. There was no formal requirement or use-case document for the entire project.
  2. The project was executed in iterations. In one iteration, few user stories were selected for implementation. During selection of user stories for one iteration, it was ensured that the implementation time would not be more than 4 to 6 weeks.
  3. The development team, business analyst and testers sit in one big conference room at all three locations. There was one hour of meeting daily to keep track of development, issues and other items.
  4. The development started on the very first day. The developers were given the user stories, and list of frameworks/tools to start the project. The developers had marathon meeting to discuss the implementation strategy. They divided the work and started coding.
  5. Business analysts and testers worked with developers to assist in understanding the requirements and testing the deliverables.
  6. Each iteration delivered a new version of application for deployment in production.
  7. The requirements were not static. It could be changed anytime during development.

This process was followed for few iterations, and we started seeing problems with this approach.

Problems with Agile Process and Lessons Learnt

  1. No Requirement Document: Agile process recommends to minimize the documents. And, the requirements can be changed by the customer anytime. This creates a lot of confusion to the customer. A lot of time is wasted in discussion with the business analyst in finalizing the requirements. As analyst is not bound to freeze the requirement, the developers are always in the state of uncertainty that the change may be coming soon.

    This creates more problems to the project manager specially in case of fixed-bid contracts. Since the scope of the iteration is not defined, it becomes difficult for the project manager to mange the scope of deliverables. Agile process says that "Forget about Change Requests", which is good for the client but not for the consulting/contracting company.
  2. No Design Document: The developers are expected to discuss the implementation approach and start development as soon as the user story is received. Now a days, the applications (Web or Integration) are so complicated that you need a good framework and abstraction around common functionality. This improves consistency and reuse.

    In Agile process, there is no time allocated to develop the common framework to be used by all developers. In absence of the common framework, each developer tends to write code in its own style. This creates huge inconsistency. The problem compounds when the teams are sitting in different locations and different time zones.
  3. Senior Developers only: The developers are expected to discuss the architecture & implementation strategy, and start programming. This requires that the developers must have good experience in developing similar applications. For junior developers, it was always a challenge to understand all the decisions taken during the discussion and start implementing it.
  4. No Team Lead / Supervisor: All developers are expected to work on certain deliverables. Usually, there is only one leader in Agile process, who manages the entire development cycle. But, the leaders responsibility is very much similar to a project manager which includes managing the user stories, scope of iterations etc. The developers work on own. In large projects, (as per my experience) technical and QA leads are very important to manage the deliverables. Without a lead, each developers tend to follow its own design patters, coding practice resulting in poor quality, duplicate work and inconsistency.
  5. Incremental Deliverables: The project is divided into user stories and the life of an iteration is around 4 to 6 weeks. Each iteration creates a version of the application to be deployed in production. If the application is actually put in production and is used by the end-users, it requires migration effort for each iteration. For large projects, the requirements are built incrementally, the database is changed in each iteration. This requires migrating data in the end of each iteration, which becomes a signification effort (but not useful) by the end of the project.
  6. Managing Large Developers: If a large development team is working, it becomes difficult to allocate work to each developer for a 4-6 weeks development cycle. Few developers get a lot of pressure and few get a lot of time for "Googling/Coffee/Smoking".
  7. No Task Level Schedule: Usually, the only task defined for an iteration is to implement the user-story. This becomes difficult for the project manager or lead to keep track of the progress. Changing requirement adds more problems to it.

Conclusion

Looking at pros and cons of Agile Development Process, I feel that it may be good for small projects or the maintenance/upgrade projects. In these cases, as the framework and other documents/tools are already created, there is a baseline. The upgrade would require minor and local changes, which can be managed very easily and effectively in terms of user stories and small iterations. For large projects with large development team & multiple development sites, Agile Development Process may not be a good choice.

Friday, October 5, 2007

How to avoid XSS security threat using Spring MVC

XSS (Cross-site Scripting) is one of the most common vulnerabilities with a web-application. And, it can be exploited by hackers very easily without using any sophisticated tool.

How does it work? Most web-applications have forms (text-box etc.) to receive input-data from user. So, a web-application may have a input-text-field to get 'user-id'. The hacker may enter anything in it including "JavaScript". If the hacker enters JavaScript (a malicious code), the server may process it, and then return it. In this case, user-id is not authenticated and it is sent as it is on the error page.

If the user's input data is returned as it is, the java-script code may execute. And, hacker wins!!

To explain further, the jsp-code may look like as shown below (using Spring MVC Form Tags):

1 <form:form id="personForm">
2 <form:input path="name" />
3 <input type="submit" value="Submit">
4 </form:form>

This will show a simple screen with an input-box and a submit button. The hacker may enter following code:

1 ">Hacker<script>alert("I am destroyer");</script>

When the page is submitted, the page is returned with error as the user is not authenticated. The error page will have the 'name' value too. In this case, the expanded page would look like:

1 <form id="personForm">
2 <input type="text" name="name" value="">Hacker <script>alert("I am destroyer");</script>"/>
3 <input type="submit" value="Submit">
4 </form>

And, while loading this page, the browser may run the script. The hacker may put anything as the java-script.

What is the solution? HTML 4.0 defines 252 Character entities (escape sequences), which include most of characters (excluding alpha-numeric) used to design HTML pages. If the input-text is changed into the html-escape-sequences during processing on server, then browser will receive the escape-sequences. The resultant text would not be a valid java-script and browser will not execute it.

After conversion into html-escape-sequences, the above code would look like:

1 <form id="personForm">
2 <input type="text" name="name" value="&quot;&gt;Hacker&lt;script&gt;alert(&quot;I am destroyer&quot;);&lt;/script&gt;"/>
3 <input type="submit" value="Submit">
4 </form>

Since all instances of characters '<', '>' and other non-alpha-numeric characters are converted into html-character-sequence, it is no longer a java-script code. So, it will not be executed by the browser. For more information on HTML-escape-entities (escape sequences), refer WiKi: http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references

Solution with Spring MVC In Spring-MVC, form-tags are used to create jsp page. Spring MVC provides multiple options to encode the html-escape-sequences on server side.

  • At global level, it can be defined in web.xml file. This will be applicable to entire application. All form-tags would refer to this definition. The sample code is shown below:
1 <context-param>
2 <param-name>defaultHtmlEscape</param-name>
3 <param-value>true</param-value>
4 </context-param>
  • At page level, it is defined as a tag-declaration. The code is: Any form-tag, after the above declaration uses html-escape-sequence-encoding.
1 <spring:htmlEscape defaultHtmlEscape="true" />
  • Third option is to define it as attribute for each form-tag. For example, a input-text can be defined as :
1 <form:input path="name" htmlEscape="true" />

Depending upon requirement, it can be implemented as global, page or tag level.

For more information on XSS, you can refer WiKi: http://en.wikipedia.org/wiki/Cross-site_scripting

Tuesday, October 2, 2007

Understanding XML Digital Signature

I found a nice article on XML digital signture. It explains in detail the structure of the information stored in various xml-fields/ infosets. As well, it explains how the digital signature is created and stored in XML. This is very useful in understanding WS-Security. Here is the link to the article: http://msdn2.microsoft.com/en-us/library/ms996502.aspx

Wednesday, April 4, 2007

Download Options: Eclipse SDK, Eclipse Platform Runtime Binary & Eclipse Platform SDK

Eclipse SDK The Eclipse SDK includes source, binary, user-guide and programmer documentation of the following components:
  1. The Eclipse Platform,
  2. Java development tools,
  3. Plug-in Development Environment,
However, Eclipse SDK does not include a Java runtime environment (JRE). Developer should download package (Eclipse SDK) and install other required plug-ins using Update Manager. Eclipse Platform (Runtime Binary And SDK) Eclipse Platform can be downloaded seprately in two versions:
  1. Platform Runtime Binary: It contains the binary of Eclipse platform. Source & documentations are not included in this version.
  2. Platform SDK: This version includes the platform runtime binary, source and programmer documentation.
Java development tools are created using Eclipse Platform SDK. Eclipse 3.2.2 is available for download at this link: http://download.eclipse.org/eclipse/downloads/drops/R-3.2.2-200702121330/index.php

Difference between java.exe and javaw.exe

Both commands (java.exe and javaw.exe) are identical. The only difference is that java.exe is associated with a console (Command Prompt), where as javaw.exe is not associated. When java.exe command is invoked, a 'Command Prompt' window is opened automatically. By default, Standard Output and Standard Error streams are directed to the console window. Since javaw.exe is not associated with any console, the text in Standard Output and Standard Error streams is not visible. However, these streams can be directed to a file by using the methods System.setOut(…) and System.setErr(…).

How to run Eclipse?

When you unzip the Eclipse SDK, it creates a base install directory called eclipse. The directory layout looks something like this: eclipse/
  1. features/ ''the directory containing Eclipse features''
  2. plugins/ ''the directory containing Eclipse plugins''
  3. eclipse.exe ''platform executable''
  4. cpl-v10.html ''the CPL license''
  5. install.ini
  6. jre/ ''the JRE to run Eclipse with'' (This may not be present)
  7. notice.html
  8. readme
  9. startup.jar ''classes needed to start the platform''
If available under the eclipse/jre directory, the Eclipse JRE will be used; otherwise the launcher will consult the JAVA_HOME system path variable. To explicitly specify a JVM of your choice, you can use the -vm command line argument: eclipse -vm c:/jre/bin/javaw.exe Another option is to put startup configuration into an eclipse.ini file. The Eclipse program launcher will read arguments from either the command-line or the configuration file named eclipse.ini. To specify a JVM using configuration file, create a text file named eclipse.ini in the same folder as eclipse.exe with these contents: -vm c:/jre/bin/javaw.exe You should always use -vm so you can be sure of what VM you are using. Installers for other applications sometimes modify the JAVA_HOME variable, thus changing the VM used to launch Eclipse without your knowing about it.

Monday, February 26, 2007

FAQ on Windows CE and Pocket PC

1) What is embedded computing?

Typically, embedded computing refers to any computer system or computing device that performs a dedicated function or is designed for use with a specific embedded software application. These are systems that the end user typically cannot modify. What is distinct about an embedded operating system? Embedded operating systems are usually highly customized for a specific task or function. They may be optimized for specialized hardware or a specific application. Since the configuration can be "locked down" and therefore rigorously tested, manufacturers of these systems can control costs and deliver highly reliable devices optimized for specialized tasks.

2) What is the difference between Windows, Windows XP, Windows XP Embedded, and Windows Embedded?

The term Windows includes a broad range of Microsoft technologies and products and is often used to refer to the desktop operating system. Windows XP is the latest desktop operating-system software and is available in multiple versions for business and home users. The term Windows Embedded refers to the Microsoft family of embedded operating systems for smart, connected, and small- or reduced-footprint devices. The Windows Embedded family includes a range of products all based on the Windows Embedded CE and Windows XP Embedded platforms. Windows XP Embedded is a specialized operating system, consisting of componentized Windows XP Professional features and an end-to-end set of development tools, for use in non-personal computer (non-desktop) devices. Windows XP Embedded is typically used by embedded developers, system integrators, and Original Equipment Manufacturers (OEMs).

3) What is Windows Embedded for Point of Service?

In October 2004, Microsoft announced the development of a standard, retail-optimized operating system platform designed for retail point-of-service systems—Windows Embedded for Point of Service. Based on the technologies available in Windows XP Embedded with Service Pack 2, Windows Embedded for Point of Service enables the Microsoft Smarter Retail Initiative and is an easy-to-use point-of-service platform optimized for the retail industry.

4) What is Windows Automotive?

Windows Automotive is based on the Windows Embedded CE real-time embedded operating system. While it shares the rich platform and services of Windows Embedded CE, Windows Automotive enables features such as voice recognition technology, automotive power management, and other automotive-specific options. More FAQs are available on Microsoft's Website.

Difference between Windows CE and Pocket PC/ Mobile

Windows CE is a collection of operating system components, which is available to developers and device manufacturers to create customized embedded devices. Device manufacturers (which includes Microsoft too) can use Windows CE .NET to build both a customized OS and applications for a variety of devices requiring a small-footprint. Microsoft built Windows Mobile software for the Pocket PC on Windows CE by adding new functionality, user interface, and applications to create an optimized mobile computing platform for handheld devices. Other companies can built another Windows Mobile type operating system using Windows CE too. In Windows Mobile, Microsoft has added Mobile version of its Office Applications (Word, Excel etc.) and many other features on top of Windows CE. Platform Builder is the integrated development environment for building, debugging, and deploying a customized embedded OS based on Windows CE . For detail information on comparison between Windows CE and Windows Mobile, refer Comparison Document on Microsoft's Website.

Thursday, February 22, 2007

Handheld RFID Readers - Wireless Security Issue

The standards for cryptography of data over wi-fi network are:
  1. WEP (Wired Equivalent Privacy): WEP is part of the IEEE 802.11 standard released in September 1999. Several serious weaknesses were identified by cryptanalysts. And, it is a fact that any WEP key can be cracked with software readily available over internet in few minutes.
  2. WPA (Wi-Fi Protected Access) WEP was superseded by Wi-Fi Protected Access (WPA) in 2003, and then by the full IEEE 802.11i standard (also known as WPA2) in 2004.
  3. LEAP (Cisco Wireless EAP) Meanwhile, Cisco developed LEAP (Lightweight Extensible Authentication Protocol) based on EAP type specified by IEEE 802.1X to provide Wi-Fi security. LEAP is a proprietary system that doesn't fit on a network open to a variety of devices, from standard PC laptops to Macs and handheld devices.

Enterprise wireless network implements WPA or EAP based security solution. Handheld RFID reader uses WLAN to connect to the Access Point and routes the tag-events. The data can be sent over tcp/ip or http. To connect to a wirless Access Point, the handheld RFID reader must support the implemented wireless security protocol.

Based on my research last week, it seems there is no handheld RFID reader currently available in the market which supports LEAP protocol. The industry leaders, such as Symbol, are working on to provide support to the LEAP and WPA protocols. This is a serious limitation in deploying RFID solution using handheld readers in a secured wireless network.