Tomcat webserver

Tomcat is an open source web server developed by Apache Group. Apache Tomcat is the servlet container that is used in the official Reference Implementation for the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed by Sun under the Java Community Process. Web Servers like Apache Tomcat support only web components while an application server supports web components as well as business components (BEAs Weblogic, is one of the popular application server).To develop a web application with jsp/servlet install any web server like JRun, Tomcat etc to run your application.

Web server and application server : A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send or redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.
           The web server simply passes the request to the program to handle it. The web server does not provides any functionality beyond providing an environment in which the server - side program can execute and pass back the generated responses. The server-side program usually provides such functions as transaction processing, database connectivity and messing .
Application Server :
While an application server exposes business logic to client applications through various protocols like HTTP, TCP-IP etc. All the web servers mainly deals with sending HTML for displaying to a Web browser. An application server providers allows the client to access the business logic for use. The application server is used to run business logic or dynamically generating presentation code. A J2EE application server runs servlets and JSPs that are used to create HTML pages dynamically. In this case, J2EE application server can run EJBs ? which are used to execute business logic. An application server is more capable of dynamic behaviour than webserver.

Refer : http://en.wikipedia.org/wiki/Apache_Tomcat

SVN

Basic svn commands : 
#create new repository
svnadmin create d:/svn/project

#import project to repository
svn import d:/web/home/project/www/ svn://localhost/

#checkout working copy from repository
svn co svn://localhost/ d:/web/home/project/www/

#update working copy
svn update d:/web/home/project/www/

#add ( delete, copy, move ) a folder or file
svn add d:/web/home/project/www/new

#find changes
svn status d:/web/home/project/www/

# revert file to his initial state in working copy
svn revert d:/web/home/project/www/index.php

# commit change to repository
svn commit d:/web/home/project/www/ -m "change description"

SVN status codes : http://blog.gotofritz.net/howto/svn-status-codes/

Refer : http://amukukki.blogspot.in/2008/07/basic-svn-commands.html

Comparison of svn and cvs :
 http://www.skill-guru.com/blog/2010/08/25/comparin-svn-and-cvs/
http://www.pushok.com/software/svn-vscvs.html

JMX

JMX is a technology that lets you implement management interfaces for Java applications.

A management interface, as defined by JMX, is composed of named objects - called MBeans (Management Beans). MBeans are registered with a name (an ObjectName) in an MBeanServer. To manage (a) resource(s) in your application, you will write an MBean that defines its management interface, and then register that MBean in your MBeanServer.
The content of the MBeanServer can then be exposed through various protocols, implemented by protocol connectors, or protocol adaptors.

A protocol connector (e.g. the JMX RMI Connector) exposes the MBeans as they are - so a remote client sees the same model than a local client.
A protocol adaptor (e.g. an SNMP adaptor, or HTML adaptor) performs (or provides hooks to let you perform) a model mediation - to adapt the model to what a client of that protocol (e.g. SNMP Manager, or Web Browser) would expect to see.

Refer : https://blogs.oracle.com/jmxetc/entry/what_is_jmx
http://en.wikipedia.org/wiki/Java_Management_Extensions

Code review

Code review guide lines
11_Best_Practices_for_Peer_Code_Review.pdf

Which things instantly ring alarm bells when looking at code?
Q)

I attended a software craftsmanship event a couple of weeks ago and one of the comments made was "I'm sure we all recognize bad code when we see it" and everyone nodded sagely without further discussion.

This sort of thing always worries me as there's that truism that everyone thinks they're an above average driver. Although I think I can recognize bad code I'd love to learn more about what other people consider to be code smells as it's rarely discussed in detail on people's blogs and only in a handful of books. In particular I think it'd be interesting to hear about anything that's a code smell in one language but not another

Ans)

When grading a student's program, I can sometimes tell in a "blink"-style moment. These are the instant clues:

• Poor or inconsistent formatting
• More than two blank lines in a row
• Nonstandard or inconsistent naming conventions
• Repeated code, the more verbatim the repeats, the stronger the warning
• What should be a simple piece of code is overly complicated (for example, checking the arguments passed to main in a convoluted way)
• unreachable code
• commented code

Rarely are my first impressions incorrect, and these warning bells are right about 95% of the time. For one exception, a student new to the language was using a style from a different programming language. Digging in and re-reading their style in the idiom of the other language removed the alarm bells for me, and the student then got full credit. But such exceptions are rare.

When considering more advanced code, these are my other warnings:

• The presence of many Java classes that are only "structs" to hold data. It doesn't matter if the fields are public or private and use getters/setters, it's still not likely part of a well thought-out design.
• Classes that have poor names, such as just being a namespace and there's no real cohesion in the code
• Reference to design patterns that aren't even used in the code
• Empty exception handlers without explanation
• When I pull up the code in Eclipse, hundreds of yellow "warnings" line the code, mostly due to unused imports or variables
• Check the scope of access modifiers.

In terms of style, I generally don't like to see:

• Javadoc comments that only echo the code

These are only clues to bad code. Sometimes what may seem like bad code really isn't, because you don't know the programmer's intentions. For instance, there may be a good reason that something seems overly complex-- there may have been another consideration at play.

Quartz job

Batch solutions are ideal for processing that is time and/or state based:
Time-based: The business function executes on a recurring basis, running at pre-determined schedules.
State-based: The jobs will be run when the system reaches a specific state.
Batch processes are usually data-centric and are required to handle large volumes of data off-line without affecting your on-line systems. This nature of batch processing requires proper scheduling of jobs. Quartz is a full-featured, open source job scheduling system that can be integrated with, or used along side virtually any Java Enterprise of stand-alone application. The Quartz Scheduler includes many enterprise-class features, such as JTA transactions and clustering.

The following is a list of features available:
Can run embedded within another free standing application
Can be instantiated within an application server (or servlet container).
Can participate in XA transactions, via the use of JobStoreCMT.
Can run as a stand-alone program (within its own Java Virtual Machine), to be used via RMI
Can be instantiated as a cluster of stand-alone programs (with load-balance and fail-over capabilities)
Supoprt for Fail-over
Support for Load balancing.
Scheduling jobs using Quartz or Timer
Scheduling and Thread Pooling
CronTrigger Tutorial

MVC Architecture

Model/view/controller (MVC) is a software architecture, currently considered an architectural pattern, used in software engineering. The pattern isolates "domain logic" (the application logic for the user) from the user interface (input and presentation), permitting independent development, testing and maintenance of each (separation of concerns).
Use of the Model/View/Controller (MVC) pattern results in applications that separate the different aspects of the application (input logic, business logic, and UI logic), while providing a loose coupling between these elements.

The main aim of the MVC architecture  is to separate the business logic and application data from the presentation data to the user.

Refer : http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
http://www.roseindia.net/struts/mvc-architecture.shtml
http://www.jcorporate.com/expresso/doc/edg/edg_WhatIsMVC.html

Web services

The term Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall
.
Unlike traditional client/server models, such as a Web server/Web page system, Web services do not provide the user with a GUI. Web services instead share business logic, data and processes through a programmatic interface across a network. The applications interface, not the users. Developers can then add the Web service to a GUI (such as a Web page or an executable program) to offer specific functionality to users.
Web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, Web services are not tied to any one operating system or programming language. For example, Java can talk with Perl, Windows applications can talk with UNIX applications.
Web services do not require the use of browsers or HTML.
Web services are sometimes called application services.

              Web Services can convert your application into a Web-application, which can publish its function or message to the rest of the world.The basic Web Services platform is XML + HTTP.