Wednesday, April 16, 2008

Sam’s Agile Application. MP & ANT


Sam’s Agile Application.

First thing I needed to decide was whether how many hours from my day life I would be able to spend after this application (Along with my busy schedule at office)?

I just realized not more than 2 and not less than 1. So there it goes.

Microsoft Project

I installed Microsoft Project today. Just going through estimation of chapters. I like the some of its features like

1. Creating project based on your own calendar. In my case I needed something just like that. My working times are not as per some office times so it allowed me to properly estimate them based on hours.

2. Other feature is Task and subtasks dependency. I can directly drag and drop task behind each other to set them up in proper order.

I still need to see some of the areas where I can use in it pair programming and how it helps in assigning project task to different people. Because on that bases only I can estimate task for team. Right now with only one member in project (that me) it was easy to finish of the Project estimation phase. But believe me it wasn’t that easy as it sounds here. Even Microsoft was bad at documenting every aspect of project. I find its Help content very poor. Ya but I won’t be better person to judge it here.

Anyways moving along.

ANT

I started working with Ant. I have eclipse IDE which comes with in built support for Ant features. But as I wanted to avoid the ready made programming with IDE for time being. I installed Ant on my PC. Things went well, especially documentation. I read through some of its basic tutorial pages. After messing with my Environment variable and PATH variable I finally managed to run in from my application folder. I created a simple java file and was able to build it as jar at the end of the day.

I wonder what it would have been without Ant before rise of IDEs. Believe me it would have been chaos. Ant makes life a simple. I remember my organization using this Ant build file when I was new to IT world. Still I’ve not created build.xml file on my own. My tomorrow’s target would be to create one which builds and application for me.

Thursday, April 3, 2008

TimeSheet Agile Application.


TimeSheet Agile Application.


Well, Being in industry and only working through daily stuff at office narrows your knowledge about other technology sometime. So I finally decided to try my hands on some other technology as well. I’ve worked on Spring before (Spring JMS API) it made me fall in love with Spring framework power. And it finally ended up in reaching to this application.


I always preferred learning any new technology from it book so first thing I’ve always done is to WASTE my time finding book related to the technology for quite sometime. Then with 400 to 500 pages in that book I’ll start my session with behind the scene phase of that book. And after a week or so I’ll end up in watching that book getting dirty inside my book self. Ouchhhh. That hurts, seriously, I’ve always been disappointed with my that approach.

So for the first time I want to reverse the procedure of accumulating my knowledge ‘well’. I came around this book “Sams.Agile.Java.Development.with.Spring.Hibernate.and.Eclipse.May.2006.pdf” by Anil Hemrajani and decided to give my hand to complete. One reason to write this blog is that at least I won’t like to waste my efforts that I’ve given in writing this blog. So I expect this project to complete. The project is regarding developing an application with the use of Hibernate, Spring and few other technology which includes Ant, JUnit, HSQLDB & Apache tomcat and most of all it’ll go through the software development process which will give me some idea(enrich my knowledge) about how to do it and which way to use to do it.

RULE 1:

NO HURRY NO WORRY!!!!

I’m not in any hurry to finish this project. Ya of course I’ll setup a dead line for this project but still I don’t want to get in to so much hurry that I’ve to skip some part of this project. So my project completion estimation is going to be on the unit of Days not hours(As I’ve personal & social life to deal with ha ha ha!!

I’ve already been through First few chapters of this book and it’s all about giving you idea on XP and AGILE methodology for development of this application. I’ve already gathered user requirements as part of process, though the requirement have been specified in the book itself.

The XP project life cycle

I’ll list out user requirements them first of all.

  • Hourly employees should be able to sign in to a web application (once or more each week) and enter their hours for each day of a given week.
  • Along with the hours, the employee must select which department the hours are being billed to.
  • Employees will be required to submit their timesheets each week.
  • An employee's manager is notified of successfully submitted timesheets. The manager must then approve or disapprove the timesheets.
  • After a timesheet is approved or disapproved, a notification is sent back to the employee indicating the updated status of the timesheet. If the timesheet is approved, an email is also sent to the accounting department to process the pay check for the given employee.
  • All users of Time Expression will have one or more relevant reports available to them.
  • A weekly reminder email will be sent out to employees who have not submitted their timesheets. Another reminder email is sent to managers who have employee timesheets pending approval.

Going through all these Use stories author has given priority for each user story as below.

Table: User Stories, Priorities, and Estimates for Our Sample Application

$$$

I don’t want to go in to detail about discussing the software development methodology used for this project as that will again switch my focus. Discussing them will be taken out as a totally separate activity in some other blog.

Following is the UI Diagram identified from user story:

$$$

First and foremost thing I’m doing right now is working out for project estimation for me.

PROJECT ESTIMATION:

Hardest thing I find during lifecycle of project is Project estimation. Actually I’m always worried about giving deadline and not meeting them. Reasons for not being able to meet deadline for me can be some of:

1. Estimations are not given by me.

2. When you expect me to work on two or three other tasks as well.

3. SAMAJ SEVA. (Helping others)

4. My own laziness. (Many times).

Anyways rather than giving my rough estimation about how I’ll go through given chapters, finally I’ve decided to get use to some tool for estimation. It doesn’t help me by much but still just as part of industry process I’ve decided to learn Microsoft Project for the same.

Wednesday, April 2, 2008

Spring JMS Template

It provides a template mechanism to hide the details of a typical JMS implementation so developers can concentrate on the actual task of processing messages instead of worrying about how to create, access, or clean up JMS resources.

Synchronous Messaging Service Vs. Asynchronous Messaging Service

Synchronous Messaging Service
1. Has to wait for service completion before starting another service or processing further.
2. Sometime its time consuming when message consumption takes much time.
Asynchronous Messaging Service
1. Does not have to wait for service to be completed. Another service can come which than can be sending in queue rather than waiting for first request to complete.
2. Can’t use in all application.

Two types of messaging:
* Point to Point
* Subscribe & Publish.

JMS
1. Similar to writing JDBC or JCA code
2. Boilerplate code to create or retrieve JMS resource objects that make the task more with more repetitive code.

Typical Process of using JMS:
1. Create JNDI initial context.
2. Get a queue connection factory from the JNDI context.
3. Get a Queue from the queue connection factory.
4. Create a Session object.
5. Create a sender or receiver object.
6. Send or receive a message using the sender or receiver object created in Step 5.
7. Close all of the JMS resources after processing the messages.

Terminology:

A JMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features. An implementation of the J2EE 1.3 platform includes a JMS provider. Bea Weblogic supports JMS as one of its j2ee service.

JMS clients are the programs or components written in the JavaTM programming language that produce and consume messages. Thus both producer and consumer of the Queue or Topic are known as JMS clients

Messages are the objects that communicate information between JMS clients.

Administered objects are preconfigured JMS objects created by an administrator of the J2EE Application Server (e.g. Bea Weblogic or IBM’s Websphere) for the use of clients. There are two kinds of administered objects, destinations (Queue or Topic) and connection factories.

JMS producer sends messages to the Destinations to be consumed by the consumer. Destination can be either Queue or Topic.

SPRING JMS
1. Templates to hide detail of java API.
2. Spring provides the JMSTemplate class so developers don't have to write the boilerplate code for a JMS implementation.
Advantages:
• Provides JMS abstraction API to simplify use of destination (Queue/Topics) and publish message to specified destination.
• No need to deal with Exception as Spring provides unchecked exception for any JMS exception that is re-thrown in JMS code.
• Simple for using asynchronous messaging
Java Classes to use with JMS application.

1. JmsException
This is the base (abstract) class for any exceptions thrown by Spring framework whenever there is a JMS exception.
2. JmsTemplate & JmsTemplate102
These are helper classes used to simplify the use of JMS by handling the creation and release of JMS resources like connection factories, destinations, and sender/receiver objects. JmsTemplate102 is a subclass of JmsTemplate that uses the JMS 1.0.2 specification.

• To get started using JmsTemplate, need to know which JMS specification is supported by the JMS provider. E.g. JBoss AS 4.0.2 supports the JMS 1.0.2 specification.
• JMS 1.1 unifies the programming interfaces for PTP and (Pub/Sub) domains. With this developer can create transacted session, and receive a message from QUEUE (PTP) and send message to TOPIC (Pub/Sub) within the same JMS transaction.

Various methods to send & receive messages:

Send: Send a message to default or specified destination.

Receive: Receive a message from default or specified destination, but only wait for a specified time of delivery.

ConvertAndSend: delegates the conversation process to an instance of MessageConverter interface and then sends it to destination.

ReceiveAndConvert: Receives a message from default or specified destination and converts it to JavaObject.

3. MessageCreator
This is a callback interface used by the JmsTemplate class. It creates a JMS message for a specified session.
4. MessageConverter
This interface acts as an abstraction to convert between Java objects and JMS messages.

MessageConverter
The MessageConverter interface defines a contract to convert Java objects into JMS messages.
Application code can focus on the business objects and not bother with the inner details of how it's represented as a JMS message.
SimpleMessageConverter (and SimpleMessageConverter102) are default implementations of MessageConverter. They are used to convert a String to a JMS TextMessage, a byte array (byte[]) to a JMS BytesMessage, a Map to a JMS MapMessage, and a Serializable object to a JMS ObjectMessage, respectively. You can also write your own custom implementations of MessageConverter to convert XML documents into a TextMessage object using an XML binding framework such as JAXB, Castor, Commons Digester, XMLBeans, or XStream.

5. DestinationResolver
This is an interface used by JmsTemplate for resolving destination names. DynamicDestinationResolver and JndiDestinationResolver are the default implementations of this interface.

Destinations
Destinations are stored and retrieved using a JNDI context. While configuring a Spring application context, we use JndiObjectFactoryBean class to get reference to JMS destinations.
The DestinationResolver interface is used to resolve a destination name to JMS destination, which is used when application has lots of destinations.
DynamicDestinationResolver is used to resolve dynamic destinations.

Process:

1. First thing we need message queue to send and receive message. Configure it in jbossmq-wsc-jboss-service.xml file.


name="jboss.mq.destination:service=Queue,name=CreditRequestSendQueue">

jboss.mq:service=DestinationManager



2. Create new destinations with queue/CreditRequestSendQueue and queue/CreditRequestReceiveQueue.

3. JMS configuration:

4. JNDI context to get resource.





org.jnp.interfaces.NamingContextFactory


localhost


org.jnp.interfaces:org.jboss.naming





5. JMS Queue connection factory configuration.

class="org.springframework.jndi.JndiObjectFactoryBean">




UIL2ConnectionFactory



JndiObjectFactoryBean:
FactoryBean that looks up a JNDI object. It exposes object found in JNDI when used as bean reference. E.g “dataSource”
Register this as singleton factory in an application context.

6. Configuration for send & receive Destination

class="org.springframework.jndi.JndiObjectFactoryBean">




queue/CreditRequestSendQueue



7. JMS Template configuration

class="org.springframework.jms.core.JmsTemplate102">







30000



8. JMS Sender & Receiver configuration















9. Testing:

public void send() {
try {
ClassPathXmlApplicationContext appContext = new
ClassPathXmlApplicationContext(new String[] {
"spring-jms.xml"});

System.out.println("Classpath loaded");

JMSSender jmsSender = (JMSSender)appContext.getBean("jmsSender");

jmsSender.sendMesage();

System.out.println("Message sent using Spring JMS.");
} catch(Exception e) {
e.printStackTrace();
}
}

Wednesday, June 27, 2007

XSLT

XSLT
******
http://www.w3.org/TR/xslt
http://www.biglist.com/lists/xsl-list/archives/200305/msg01187.html

http://www.biglist.com/lists/xsl-list/archives/200104/msg00963.html

********

XSLT is a language for transforming the structure of an XML document.

A transformation expressed in XSLT describes rules for transforming a source tree into a result tree. The transformation is achieved by associating patterns with templates. A pattern is matched against elements in the source tree. A template is instantiated to create part of the result tree. The result tree is separate from the source tree. The structure of the result tree can be completely different from the structure of the source tree. In constructing the result tree, elements from the source tree can be filtered and reordered, and arbitrary structure can be added.

A template is instantiated for a particular source element to create part of the result tree. A template can contain elements that specify literal result element structure. A template can also contain elements from the XSLT namespace that are instructions for creating result tree fragments.

Couln't go funther from here i my research was ended up by the change in requirement.
Still i would say its pretty good one.

Monday, June 25, 2007

DOM tutorial

http://www.developerlife.com/domintro/default.htm

Why Is XML Important?

Why Is XML Important?

There are a number of reasons for XML's surging acceptance. This section lists a few of the most prominent.

Plain Text

Because XML is not a binary format, you can create and edit files using anything from a standard text editor to a visual development environment. That makes it easy to debug your programs, and it makes XML useful for storing small amounts of data. At the other end of the spectrum, an XML front end to a database makes it possible to efficiently store large amounts of XML data as well. So XML provides scalability for anything from small configuration files to a company wide data repository.

Data Identification

XML tells you what kind of data you have, not how to display it. Because the markup tags identify the information and break the data into parts, an email program can process it, a search program can look for messages sent to particular people, and an address book can extract the address information from the rest of the message. In short, because the different parts of the information have been identified, they can be used in different ways by different applications.

Stylability

When display is important, the stylesheet standard, XSL, lets you dictate how to portray the data. For example, consider this XML:

you@yourAddress.com  

The stylesheet for this data can say

  1. Start a new line.
  2. Display "To:" in bold, followed by a space
  3. Display the destination data.

This set of instructions produces:

To: you@yourAddress  

Of course, you could have done the same thing in HTML, but you wouldn't be able to process the data with search programs and address-extraction programs and the like. More importantly, because XML is inherently style-free, you can use a completely different stylesheet to produce output in Postscript, TEX, PDF, or some new format that hasn't even been invented. That flexibility amounts to what one author described as "future proofing" your information. The XML documents you author today can be used in future document-delivery systems that haven't even been imagined.

Inline Reusability

One of the nicer aspects of XML documents is that they can be composed from separate entities. You can do that with HTML, but only by linking to other documents. Unlike HTML, XML entities can be included "inline" in a document. The included sections look like a normal part of the document: you can search the whole document at one time or download it in one piece. That lets you modularize your documents without resorting to links. You can single-source a section so that an edit to it is reflected everywhere the section is used, and yet a document composed from such pieces looks for all the world like a one-piece document.

Linkability

Thanks to HTML, the ability to define links between documents is now regarded as a necessity. Appendix B discusses the link-specification initiative. This initiative lets you define two-way links, multiple-target links, expanding links (where clicking a link causes the targeted information to appear inline), and links between two existing documents that are defined in a third.

Easily Processed

As mentioned earlier, regular and consistent notation makes it easier to build a program to process XML data. For example, in HTML a

tag can be delimited by
, another
,
, or . That makes for some difficult programming. But in XML, the
tag must always have a
terminator, or it must be an empty tag such as
. That restriction is a critical part of the constraints that make an XML document well formed. (Otherwise, the XML parser won't be able to read the data.) And because XML is a vendor-neutral standard, you can choose among several XML parsers, any one of which takes the work out of processing XML data.

Hierarchical

Finally, XML documents benefit from their hierarchical structure. Hierarchical document structures are, in general, faster to access because you can drill down to the part you need, as if you were stepping through a table of contents. They are also easier to rearrange, because each piece is delimited. In a document, for example, you could move a heading to a new location and drag everything under it along with the heading, instead of having to page down to make a selection, cut, and then paste the selection into a new location.

Thursday, June 21, 2007

XStream fight.

Morning started with searching the difference between XStream and other Parsers like DOM.

The motive was clear "find out which parser is better". But i was in nowhere looking out what is XStream and wat's DOM. It took 2 hours to understand and start working with XStream.
You can have look at it by

http://xstream.codehaus.org/tutorial.html

Than it was time to find out about DOM.

Well i must say i couldn't find any example to start with it. I got to hear that the kind of xml i'm gonna parse is gonna be easy with XStream. Even by Project Leader told me that. But i'm really looking some stuff with DOM parser.

Tuesday, June 19, 2007

Why to put the Web server in front of Tomcat at all?

http://people.apache.org/~mturk/docs/article/ftwai.html#cooliris

A. First thing to ease the load from the Tomcat is to use the Web server for serving static content like images, etc.

B. Second thing is creating an DMZ (demilitarized zone). Putting Web server on a computer host inserted as a "neutral zone" between a company's private network and the internet or some other outside public network gives the applications hosted on Tomcat capability to access company private data, while securing the access to other private resources.

C. The need for the custom authentication for example.

1st Day @ Java

Hmm. Finally i'm stepping in blogging. Hope it turns out good for me.

Knowledge is good but Sharing the knowledge is even better.