Guru Nanak Dev University
Regional Campus, Gurdaspur
A Project Report On
“Enterprise Java Beans Stub Simulator”
For the partial fulfilment for the award of the degree of
B.Tech
SUBMITTED BY
Swajot Singh 74219
Reg. No.: 2006.RG/A.156
UNDER THE GUIDANCE OF
Ms. Taqdeer
Professor
(Dept of CSE)
Department Of Computer Science & Engineering 2009-2010
Declaration
I hereby declare that the present report has been prepared after the completion of my six months industrial training at Accenture Services Pvt. Ltd., Bangalore and is submitted only at G.N.D.U RCG and not at any other institution for the attainment of any other degree.
Swajot Singh
2 | P a g e
Acknowledgement
Apart from the efforts of me, the success of any project depends largely on the encouragement and guidelines of many others. I take this opportunity to express my gratitude to the people who have been instrumental in the successful completion of this project.
I would like to show my greatest appreciation to Mr. Srinivas Kondamudi (Manager). I can’t say thank you enough for his tremendous support and help. I feel motivated and encouraged every time I attend his meeting. Without his encouragement and guidance this project would not have materialized.
I would like to thank my Team Leader, Mr. Chandrashekar for the valuable guidance and advice. He inspired me greatly to work in this project. His willingness to motivate me contributed tremendously to this project. I also would like to thank him for showing me some example that related to the topic of the project.
The guidance and support received from Mr. Madhu Shanmugam (Senior Programmer) was vital for the success of the project. I am grateful for his constant support and help.
I cannot let go this opportunity to thank the most to the project guide assigned to me by the university, Ms. Taqdeer for her belief in this project and for her faith in me and for investing her energies in this project. She has been sole inspiration to hard work and she has been most helpful guide and she has always been so concerned that it has helped me to improve the quality of the project.
3 | P a g e
Besides, I would like to take this opportunity to thank the authority of Accenture Services Pvt. Ltd for providing me the opportunity to work in this project and providing with a good environment and facilities to complete this project.
Finally, an honorable mention goes to my family and friends for their understanding and support. Without the help of the particular that mentioned above, I would have faced many difficulties while doing this project.
4 | P a g e
My Role
The project assigned to me was to develop a tool that would simulate the Enterprise Java Beans and this will have an enterprise vide implementation and the other resource working on this project was Mr. Madhu Shanmugam (senior programmer). The project was ably supervised by Mr. Chandrashekar.
My working profile on the project comprised of developing a ‘Graphical User Interface’ for the Client which shall provide him the option to browse and upload jar files and provide checkboxes to select home and remote interfaces. Configure the binding of the JNDI names to the Home Interfaces. To find the methods in the Home and Remote interfaces and to pull the required domain jar from the selected Home and Remote Interfaces. Create the Home and Remote Classes by going through the Home Interface chosen by the User. At Last I needed to compile the Home and Remote Classes and then bind the Home to JNDI name.
5 | P a g e
Abstract
Imagine a scenario where the client (can be an external/internal) needs to access an EJB which has still not been developed yet. Without the EJB the client cannot continue his development/testing. This would result in a decrease in productivity. In such a situation we can deploy a simulator which will simulate the EJB which is not present and will give the output to the calling Client and this would mean that even in the absence of the actual EJB required the client can continue with the process of development and/or testing and this would result in saving in valuable time and has a very practical importance in the enterprise wide working because such issues are encountered very often that we need certain EJBs and they still are not been developed so this tool/project will solve such an issue and therefore client can not only save time but money as well.
We need a tool that can simulate the EJB which will help in continuing the development and testing. The simulator would help in carrying out testing process in case of unavailability of an Enterprise JAVA Bean that is being called by another Enterprise JAVA Bean that is to be tested so the stub would provide the test results and thus help in speeding up the testing process. It would automate the process of giving test outputs for the particular Enterprise JAVA Bean while we perform testing. There exists no previous version of this application so this application is being developed from scratch and the tool is aimed to be generic in nature.
These are the few key features/functionalities that the aimed tool needs to serve:
The project is aimed to be implemented in the areas involving the development of the applications where the different EJBs interact with each other to give an output.
The project is aimed to stub an EJB where the client can interact with the EJB which has still not been implemented. It involves developing a tool that would help to simulate this process and component testing can take place.
The tool being developed is a generic one so that it can be used/help simulates for various enterprise applications.
It can be effectively be used to increase the speed of developing a new application where the client in need for looking up an EJB can use this tool to generate the stub of the actual EJB which has not yet been developed and continue their development and unit/component testing. Hence making the process of coding and testing to an extent parallel to each other.
6 | P a g e
Table of Contents Acknowledgement ...... 3 My Role ...... 5 Abstract ...... 6 Introduction ...... 11 Issues/Risks ...... 14 Company Profile ...... 15 ACCENTURE SERVICES Pvt. Ltd...... 15 The Group ...... 15 IDEOLOGY ...... 15 Corporate Citizenship...... 18 Corporate Citizenship is a fundamental part of Accenture's character and the way we run our business...... 18 Clients...... 18 Industry Expertise ...... 19 Revenues Detail ...... 20 Technologies being used in this Project ...... 23 JAVA ...... 23 History ...... 24 Principles ...... 25 Java Platform ...... 25 Syntax ...... 28 Examples ...... 28 Special Classes ...... 30 Class Libraries ...... 35 Enterprise Java Beans ...... 37 Rapid Adaption Followed by Criticism ...... 39 Reinventing EJBs ...... 40 Examples ...... 41 Types ...... 43 Execution ...... 45
7 | P a g e
XML (Extensible Markup Language) ...... 48 Key Terminology ...... 48 The material in this section is based on the XML Specification. This is not an exhaustive list of all the constructs which appear in XML; it provides an introduction to the key constructs most often encountered in day-to-day use...... 48 Well-formedness and Error-handling ...... 51 Schemas and Validation ...... 52 DTD (Document Type Definition) ...... 52 XML Schema ...... 53 JBoss (Application Server) ...... 54 Versions ...... 54 Product Features ...... 55 Eclipse (IDE) ...... 56 Architecture ...... 56 Rich Client Platform ...... 57 System Development Life Cycle ...... 59 Recognition of need ...... 60 Feasibility study...... 60 Analysis ...... 62 Design ...... 62 Implementation ...... 65 Post implementation & maintenance ...... 66 Requirements ...... 68 Stateless Session Bean ...... 69 Design ...... 70 Coding ...... 72 Screenshots ...... 73 Testing ...... 80 Psychology of Testing ...... 82 Testing Objectives ...... 82 Levels of Testing ...... 82
8 | P a g e
Unit Testing ...... 83 Integration Testing ...... 84 System Testing ...... 84 Acceptance Testing ...... 84 White Box Testing ...... 85 Black Box Testing ...... 85 TEST INFORMATION FLOW ...... 85 Conclusion ...... 87 Future Enhancements ...... 88 References ...... 89
9 | P a g e
10 | P a g e
Introduction
During the period of the Internship in Accenture, The project assigned to me was ‘Aristos’. Aristos is the project of the United States of America’s largest Telecom Company. The domain under the Aristos in which I have worked is ‘Middleware’ and in the Team, the task assigned to me was to develop a tool called EJB Stub Simulator that would be used to deploy an EJB Stub at the place of an EJB which will provide the desired output to the calling EJB and thus it will be a replacement to the original EJB which is unavailable and thus it enables performing unit testing of the other EJBs which are already deployed and needs to interact with the EJB for which we are deploying the stub. The stubs would help in carrying out testing process in case of unavailability of a program that is being called by the program that is to be tested so the stub would provide the test results and thus help in speeding up the testing process. We require having fields in our application that should be able to provide client with the home screen, Remote interface, Domains that he can add to provide the objects as the data input for the simulator. As the tool is aimed at being generic in nature so it should be able to populate domains dynamically i.e. the end user must have the liberty of entering any number of domains and he must be able to enter any type of data either strings or objects. The technologies that are required to develop this tool are JAVA, Enterprise JAVA Beans, and XML is required for the creation of the window in which the user can enter the values for which he needs the output values.
Below is the table designed for the requirements of the tool and their brief description:
Name Text
EJB Stub Simulator The EJB Stub Simulator shall stub the Enterprise Java Bean which shall provide the client with the desired response to its input.
11 | P a g e
Name Text
Client Login The EJB Stub Simulator shall provide login Page to the Client where he shall enter Name and Password.
Input Provide an option to the Client to enter the Home and remote name
Provide an option to the Client to input the JNDI names.
Provide an option for the client to enter the inputs from which the domain objects can be built.
Home and Remote interface The EJB Stub Simulator shall parse the Home and Remote interface provided by the client and built up Classes that are required to serve the Client’s requirements.
Provide an option to the Client to make a JNDI look up.
12 | P a g e
Name Text
Database The tool should maintain a database using which would provide the data that would be used to give the output to the client for given input.
Output Provide the output to client in the form of object.
The project is aimed to be implemented in the areas involving the development of the applications where the different EJBs interact with each other to give an output. The project is aimed to stub an EJB where the client can interact with the EJB which has still not been implemented. It involves developing a tool that would help to simulate this process and component testing can take place. The tool being developed is a generic one so that it can be used/help simulates for various enterprise applications. It can be effectively be used to increase the speed of developing a new application where the client in need for looking up an EJB can use this tool to generate the stub of the actual EJB which has not yet been developed and continue their development and unit/component testing. Hence, making the process of coding and testing to an extent parallel to each other.
13 | P a g e
Issues/Risks
1. The one major issue in the development of this software lies in the fact that it needs to be generic so it should be able to accept any data type from the user even the objects.
2. Another issue could be designing the user interface that could allow him to create as many domains as he wants.
3. The mapping and binding of JNDI names to the Home and Remote Interface will pose another issue.
4. To pull out the required domains from the jar by scanning through the methods in the Remote interface for the selected Home Interface.
5. Dynamically creation of Home and Remote Interface corresponding to the Home interfaces selected by the user will pose another issue.
14 | P a g e
Company Profile
ACCENTURE SERVICES Pvt. Ltd.
Accenture is a global management consulting, technology services and outsourcing company. Combining unparalleled experience, comprehensive capabilities across all industries and business functions, and extensive research on the world’s most successful companies, Accenture collaborates with clients to help them become high-performance businesses and governments. With approximately 177,000 people serving clients in more than 120 countries, the company generated net revenues of US$21.58 billion for the fiscal year ended Aug. 31, 2009.
The Group
Continuous innovation and rapid transformation have been themes throughout Accenture's history. Established in 1989 primarily as a technology consultant and systems integrator, Accenture soon began offering a new breed of business integration solutions to clients— solutions that aligned organizations' technologies, processes and people with their strategies.
Throughout its history, Accenture has expanded its offerings and capitalized on evolving management trends and technologies to benefit its clients. The company pioneered systems integration and business integration; led the deployment of enterprise resource planning, customer relationship management and electronic services; and has established itself as a leader in today's global marketplace.
Today Accenture is a global management consulting, technology services and outsourcing company, with net revenues of US$23.39 billion for the fiscal year ended Aug. 31, 2008.
IDEOLOGY
Accenture’s "high performance business" strategy builds on our expertise in consulting, technology and outsourcing to help clients perform at the highest levels so they can create
15 | P a g e
sustainable value for their customers and shareholders. Using our industry knowledge, service- offering expertise and technology capabilities, we identify new business and technology trends and develop solutions to help clients around the world:
Enter new markets.
Increase revenues in existing markets.
Improve operational performance.
Deliver their products and services more effectively and efficiently.
We have extensive relationships with the world's leading companies and governments and work with organizations of all sizes—including 96 of the Fortune Global 100 and more than three quarters of the Fortune Global 500. Our commitment to client satisfaction strengthens and extends our relationships. For example, of our top 100 clients in fiscal year 2008, based on revenue, 99 have been clients for at least five years and 87 have been clients for at least 10 years.
Among the much strength that distinguishes Accenture in the marketplace are our:
Extensive industry expertise.
Broad and evolving service offerings.
Expertise in business transformation outsourcing.
History of technology innovation and implementation, including our research and development capabilities, on which we spend approximately $300 million annually.
Commitment to the long-term development of our employees.
Proven and experienced management team.
Our Core Values have shaped the culture and defined the character of our company, guiding how we behave and make decisions:
Stewardship: Building a heritage for future generations, acting with an owner mentality, developing people everywhere we are, and meeting our commitments to all internal and external stakeholders.
16 | P a g e
Best People: Attracting and developing the best talent for our business, stretching our people and developing a "can do" attitude.
Client Value Creation: Improving our clients' business performance, creating long-term, win-win relationships and focusing on execution excellence.
One Global Network: Mobilizing the power of teaming to deliver consistently exceptional service to our clients anywhere in the world.
Respect for the Individual: Valuing diversity, ensuring an interesting and inclusive environment, and treating people as we would like to be treated ourselves.
Integrity: Inspiring trust by taking responsibility, acting ethically, and encouraging honest and open debate.
By enhancing our consulting and outsourcing expertise with alliances and other capabilities, we help move clients forward in every part of their businesses, from strategic planning to day-to-day operations. With approximately 177,000 people in 52 countries, deep industry and business process expertise, broad global resources and a proven track record, Accenture can mobilize the right people, skills and technologies to help clients improve their performance.
17 | P a g e
Corporate Citizenship
Corporate Citizenship is a fundamental part of Accenture's character and the way we run our business.
It is reflected in our core values, our Code of Business Ethics, and ultimately, in the actions of our people. From Accenture Skills to Succeed to our environmental stewardship, our corporate citizenship efforts target achieving outcomes that make a real impact.
Skills to Succeed Accenture people are helping build skills that enable people to develop themselves to participate in and contribute to the economy. Skills to Succeed combines our passion, experience and our constant commitment to developing and nurturing talent with our high performance approach and it supports our efforts to make significant impact on the economic well-being of individuals, their families and their communities.
Accenture’s Environmental Stewardship Accenture is committed to understanding and reducing its environmental impact in terms of carbon, water and waste. In addition to running our business in an environmentally responsible way, we provide sustainable solutions to our clients choose suppliers based on their environmental performance and foster employees' efforts to reduce their individual impacts.
Clients
Accenture's clients span the full range of industries around the world and include 99 of the Fortune Global 100 and more than three-quarters of the Fortune Global 500. In addition, of our top 100 clients in fiscal year 2009, based on revenue, 99 have been clients for at least five years,
18 | P a g e
and 91 have been clients for at least 10 years and we are top company when it comes to outsourcing.
Industry Expertise
Accenture delivers its services and solutions through 18 focused industry groups in five operating groups. This industry focus provides Accenture’s professionals with a thorough understanding of industry evolution, business issues and applicable technologies, enabling Accenture to deliver solutions tailored to each client's industry.
Operating Groups and Industry Groups
Communications Financial Services Health & Public Products Resources & High Tech Service
Industry Groups Industry Groups Industry Groups Industry Groups Industry Groups
Communications Banking Health Automotive Chemicals Electronics & Capital Markets Public Service Consumer Goods & Energy High Tech Insurance Services Natural Media & Life Sciences Resources Entertainment Industrial Utilities Equipment Retail Infrastructure &
19 | P a g e
Revenues Detail
NET REVENUES (revenues before reimbursements; all figures in $US thousands)
First Quarter Full Fiscal Year (3 months ended Nov. 30, 2009 (12 months ended Aug. 31, 2009 and and Nov. 30, 2008) Aug. 31, 2008)
Fiscal Fiscal % Growth % of Q1 Fiscal 2009 Fiscal 2008 % Growth % of 2010 2009 (Local FY10 Net (Local FY09 Net Currency) Revenues Currency) Revenues
TOTAL 5,382,532 6,019,497 -12 100 21,576,850 23,386,802 0 100
By Operating Group
Comms. & 1,159,313 1,363,818 -17 22 4,830,880 5,449,737 -4 22 High Tech
20 | P a g e
Financial 1,104,037 1,238,078 -12 20 4,322,896 5,005,039 -6 20 Services
Health & Public 946,512 943,334 18 5,530,232 6,068,589 1 26 Service
Products 1,204,060 1,384,962 -14 22 2,984,304 2,870,765 +11 14
Resources 942,163 1,079,228 -12 18 3,879,711 3,963,477 +8 18
Other 4,447 10,077 * 0 28,827 29,195 * 0
TOTAL 5,382,532 6,019,497 -12 100 21,576,850 23,386,802 0 100
By Geography
Americas 2,229,064 2,576,378 -14 42 9,403,420 9,725,808 0 44
EMEA 2,550,372 2,873,086 -12 47 9,903,536 11,545,904 -2 46
21 | P a g e
Asia Pacific 603,096 570,033 -2 11 2,269,894 2,115,090 +12 10
TOTAL 5,382,532 6,019,497 -12 100 21,576,850 23,386,802 0 100
By Type of Work
Consulting 3,120,230 3,657,175 -16 57 12,555,652 14,117,186 -4 58
Outsourcing. 2,262,293 2,362,322 -5 43 9,021,198 9,269,616 +6 42
TOTAL 5,382,532 6,019,497 -12 100 21,576,850 23,386,802 0 100
22 | P a g e
Technologies being used in this Project
JAVA Enterprise JAVA Beans XML JBoss (Server) Eclipse (Integrated Development Environment)
JAVA
Java is a programming language originally developed by James Gosling at Sun Microsystems (which is now a subsidiary of Oracle Corporation) and released in 1995 as a core component of Sun Microsystems' Java platform. The language derives much of its syntax from C and C++ but has a simpler object model and fewer low-level facilities. Java applications are typically compiled to byte code (class file) that can run on any Java Virtual Machine (JVM) regardless of computer architecture. Java is general-purpose, concurrent, class-based, and object- oriented, and is specifically designed to have as few implementation dependencies as possible. It is intended to let application developers "write once, run anywhere". Java is considered by many as one of the most influential programming languages of the 20th century, and is widely used from application software to web applications.
The original and reference implementation Java compilers, virtual machines, and class libraries were developed by Sun from 1995. As of May 2007, in compliance with the specifications of the Java Community Process, Sun relicensed most of their Java technologies under the GNU General Public License. Others have also developed alternative implementations of these Sun technologies, such as the GNU Compiler for Java and GNU Class path.
23 | P a g e
History
James Gosling initiated the Java language project in June 1991 for use in one of his many set-top box projects. The language, initially called Oak after an oak tree that stood outside Gosling's office, also went by the name Green and ended up later renamed as Java, from a list of random words. Gosling aimed to implement a virtual machine and a language that had a familiar C/C++ style of notation.
Sun Microsystems released the first public implementation as Java 1.0 in 1995. It promised "Write Once, Run Anywhere" (WORA), providing no-cost run-times on popular platforms. Fairly secure and featuring configurable security, it allowed network- and file-access restrictions. Major web browsers soon incorporated the ability to run Java applets within web pages, and Java quickly became popular. With the advent of Java 2 (released initially as J2SE 1.2 in December 1998), new versions had multiple configurations built for different types of platforms. For example, J2EE targeted enterprise applications and the greatly stripped-down version J2ME for mobile applications (Mobile Java). J2SE designated the Standard Edition. In 2006, for marketing purposes, Sun renamed new J2 versions as Java EE, Java ME, and Java SE, respectively.
In 1997, Sun Microsystems approached the ISO/IEC JTC1 standards body and later the Ecma International to formalize Java, but it soon withdrew from the process. Java remains a de facto standard, controlled through the Java Community Process. At one time, Sun made most of its Java implementations available without charge, despite their proprietary software status. Sun generated revenue from Java through the selling of licenses for specialized products such as the Java Enterprise System. Sun distinguishes between its Software Development Kit (SDK) and Runtime Environment (JRE) (a subset of the SDK); the primary distinction involves the JRE's lack of the compiler, utility programs, and header files.
On November 13, 2006, Sun released much of Java as open source software under the terms of the GNU General Public License (GPL). On May 8, 2007, Sun finished the process, making all of Java's core code available under free software/open-source distribution terms, aside from a small portion of code to which Sun did not hold the copyright.
24 | P a g e
Principles
There were five primary goals in the creation of the Java language:
1. It should be "simple, object oriented, and familiar".
2. It should be "robust and secure".
3. It should be "architecture neutral and portable".
4. It should execute with "high performance".
5. It should be "interpreted, threaded, and dynamic".
Java Platform
One characteristic of Java is portability, which means that computer programs written in the Java language must run similarly on any supported hardware/operating-system platform. This is achieved by compiling the Java language code to an intermediate representation called Java byte code, instead of directly to platform-specific machine code. Java byte code instructions are analogous to machine code, but are intended to be interpreted by a virtual machine (VM) written specifically for the host hardware. End-users commonly use a Java Runtime Environment (JRE) installed on their own machine for standalone Java applications, or in a Web browser for Java applets.
Standardized libraries provide a generic way to access host-specific features such as graphics, threading and networking.
A major benefit of using byte code is porting. However, the overhead of interpretation means that interpreted programs almost always run more slowly than programs compiled to native executables would. Just-in-Time compilers were introduced from an early stage that compiles byte codes to machine code during runtime. Over the years, this JVM built-in feature has been optimized to a point where the JVM's performance competes with natively compiled C code.
25 | P a g e
Implementations
Sun Microsystems officially licenses the Java Standard Edition platform for Linux, Mac OS X, and Solaris. Although in the past Sun has licensed Java to Microsoft, the license has expired and has not been renewed. Through a network of third-party vendors and licensees, alternative Java environments are available for these and other platforms.
Sun's trademark license for usage of the Java brand insists that all implementations be "compatible". This resulted in a legal dispute with Microsoft after Sun claimed that the Microsoft implementation did not support RMI or JNI and had added platform-specific features of their own. Sun sued in 1997, and in 2001 won a settlement of $20 million as well as a court order enforcing the terms of the license from Sun. As a result, Microsoft no longer ships Java with Windows, and in recent versions of Windows, Internet Explorer cannot support Java applets without a third-party plugin. Sun, and others, have made available free Java run-time systems for those and other versions of Windows.
Platform-independent Java is essential to the Java EE strategy, and an even more rigorous validation is required to certify an implementation. This environment enables portable server- side applications, such as Web services, Java Servlets, and Enterprise JavaBeans, as well as with embedded systems based on OSGi, using Embedded Java environments. Through the new GlassFish project, Sun is working to create a fully functional, unified open source implementation of the Java EE technologies.
Sun also distributes a superset of the JRE called the Java Development Kit (commonly known as the JDK), which includes development tools such as the Java compiler, Javadoc, Jar and debugger.
Performance
Programs written in Java have a reputation for being slower and requiring more memory than those written in some other languages. However, Java programs' execution speed improved significantly with the introduction of Just-in-time compilation in 1997/1998 for Java 1.1, the addition of language features supporting better code analysis (such as inner classes, String Buffer class, optional assertions, etc.), and optimizations in the Java Virtual Machine itself, such as HotSpot becoming the default for Sun's JVM in 2000.
26 | P a g e
To boost even further the speed performances that can be achieved using the Java language Systronix made JStik, a microcontroller based on the aJile Systems line of embedded Java processors. In addition, the widely used ARM family of CPUs has hardware support for executing Java byte code through its Jazelle option.
Automatic Memory Management
Java uses an automatic garbage collector to manage memory in the object lifecycle. The programmer determines when objects are created, and the Java runtime is responsible for recovering the memory once objects are no longer in use. Once no references to an object remain, the unreachable memory becomes eligible to be freed automatically by the garbage collector. Something similar to a memory leak may still occur if a programmer's code holds a reference to an object that is no longer needed, typically when objects that are no longer needed are stored in containers that are still in use. If methods for a nonexistent object are called, a "null pointer exception" is thrown.
One of the ideas behind Java's automatic memory management model is that programmers be spared the burden of having to perform manual memory management. In some languages memory for the creation of objects is implicitly allocated on the stack, or explicitly allocated and deallocated from the heap. Either way, the responsibility of managing memory resides with the programmer. If the program does not deallocate an object, a memory leak occurs. If the program attempts to access or deallocate memory that has already been deallocated, the result is undefined and difficult to predict, and the program is likely to become unstable and/or crash. This can be partially remedied by the use of smart pointers, but these add overhead and complexity. Note that garbage collection does not prevent 'logical' memory leaks, i.e. those where the memory is still referenced but never used.
Garbage collection may happen at any time. Ideally, it will occur when a program is idle. It is guaranteed to be triggered if there is insufficient free memory on the heap to allocate a new object; this can cause a program to stall momentarily. Explicit memory management is not possible in Java.
Java does not support C/C++ style pointer arithmetic, where object addresses and unsigned integers (usually long integers) can be used interchangeably. This allows the garbage collector to relocate referenced objects, and ensures type safety and security.
As in C++ and some other object-oriented languages, variables of Java's primitive data types are not objects. Values of primitive types are either stored directly in fields (for objects) or on the
27 | P a g e
stack (for methods) rather than on the heap, as commonly true for objects (but see Escape analysis). This was a conscious decision by Java's designers for performance reasons. Because of this, Java was not considered to be a pure object-oriented programming language. However, as of Java 5.0, autoboxing enables programmers to proceed as if primitive types are instances of their wrapper classes.
Syntax
The syntax of Java is largely derived from C++. Unlike C++, which combines the syntax for structured, generic, and object-oriented programming, Java was built almost exclusively as an object oriented language. All code is written inside a class and everything is an object, with the exception of the intrinsic data types (ordinal and real numbers, boolean values, and characters), which are not classes for performance reasons.
Java suppresses several features (such as operator overloading and multiple inheritance) for classes in order to simplify the language and to prevent possible errors and anti-pattern design.
Java uses similar commenting methods to C++. There are three different styles of comment: a single line style marked with two forward slashes (//), a multiple line style opened with a forward slash asterisk (/*) and closed with an asterisk forward slash (*/) and the Javadoc commenting style opened with a forward slash and two asterisks (/**) and closed with an asterisk forward slash (*/). The Javadoc style of commenting allows the user to run the Javadoc executable to compile documentation for the program.
Examples
HelloWorld.java
// Outputs "Hello, world!" and then exits public class HelloWorld {
public static void main (String[] args) {
28 | P a g e
System.out.println ("Hello, world!");
}
}
Source files must be named after the public class they contain, appending the suffix .java, for example, HelloWorld.java. It must first be compiled into byte code, using a Java compiler, producing a file named HelloWorld.class. Only then can it be executed, or 'launched'. The java source file may only contain one public class but can contain multiple classes with less than public access and any number of public inner classes.
A class that is not declared public may be stored in any .java file. The compiler will generate a class file for each class defined in the source file. The name of the class file is the name of the class, with .class appended. For class file generation, anonymous classes are treated as if their name was the concatenation of the name of their enclosing class, a $, and an integer.
The keyword public denotes that a method can be called from code in other classes, or that a class may be used by classes outside the class hierarchy. The class hierarchy is related to the name of the directory in which the .java file is.
The keyword static in front of a method indicates a static method, which is associated only with the class and not with any specific instance of that class. Only static methods can be invoked without a reference to an object. Static methods cannot access any method variables that are not static.
The keyword void indicates that the main method does not return any value to the caller. If a Java program is to exit with an error code, it must call System.exit() explicitly.
The method name "main" is not a keyword in the Java language. It is simply the name of the method the Java launcher calls to pass control to the program. Java classes that run in managed environments such as applets and Enterprise Java Bean do not use or need a main() method. A java program may contain multiple classes that have main methods, which means that the VM needs to be explicitly told which class to launch from.
The main method must accept an array of String objects. By convention, it is referenced as args although any other legal identifier name can be used. Since Java 5, the main method can also use variable arguments, in the form of public static void main(String... args), allowing the main method to be invoked with an arbitrary number of String arguments. The effect of this alternate
29 | P a g e
declaration is semantically identical (the args parameter is still an array of String objects), but allows an alternative syntax for creating and passing the array.
The Java launcher launches Java by loading a given class (specified on the command line or as an attribute in a JAR) and starting its public static void main(String[]) method. Stand-alone programs must declare this method explicitly. The String[] args parameter is an array of String objects containing any arguments passed to the class. The parameters to main are often passed by means of a command line.
Printing is part of a Java standard library: The System class defines a public static field called out. The out object is an instance of the PrintStream class and provides many methods for printing data to standard out, including println(String) which also appends a new line to the passed string.
The string "Hello, world!" is automatically converted to a String object by the compiler.
Special Classes
Applet
Java applets are programs that are embedded in other applications, typically in a Web page displayed in a Web browser.
// Hello.java import javax.swing.JApplet; import java.awt.Graphics;
public class Hello extends JApplet {
public void paintComponent(Graphics g) {
g.drawString("Hello, world!", 65, 95);
30 | P a g e
}
}
The import statements direct the Java compiler to include the javax.swing.JApplet and java.awt.Graphics classes in the compilation. The import statement allows these classes to be referenced in the source code using the simple class name (i.e. JApplet) instead of the fully qualified class name (i.e. javax.swing.JApplet).
The Hello class extends (subclasses) the JApplet (Java Applet) class; the JApplet class provides the framework for the host application to display and control the lifecycle of the applet. The JApplet class is a JComponent (Java Graphical Component) which provides the applet with the capability to display a graphical user interface (GUI) and respond to user events.
The Hello class overrides the paintComponent (Graphics) method inherited from the Container superclass to provide the code to display the applet. The paintComponent() method is passed a Graphics object that contains the graphic context used to display the applet. The paintComponent() method calls the graphic context drawString(String, int, int) method to display the "Hello, world!" string at a pixel offset of (65, 95) from the upper-left corner in the applet's display.
"http://www.w3.org/TR/html4/strict.dtd">
31 | P a g e
An applet is placed in an HTML document using the
The host application, typically a Web browser, instantiates the Hello applet and creates an AppletContext for the applet. Once the applet has initialized itself, it is added to the AWT display hierarchy. The paintComponent() method is called by the AWT event dispatching thread whenever the display needs the applet to draw itself.
Servlet
Java Servlet technology provides Web developers with a simple, consistent mechanism for extending the functionality of a Web server and for accessing existing business systems. Servlets are server-side Java EE components that generate responses (typically HTML pages) to requests (typically HTTP requests) from clients. A servlet can almost be thought of as an applet that runs on the server side—without a face.
// Hello.java import java.io.*; import javax.servlet.*;
public class Hello extends GenericServlet {
public void service(ServletRequest request, ServletResponse response)
throws ServletException, IOException {
32 | P a g e
response.setContentType("text/html");
final PrintWriter pw = response.getWriter();
pw.println("Hello, world!");
pw.close();
}
}
The import statements direct the Java compiler to include all of the public classes and interfaces from the java.io and javax.servlet packages in the compilation.
The Hello class extends the GenericServlet class; the GenericServlet class provides the interface for the server to forward requests to the servlet and control the servlet's lifecycle.
The Hello class overrides the service(ServletRequest, ServletResponse) method defined by the Servlet interface to provide the code for the service request handler. The service() method is passed a ServletRequest object that contains the request from the client and a ServletResponse object used to create the response returned to the client. The service() method declares that it throws the exceptions ServletException and IOException if a problem prevents it from responding to the request.
The setContentType(String) method in the response object is called to set the MIME content type of the returned data to "text/html". The getWriter() method in the response returns a PrintWriter object that is used to write the data that is sent to the client. The println(String) method is called to write the "Hello, world!" string to the response and then the close() method is called to close the print writer, which causes the data that has been written to the stream to be returned to the client.
Java Server Pages
JavaServer Pages (JSPs) are server-side Java EE components that generate responses, typically HTML pages, to HTTP requests from clients. JSPs embed Java code in an HTML page by using the special delimiters <% and %>. A JSP is compiled to a Java servlet, a Java application in its own right, the first time it is accessed. After that, the generated servlet creates the response.
33 | P a g e
Swing Application
Swing is a graphical user interface library for the Java SE platform. It is possible to specify a different look and feel through the pluggable look and feel system of Swing. Clones of Windows, GTK+ and Motif are supplied by Sun. Apple also provides an Aqua look and feel for Mac OS X. Where prior implementations of these looks and feels may have been considered lacking, Swing in Java SE 6 addresses this problem by using more native GUI widget drawing routines of the underlying platforms.
This example Swing application creates a single window with "Hello, world!" inside:
// Hello.java (Java SE 5) import javax.swing.*;
public class Hello extends JFrame {
public Hello() {
setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
add(new JLabel("Hello, world!"));
pack();
}
public static void main(String[] args) {
new Hello().setVisible(true);
}
34 | P a g e
}
The first import includes all of the public classes and interfaces from the javax.swing package.
The Hello class extends the JFrame class; the JFrame class implements a window with a title bar and a close control.
The Hello() constructor initializes the frame by first calling the superclass constructor, passing the parameter "hello", which is used as the window's title. It then calls the setDefaultCloseOperation(int) method inherited from JFrame to set the default operation when the close control on the title bar is selected to WindowConstants.EXIT_ON_CLOSE — this causes the JFrame to be disposed of when the frame is closed (as opposed to merely hidden), which allows the JVM to exit and the program to terminate. Next, the layout of the frame is set to a BorderLayout; this tells Swing how to arrange the components that will be added to the frame. A JLabel is created for the string "Hello, world!" and the add(Component) method inherited from the Container superclass is called to add the label to the frame. The pack() method inherited from the Window superclass is called to size the window and lay out its contents.
The main() method is called by the JVM when the program starts. It instantiates a new Hello frame and causes it to be displayed by calling the setVisible(boolean) method inherited from the Component superclass with the boolean parameter true. Once the frame is displayed, exiting the main method does not cause the program to terminate because the AWT event dispatching thread remains active until all of the Swing top-level windows have been disposed.
Class Libraries
Java libraries are the compiled bytecodes of source code developed by the JRE implementor to support application development in Java. Examples of these libraries are:
o The core libraries, which include:
. Collection libraries that implement data structures such as lists, dictionaries, trees and sets
. XML Processing (Parsing, Transforming, Validating) libraries
. Security
35 | P a g e
. Internationalization and localization libraries
o The integration libraries, which allow the application writer to communicate with external systems. These libraries include:
. The Java Database Connectivity (JDBC) API for database access
. Java Naming and Directory Interface (JNDI) for lookup and discovery
. RMI and CORBA for distributed application development
. JMX for managing and monitoring applications
o User interface libraries, which include:
. The (heavyweight, or native) Abstract Window Toolkit (AWT), which provides GUI components, the means for laying out those components and the means for handling events from those components
. The (lightweight) Swing libraries, which are built on AWT but provide (non-native) implementations of the AWT widgetry
. APIs for audio capture, processing, and playback
A platform dependent implementation of Java Virtual Machine (JVM) that is the means by which the byte codes of the Java libraries and third party applications are executed
Plugins, which enable applets to be run in Web browsers
Java Web Start, which allows Java applications to be efficiently distributed to end-users across the Internet
Licensing and documentation.
36 | P a g e
Diagram Showing JAVA Platform
Enterprise Java Beans
Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications.
The EJB specification is one of several Java APIs in the Java EE. EJB is a server-side model that encapsulates the business logic of an application. The EJB specification was originally developed in 1997 by IBM and later adopted by Sun Microsystems(EJB 1.0 and 1.1) in 1999 and enhanced under the Java Community Process as JSR 19 (EJB 2.0), JSR 153 (EJB 2.1) and JSR 220 (EJB 3.0).
37 | P a g e
The EJB specification intends to provide a standard way to implement the back-end 'business' code typically found in enterprise applications (as opposed to 'front-end' interface code). Such code was frequently found to address the same types of problems, and it was found that solutions to these problems are often repeatedly re-implemented by programmers. Enterprise JavaBeans were intended to handle such common concerns as persistence, transactional integrity, and security in a standard way, leaving programmers free to concentrate on the particular problem at hand.
Accordingly, the EJB specification details how an application server provides:
. Persistence via the Java Persistence API (JPA)
. Transaction processing
. Concurrency control
. Events using Java Message Service
. Naming and directory services (JNDI)
. Security ( Java Cryptography Extension (JCE) and JAAS )
. Deployment of software components in an application server
. Remote procedure calls using RMI-IIOP.
. Exposing business methods as Web Services.
Additionally, the Enterprise Java Bean specification defines the roles played by the EJB container and the EJBs as well as how to deploy the EJBs in a container.
38 | P a g e
Rapid Adaption Followed by Criticism
This vision was persuasively presented by EJB advocates such as IBM and Sun Microsystems, and Enterprise JavaBeans were quickly adopted by large companies. Problems were quick to appear, however, and the reputation of EJBs began to suffer as a result. Some developers felt that the APIs of the EJB standard were far more complex than those developers were used to. An abundance of checked exceptions, required interfaces, and the implementation of the bean class as an abstract class were all unusual and counter-intuitive for many programmers. Granted, the problems that the EJB standard was attempting to address, such as object-relational mapping and transactional integrity, are complex. However many programmers found the APIs to be just as difficult if not more so, leading to a widespread perception that EJBs introduced complexity without delivering real benefits.
In addition, businesses found that using EJBs to encapsulate business logic brought a performance penalty. This is because the original specification only allowed for remote method invocation through CORBA (and optionally other protocols), even though the large majority of business applications actually do not require this distributed computing functionality. The EJB 2.0 specification addressed this concern by adding the concept of local interfaces which could be called directly without performance penalties by applications that were not distributed over multiple servers. It was introduced largely to address the performance problems that existed with EJB 1.0.
The complexity issue, however, continued to hinder EJB's acceptance. Although high-quality developer tools made it easy to create and use EJBs by automating most of the repetitive tasks, these tools did not make it any easier to learn how to use the technology. Moreover, a counter- movement had grown up on the grass-roots level among programmers. The main products of this movement were the so-called 'lightweight' (i. e. in comparison to EJB) technologies of Hibernate (for persistence and object-relational mapping) and Spring Framework(which provided an alternate and far less verbose way to encode business logic). Despite lacking the support of big businesses, these technologies grew in popularity and were adopted more and more by businesses who had become disillusioned with EJBs.
39 | P a g e
EJBs were promoted by Sun's Java Pet Store demo Java BluePrints. The use of EJBs was controversial and influential Java EE programmers such as Rod Johnson took positions in response to Java Pet Store that sought to deemphasize EJB use. Sun itself produced an alternative called Java Data Objects. Later, EJBs, Java Data Forms, and many of the ideas underlying Hibernate were combined to form EJB 3.0 which included the Java Persistence API and Plain Old Java Objects (POJOs). EJB 3.0 was less heavy weight than EJB 2.0 and provided more choices to developers.
Reinventing EJBs
Gradually an industry consensus emerged that the original EJB specification's primary virtue — enabling transactional integrity over distributed applications — was of limited use to most enterprise applications, and the functionality delivered by simpler frameworks like Spring and Hibernate was more useful. Accordingly, the EJB 3.0 specification (JSR 220) was a radical departure from its predecessors, following this new paradigm. It shows a clear influence from Spring in its use of POJOs, and its support for dependency injection to simplify configuration and integration of heterogeneous systems. Gavin King, the creator of Hibernate, participated in the EJB 3.0 process and is an outspoken advocate of the technology. Many features originally in Hibernate were incorporated in the Java Persistence API, the replacement for entity beans in EJB 3.0. The EJB 3.0 specification relies heavily on the use of annotations, a feature added to the Java language with its 5.0 release, to enable a much less verbose coding style.
Accordingly, in practical terms EJB 3.0 is very nearly a completely new API, bearing little resemblance to the previous EJB specifications.
40 | P a g e
Examples
The following shows a basic example of what an EJB looks like in code:
@Local public interface CustomerServiceLocal {
void addCustomer(Customer customer);
}
@Stateless public class CustomerService {
@PersistenceContext
private EntityManager entityManager;
public void addCustomer(Customer customer) {
entityManager.persist(customer);
}
}
41 | P a g e
The above defines a local interface and the implementation of a service class for persisting a Customer object (via O/R mapping). The EJB takes care of managing the persistence context and the addCustomer() method is transactional and thread-safe by default. As demonstrated, the EJB focussed only on business logic and persistence and knows nothing about any particular presentation.
Such an EJB can be used by a class in e.g. the web layer as follows:
@Named
@RequestScoped public class CustomerBacking {
@EJB CustomerServiceLocal customerService;
public String addCustomer() {
customerService.addCustomer(customer);
context.addMessage(...); // abbreviated for brevity
return "customer_overview";
}
}
The above defines a JSF backing bean in which the EJB is injected by means of the @EJB annotation. Its addCustomer method is typically bound to some UI component, like a button. Contrary to the EJB, the backing bean does not contain any business logic or persistence code, but delegates such concerns to the EJB. The backing bean does know about a particular presentation, of which the EJB had no knowledge.
42 | P a g e
Types
An EJB container holds two major types of beans:
. Session Beans that can be either "Stateful", "Stateless" or "Singleton" and can be accessed via either a Local (same JVM) or Remote (different JVM) interface. All sessions beans support asynchronous execution for all views (local/remote).
. Message Driven Beans (also known as MDBs or Message Beans). MDBs also support asynchronous execution, but via messaging paradigm.
Stateful Session Beans are business objects having state: that is, they keep track of which calling client they are dealing with throughout a session and thus access to the bean instance is strictly limited to only one client at a time. Stateful session beans' state may be persisted (passivated) automatically by the container to free up memory after the client hasn't accessed the bean for some time. The JPA extended persistence context is explicitly supported by Stateful Session Beans. As an example, checking out in a web store might be handled by a stateful session bean that would use its state to keep track of where the customer is in the checkout process.
Stateless Session Beans are business objects that do not have state associated with them. However, access to a single bean instance is still limited to only one client at a time and thus concurrent access to the bean is prohibited. This makes a stateless session bean automatically thread-safe. Instance variables can be used during a single method call to the bean, but the contents of those instance variables are not guaranteed to be preserved across method calls. Instances of Stateless Session beans are typically pooled. If a second client accesses a specific bean right after a method call on it made by a first client has finished, it might get the same instance. The lack of overhead to maintain a conversation with the calling client makes them less resource-intensive than stateful beans. Sending an e-mail to customer support might be handled by a stateless bean, since this is a one-off operation and not part of a multi-step process.
43 | P a g e
Singleton Session Beans are business objects having a global shared state. Concurrent access to the one and only bean instance can be controlled by the container (Container-managed concurrency, CMC) or by the bean itself (Bean-managed concurrency, BMC). CMC can be tuned using the @Lock annotation, that designates whether a read lock or a write lock will be used for a method call. Additionally, Singleton Session Beans can explicitly request to be instantiated when the EJB container starts up, using the @Startup annotation. Loading a global daily price list that will be the same for every user might be done with a singleton session bean, since this will prevent the application having to do the same query to a database over and over again.
Message Driven Beans were introduced in the EJB 2.0 specification that is supported by Java EE 1.3 or higher. The message bean represents the integration of JMS (Java Message Service) with EJB to create an entirely new type of bean designed to handle asynchronous JMS or other type of messages. Message Driven Beans are business objects that behave primarily asynchronously. That is, they handle operations that do not require an immediate response. For example, a user of a website clicking on a "keep me informed of future updates" box may trigger a call to a Message Driven Bean to add the user to a list in the company's database. (This call is asynchronous because the user does not need to wait to be informed of its success or failure.) These beans may subscribe to JMS (Java Message Service) message queues or message topics. They were added in the EJB 2.0 specification to allow event-driven processing inside EJB Container. Unlike other types of beans, MDB does not have a client view (Local/Remote interfaces), i.e. clients cannot look-up an MDB instance. It just listens for any incoming message on e.g. a JMS queue (or topic) and processes them automatically. Only JMS support is required by the Java EE spec, but Message Driven Beans can support other messaging protocols. Such protocols may be asynchronous but can also be synchronous.
Previous versions of EJB also used a type of bean known as an Entity Bean. These were distributed objects having persistent state. Beans in which their container managed the persistent state were said to be using Container-Managed Persistence (CMP), whereas beans that managed their own state were said to be using Bean-Managed Persistence (BMP). Entity Beans were replaced by the Java Persistence API in EJB 3.0, though as of 2007, CMP 2.x style Entity beans are still available for backward compatibility. As of EJB 3.1, JPA has been completely separated to its own spec and EJB will focus only on the "core session bean and message-driven bean component models and their client API”.
44 | P a g e
Execution
EJBs are deployed in an EJB container within the application server. The specification describes how an EJB interacts with its container and how client code interacts with the container/EJB combination. The EJB classes used by applications are included in the javax.ejb package. (The javax.ejb.spi package is a service provider interface used only by EJB container implementations.)
With EJB 2.1 and earlier, each EJB had to provide a Java implementation class and two Java interfaces. The EJB container created instances of the Java implementation class to provide the EJB implementation. The Java interfaces were used by client code of the EJB.
The two interfaces, referred to as the Home and the Remote interface, specified the signatures of the EJB's remote methods. The methods were split into two groups:
Class methods
Not tied to a specific instance, such as those used to create an EJB instance (factory method) or to find an existing entity EJB (see EJB Types, above). These were declared by the Home interface.
Instance methods
These are methods tied to a specific instance. They are placed in the Remote interface.
Because these are merely Java interfaces and not concrete classes, the EJB container must generate classes for these interfaces that will act as a proxy in the client. Client code invokes a method on the generated proxies that in turn places the method arguments into a message and sends the message to the EJB server.
45 | P a g e
Transactions
EJB containers must support both container managed ACID transactions and bean managed transactions. Container-managed transactions use a declarative syntax for specifying transactions in the deployment descriptor.
Events
JMS (Java Message Service) is used to send messages from the beans to client objects, to let clients receive asynchronous messages from these beans. MDB can be used to receive messages from client applications asynchronously using either a JMS Queue or a Topic.
Naming and Directory Services
Clients of the EJB locate the Home Interface implementation object using JNDI. The Home interface may also be found using the CORBA name service. From the home interface, client code can find entity beans, as well as create and delete existing EJBs.
Security
The EJB Container is responsible for ensuring the client code has sufficient access rights to an EJB.
Deployment
46 | P a g e
The EJB specification defines a mechanism that allows EJBs to be deployed in a consistent manner regardless of the specific EJB platform that is chosen. Information about how the bean should be deployed (such as the name of the home or remote interfaces, whether and how to store the bean in a database, etc.) are specified in the deployment descriptor.
The deployment descriptor is an XML document having an entry for each EJB to be deployed. This XML document specifies the following information for each EJB:
. Name of the Home interface
. Java class for the Bean (business object)
. Java interface for the Home interface
. Java interface for the business object
. Persistent store (only for Entity Beans)
. Security roles and permissions
. Stateful or Stateless (for Session Beans)
EJB containers from many vendors require more deployment information than that in the EJB specification. They will require the additional information as separate XML files, or some other configuration file format. An EJB platform vendor generally provides their own tools that will read this deployment descriptor, and possibly generate a set of classes that will implement the Home and Remote interfaces.
Since EJB3.0 (JSR 220), the XML descriptor is replaced by Java annotations set in the Enterprise Bean implementation (at source level), although it is still possible to use an XML descriptor instead of (or in addition to) the annotations. If an XML descriptor and annotations are both applied to the same attribute within an Enterprise Bean, the XML definition overrides the corresponding source-level annotation.
47 | P a g e
XML (Extensible Markup Language)
XML (Extensible Markup Language) is a set of rules for encoding documents electronically. It is defined in the XML 1.0 Specification produced by the W3C, and several other related specifications, all gratis open standards.
XML’s design goals emphasize simplicity, generality, and usability over the Internet. It is a textual data format, with strong support via Unicode for the languages of the world. Although XML’s design focuses on documents, it is widely used for the representation of arbitrary data structures, for example in web services.
There are many programming interfaces that software developers may use to access XML data, and several schema systems designed to aid in the definition of XML-based languages.
As of 2009, hundreds of XML-based languages have been developed, including RSS, Atom, SOAP, and XHTML. XML-based formats have become the default for most office-productivity tools, including Microsoft Office (Office Open XML), OpenOffice.org (Open Document), and Apple's iWork.
Key Terminology
The material in this section is based on the XML Specification. This is not an exhaustive list of all the constructs which appear in XML; it provides an introduction to the key constructs most often encountered in day-to-day use.
48 | P a g e
Unicode (Character)
By definition, an XML document is a string of characters. Almost every legal Unicode character may appear in an XML document.
Processor and Application
The processor analyzes the markup and passes structured information to an application. The specification places requirements on what an XML processor must do and not do, but the application is outside its scope. The processor (as the specification calls it) is often referred to colloquially as an XML parser.
Markup and Content
The characters which make up an XML document are divided into markup and content. Markup and content may be distinguished by the application of simple syntactic rules. All strings which constitute markup either begin with the character "<" and end with a ">", or begin with the character "&" and end with a ";". Strings of characters which are not markup are content.
49 | P a g e
Tag
A markup construct that begins with "<" and ends with ">". Tags come in three flavors: start- tags, for example
Element
A logical component of a document which either begins with a start-tag and ends with a matching end-tag, or consists only of an empty-element tag. The characters between the start- and end-tags, if any, are the element's content, and may contain markup, including other elements, which are called child elements. An example of an element is
Attribute
A markup construct consisting of a name/value pair that exists within a start-tag or empty- element tag. In the example (below) the element img has two attributes, src and alt:. Another example would be
XML Declaration
XML documents may begin by declaring some information about themselves, as in the following example.
50 | P a g e
Well-formedness and Error-handling
The XML specification defines an XML document as a text which is well-formed, i.e., it satisfies a list of syntax rules provided in the specification. The list is fairly lengthy; some key points are:
. It contains only properly-encoded legal Unicode characters.
. None of the special syntax characters such as "<" and "&" appear except when performing their markup-delineation roles.
. The begin, end, and empty-element tags which delimit the elements are correctly nested, with none missing and none overlapping.
. The element tags are case-sensitive; the beginning and end tags must match exactly.
. There is a single "root" element which contains all the other elements.
The definition of an XML document excludes texts which contain violations of well-formedness rules; they are simply not XML. An XML processor which encounters such a violation is required to report such errors and to cease normal processing. This policy, occasionally referred to as draconian, stands in notable contrast to the behavior of programs which process HTML, which are designed to produce a reasonable result even in the presence of severe markup errors. XML's policy in this area has been criticized as a violation of Postel's law.
51 | P a g e
Schemas and Validation
In addition to being well-formed, an XML document may be valid. This means that it contains a reference to a Document Type Definition (DTD), and that its elements and attributes are declared in that DTD and follow the grammatical rules for them that the DTD specifies.
XML processors are classified as validating or non-validating depending on whether or not they check XML documents for validity. A processor which discovers a validity error must be able to report it, but may continue normal processing.
A DTD is an example of a schema or grammar. Since the initial publication of XML 1.0, there has been substantial work in the area of schema languages for XML. Such schema languages typically constrain the set of elements that may be used in a document, which attributes may be applied to them, the order in which they may appear, and the allowable parent/child relationships.
DTD (Document Type Definition)
The oldest schema language for XML is the Document Type Definition (DTD), inherited from SGML.
DTDs have the following benefits:
. DTD support is ubiquitous due to its inclusion in the XML 1.0 standard.
. DTDs are terse compared to element-based schema languages and consequently present more information in a single screen.
. DTDs allow the declaration of standard public entity sets for publishing characters.
52 | P a g e
. DTDs define a document type rather than the types used by a namespace, thus grouping all constraints for a document in a single collection.
DTDs have the following limitations:
. They have no explicit support for newer features of XML, most importantly namespaces.
. They lack expressiveness. XML DTDs are simpler than SGML DTDs and there are certain structures that cannot be expressed with regular grammars. DTDs only support rudimentary datatypes.
. They lack readability. DTD designers typically make heavy use of parameter entities (which behave essentially as textual macros), which make it easier to define complex grammars, but at the expense of clarity.
. They use a syntax based on regular expression syntax, inherited from SGML, to describe the schema. Typical XML APIs such as SAX do not attempt to offer applications a structured representation of the syntax, so it is less accessible to programmers than an element-based syntax may be.
Two peculiar features that distinguish DTDs from other schema types are the syntactic support for embedding a DTD within XML documents and for defining entities, which are arbitrary fragments of text and/or markup that the XML processor inserts in the DTD itself and in the XML document wherever they are referenced, like character escapes.
DTD technology is still used in many applications because of its ubiquity.
XML Schema
A newer schema language, described by the W3C as the successor of DTDs, is XML Schema, often referred to by the initialism for XML Schema instances, XSD (XML Schema Definition).
53 | P a g e
XSDs are far more powerful than DTDs in describing XML languages. They use a rich data typing system and allow for more detailed constraints on an XML document's logical structure. XSDs also use an XML-based format, which makes it possible to use ordinary XML tools to help process them.
JBoss (Application Server)
JBoss Application Server (or JBoss AS) is a free software/open-source Java EE- based application server. Because it is Java-based, the JBoss application server operates cross- platform: usable on any operating system that supports Java. JBoss AS was developed by JBoss, now a division of Red Hat.
Versions
JBoss AS 4.0, a Java EE 1.4 application server, features an embedded Apache Tomcat 5.5 Servlet. It supports any Java Virtual Machine between versions 1.4 and 1.6. JBoss can run on numerous operating systems including many POSIX platforms (like Linux, FreeBSD and Mac OS X), Microsoft Windows and others, as long as a suitable JVM is present.
JBoss AS 4.2 also functions as a Java EE 1.4 application server, but deploys Enterprise JavaBeans 3.0 by default. It requires the Java Development Kit version 5. Tomcat 5.5 comes bundled with it.
JBoss AS 5.1, released as of 2009, operates as a Java EE 5 application server. It is a minor update of the major release JBoss AS 5.0, which had been in development for 3+ years and is built on top of a new JBoss micro container. JBoss AS 5.1 contains a preview of some elements from the not yet released Java EE 6 specification.
54 | P a g e
Product Features
Clustering Failover (including sessions) Load balancing Distributed caching (using JBoss Cache, a standalone product) Distributed deployment (farming) Deployment API Management API Aspect-Oriented Programming (AOP) support JSP/Servlet 2.1/2.5 (Tomcat) Java Server Faces 1.2 (Mojarra) Enterprise Java Beans versions 3 and 2.1 JNDI (Java Naming and Directory Interface) Hibernate-integration (for persistence programming; JPA) JDBC JTA (Java Transaction API) Support for Java EE-Web Services like JAX-WS SAAJ (SOAP with Attachments API for Java) JMS (Java Message Service) integration Java Mail RMI-IIOP (JacORB, alias Java and CORBA) JAAS (Java Authentication and Authorization Service) JCA (Java Connector Architecture)-integration JACC (Java Authorization Contract for Containers)-integration Java Management Extensions
55 | P a g e
Eclipse (IDE)
Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. It is written primarily in Java and can be used to develop applications in Java and, by means of the various plug-ins, in other languages as well, including C, C++, COBOL, Python, Perl, PHP, and others. The IDE is often called Eclipse ADT for Ada, Eclipse CDT for C, Eclipse JDT for Java and Eclipse PDT for PHP.
The initial codebase originated from VisualAge. In its default form it is meant for Java developers, consisting of the Java Development Tools (JDT). Users can extend its capabilities by installing plug-ins written for the Eclipse software framework, such as development toolkits for other programming languages, and can write and contribute their own plug-in modules.
Released under the terms of the Eclipse Public License, Eclipse is free and open source software.
Architecture
Eclipse employs plug-ins in order to provide all of its functionality on top of (and including) the runtime system, in contrast to some other applications where functionality is typically hard coded. The runtime system of Eclipse is based on Equinox, an OSGi standard compliant implementation.
This plug-in mechanism is a lightweight software componentry framework. In addition to allowing Eclipse to be extended using other programming such as C and Python, the plug-in framework allows Eclipse to work with typesetting languages like LaTeX, networking applications such as telnet, and database management systems. The plug-in architecture supports
56 | P a g e
writing any desired extension to the environment, such as for configuration management. Java and CVS support is provided in the Eclipse SDK, with Subversion support provided by third- party plug-ins.
With the exception of a small run-time kernel, everything in Eclipse is a plug-in. This means that every plug-in developed integrates with Eclipse in exactly the same way as other plug-ins; in this respect, all features are created equal. Eclipse provides plug-ins for a wide variety of features, some of which are through third parties using both free and commercial models. Examples of plug-ins include a UML plug-in for Sequence and other UML diagrams, a plug-in for Database explorer, and many others.
The Eclipse SDK includes the Eclipse Java Development Tools (JDT), offering an IDE with a built-in incremental Java compiler and a full model of the Java source files. This allows for advanced refactoring techniques and code analysis. The IDE also makes use of a workspace, in this case a set of metadata over a flat file space allowing external file modifications as long as the corresponding workspace "resource" is refreshed afterwards. The Visual Editor project allows interfaces to be created interactively, thus allowing Eclipse to be used as an RADtool.
Eclipse's widgets are implemented by a widget toolkit for Java called SWT, unlike most Java applications, which use the Java standard Abstract Window Toolkit (AWT) or Swing. Eclipse's user interface also uses an intermediate GUI layer called JFace, which simplifies the construction of applications based on SWT.
Language packs provide translations into over a dozen natural languages.
Rich Client Platform
Eclipse provides the Eclipse Rich Client Platform (RCP) for developing general purpose applications. The following components constitute the rich client platform:
. Equinox OSGi – a standard bundling framework
57 | P a g e
. Core platform – boot Eclipse, run plug-ins
. Standard Widget Toolkit (SWT) – a portable widget toolkit
. JFace – viewer classes to bring model view controller programming to SWT, file buffers, text handling, text editors
. Eclipse Workbench – views, editors, perspectives, wizards
58 | P a g e
System Development Life Cycle
The System Development Life Cycle is the process of developing information systems through investigation, analysis, design, implementation, and maintenance. The System Development Life Cycle (SDLC) is also known as Information Systems Development or Application Development.
It is a methodology that consists of development activities that have a prescribed order. Once a problem or opportunity for a new system is recognized a request for developing the new system is forwarded for approval. If it is approved, a study is carried out to ensure that the proposed system is feasible. If it is feasible, then the system’s requirements are specified and are followed by phases of system analysis, system design, system implementation, and post implementation. A recycling of development may occur again following system evaluation if the system still requires modification or redevelopment.
Below are the steps involved in the System Development Life Cycle. Each phase within the overall cycle may be made up of several steps.
Recognition of need
Feasibility study
Analysis
Design
Implementation
Post implementation & maintenance
59 | P a g e
Recognition of need
One must know what problem is before it can be solved.
The basis for a system is recognition of need for improving information system or procedure. This need leads to a preliminary investigation to determine whether any system can solve the problem. The analyst’s first talk is to prepare a statement specifying the scope and objectives of problem.
Feasibility study
Depending on the result of the initial investigation the survey is expanded to a more detailed feasibility study. A feasibility study is a test of system proposal according to its workability impact on the organization, ability to meet the users need and effective use of the resources.
It focuses on the following questions:-
What are the user’s demonstrable needs and how the candidate System meets them?
What resources are available for the given candidate system?
What is the likely impact of the candidate system on the organization?
The objectives of feasibility study are not to solve the problem but a sense of its scope. During the feasibility study the problem to be included in the system are determined. Consequently the cost and the benefits are estimated with greater accuracy.
60 | P a g e
Following questions are answered:-
Will the cost of new system will be more than the profits expected from implementation of the new system?
Is their a new way to do the job that will benefit the user?
The study can be categorized as:-
Technical Feasibility
Technical feasibility centers around the existing computer system hardware/software and to what extend it can support the proposed system.
Economical Feasibility
Economical feasibility is the most frequently used method for evaluating the effectiveness of the candidate system. The procedure is to determine the benefits and disadvantages that are expected from the candidate system and are compared with the cost.
Social Feasibility
It is made to estimate how strong the reaction the user staff is likely to have towards the developments of the new system.
61 | P a g e
The result is a formal proposal. The proposal summarizes what is known and what is going to be done.
Analysis
Analysis is a detailed study of the various operations performed by the system and their relationships within and outside the system. During analysis data are collected on the files, decision points and transaction handled by the present system. The interview is the commonly used tool in system analysis. It requires special skill and sensitivity to the subject being interviewed.
It is most important and critical process for the development of an information system. System analysis means finding the problem and breaking it to its several components so that a logical repackaging can be evolved. System analysis involves survey, study, and definition and evaluation phase of the problem.
Design
The term design describes a final system and the process by which it is developed. In this phase we move from logical to physical aspect of life cycle. It includes the construction of overall layout. The first step is to determine how the output is to be produced and in what format. Second, the input data and the master databases have to be designed to meet the requirements of the proposed output. The final report prior to the implementation phase includes procedural flowcharts, record layouts, report layouts and a workable plan for implementing the candidate system.
62 | P a g e
System design is a solution i.e. how to approach the creation of a new system. It involves starting with a vague idea and ultimately starting with a new system the design phase is transitioned from user oriented to a programmer database.
Various steps involved are:-
Problem definition
Input/Output specification
Database design
Modular program design
Preparation of source code
Testing and debugging
The system design goes through two phases of development:-
Logical Design
Logical design covers the following:-
1. Review the current physical system- its data flows; file contents, volume, frequencies.
2. Prepares output specifications – determine the format & content, of reports including terminal specification and location
3. Prepare input specifications – format & content of input functions.
63 | P a g e
4. Prepare edit, control and security specifications – which indicates backup procedures and ensure file integrity.
5. Specifies implementation plans.
6. Reviews benefits, cost, target dates and system constraints.
Physical design
Physical design consists of following steps:-
1. Design the physical system
Specify the input/output media
Design the database
Design physical information flow through the system
2. Plan system implementation
Prepare a conversion schedule
Determine training procedure
3. Revise the test and the implementation plan and specify new hardware and software
4. Update benefits, cost, conversion date, and system constraints
64 | P a g e
Coding
The goal of the coding phase is to translate the design of the system into code in a given programming language. The coding phase affects both Testing and Maintenance effort. A well- written code can reduce the testing and maintenance efforts. So simplicity and clarity should be strived for during the coding phase.
Testing
Testing is a process of executing a program with intent of finding an error. It is essential for good system that it is properly being tested before transferring it to the ultimate user, so that in early stage the bugs could be set all right and probability of system failure could be reduced.
Testing is the major quality control measure used during software development. Its basic function is to detect errors in the software. After the coding phase, computer programs are available that can be executed for testing purposes. The starting point of testing is unit testing. In this each module is tested separately. Then integration testing is performed to detect design errors by focusing on testing the interconnection between modules. After this system is put together and system testing is performed. Here the system is tested against the system requirements to see if all requirements are met and if the system performs as specified by the requirements.
Implementation
It is primarily concerned with the user training, site preparation, file conservation. During the final testing user acceptance is tested followed by user training.
65 | P a g e
Post implementation & maintenance
After the installation phase is complete and the user staff is adjusted to the changes created by the candidate system, evaluation and maintenance begin. There is an aging process that requires periodical maintenance of hardware and software. The importance of maintenance is to bring the system to new standards.
There are different SDLC models available that can be used but we have used Waterfall Model as it is a sequential software development process, in which progress is seen as flowing steadily downwards (like waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and Maintenance.
The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development.
The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce, although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development— as a way to criticize a commonly used software practice.
66 | P a g e
Waterfall Model
67 | P a g e
Requirements
For the analysis of the requirements for the development of the proposed application, there were couple of meetings organized by the Manager, Mr. Srinivas Kondamudi, in which the various aspects of the problem were discussed and the fields that are required in this application were told. There was a discussion based on what possibly could be the issues that would need to be tackled while developing this application. The technologies that we require to use in this particular application and the domains where it can be used. The meetings took around an hour and at the end of it we were able to know the problem at hand vividly. The team working on this particular application is:
Mr. Srinivas Kondamudi (Manager)
Mr. S. Chandrashekar(Associate Manager)
Mr. Madhu Shanmugam(Senior Programmer)
Mr. Swajot Singh(Intern)
In the development of the above Proposed System, the first phase of SDLC is over that is the requirement analysis is done and we have outlined the following technologies and packages that would be required for the development of the above project:
Enterprise JavaBeans TM
JBoss
Eclipse
XML
68 | P a g e
Under the EJB we will be using the Stateless Session Beans, the reason for choosing the stateless session beans over the stateful session beans is that the stateless session bean does not require to store the state so we don’t require to store the states in our application which otherwise would have been required to store in the database if we used stateful session bean. A stateful session bean does not have pooling concept but stateless session bean instances are pooled.
Stateless Session Bean
Just as the entity bean has a well-defined life cycle, so does the stateless session bean. The stateless session bean's life cycle has two states: the Does Not Exist state and the Method-Ready Pool. The Method-Ready Pool is similar to the instance pool used for entity beans. This is one of the significant life-cycle differences between stateless and stateful session beans; stateless beans define instance pooling in their life cycle and stateful beans do not.
Life Cycle of Stateless Session Bean
69 | P a g e
Design
The Design Document is aimed at providing footprints of how to proceed further in developing this software. In this phase we move from logical to physical aspect of life cycle. It includes the construction of overall layout. The first step is to determine how the output is to be produced and in what format. Second, the input data and the master databases have to be designed to meet the requirements of the proposed output. The final report prior to the implementation phase includes procedural flowcharts, record layouts, report layouts and a workable plan for implementing the candidate system.
System design is a solution i.e. how to approach the creation of a new system. It involves starting with a vague idea and ultimately starting with a new system the design phase is transitioned from user oriented to a programmer database.
The design phase will give us the required system diagram which will be referred to again and again during the development of the software. The design may undergo small changes as one may encounter some issues while coding but the design will remain as the main backbone of the final project.
NOTE: As I have signed Non Disclosure Agreement with the Accenture Services Pvt. Ltd., as per the company policy so I can not disclose the actual design and code to any person outside the organisation and not even to any person outside the project. So only a brief description of design can be illustrated here.
70 | P a g e
71 | P a g e
Coding
As per the policies of the Accenture Services Pvt. Ltd., I am not allowed to disclose the exact code so here is just a description of the coding written in the form of the simple English.
Firstly, we created a jsp page that displays a text box along with a browse button that will browse the file system of the client and then will upload the selected jar file. The page is developed by the help of struts and the jsp page has an action class that has the code written for specifying the fields used in the jsp page and the action class carries the code for checking if the file being uploaded by the user is ajar file or not and then if the file is jar file it uploads the jar file and jumps to the next page and if the file is not jar file then it displays the error message and user has to upload another file. After the jar file is uploaded the next jsp page that appears displays the home and remote interfaces along with the text box in which user can write the JNDI name for the specific home and interface and checkboxes which the user can use to select the home and remote interfaces corresponding to which he needs to create home and remote classes. The next page that was created had the drop down list of the methods contained in the selected home/remote interfaces and it provided option to the user to select the method and enter the data that it should return and it also provides the save button that saves the values provided by the user for the input and a configure button that will bind the JNDI name to the Home interface and this will make the EJB ready for the Client look up. The most important issue arises when the simulator needs to create the home and remote classes dynamically. The Home class (should implement serializable) create() method returns the instance of the Remote Class. The Remote class contains the implementation for the Business methods. The next step was to compile the Home and Remote classes and binding the Home Classes to JNDI name. The next basic problem comes is the mapping of the action classes to the jsp pages and the mapping is done by the xml and struts.xml is also created as it includes the struts in our application as by the help of struts the buttons, the dynamic data in the jsp pages are easily created. The build.xml is created that imports all the jar files that we use as the predefined methods to use in our project and we ant the build.xml and that creates a war file this war file is deployed in the server and then when server is started our application gets published over the server. So basically the build.xml binds and compiles our whole application.
72 | P a g e
Screenshots
Home Screen
73 | P a g e
Screen when user clicks browse
74 | P a g e
Error message when file selected is not jar file
75 | P a g e
After selecting a jar file click on upload jar
76 | P a g e
List of the Home and Remote Interfaces
77 | P a g e
Select the Home and Remote Interfaces
78 | P a g e
Bind the JNDI names to the Home and Remote Interfaces
79 | P a g e
Testing
Here the System testing involved is the most widely used testing process consisting of five stages as shown in the figure. In general, the sequence of testing activities is component testing, integration testing, and then user testing. However, as defects are discovered at any one stage, they require program modifications to correct them and this may require other stages in the testing process to be repeated.
Unit testing
Module testing
Sub-system testing
System testing
Acceptance
testing
(Component testing) (Integration testing) (User testing)
80 | P a g e
Testing is the process of detecting errors. Testing performs a very critical role for quality assurance and for ensuring the reliability of the software. The results of testing are used later on during maintenance also.
Testing is vital to the success of the system. System testing makes a logical assumption that if the parts of the system are correct, the goal will be successfully achieved. In adequate testing or non- testing leads to errors that may not appear until months or even years later.
This creates two problems:
1. The time lag between the cause and the appearance of the problem.
2. The time interval effect of the system errors on files and the records on the system.
A small error can conceivably explode into a much larger problem. Effective testing early in the process translates directly into long term cost savings from a reduced number of errors.
Another reason for system testing is its utility as a user oriented vehicle before implementation. The best program is worthless if it does not meet the user requirements. Unfortunately, the user’s demands are often compromised by efforts to facilitate program or design efficiency in terms of processing time or design efficiency.
81 | P a g e
Psychology of Testing
The aim of testing is often to demonstrate that a program works by showing that it has no errors. The basic purpose of testing phase is to detect the errors that may be present in the program. Hence one should not start testing with the intent of showing that a program works, but the intent should be to show that a program doesn’t work. Testing is the process of executing a program with the intent of finding errors.
Testing Objectives
The aim of testing is often to demonstrate that a program works by showing that it has no errors. The basic purpose of testing phase is to detect the errors that may be present in the program. Hence one should not start testing with the intent of showing that a program works, but the intent should be to show that a program doesn’t work. Testing is the process of executing a program with the intent of finding errors.
Levels of Testing
In order to uncover the errors present in different phases, we have the concept of levels of testing. The basic levels of testing are
82 | P a g e
Client Needs
Acceptance Testing
Requirements
System Testing
Design
Integration Testing
Code
Unit Testing
Unit Testing
Unit testing focuses verification effort on the smallest unit of software i.e. the module. Using the detailed design and the process specifications, testing is done to uncover errors within the
83 | P a g e
boundary of the module. All modules must be successful in the unit test before the start of the integration testing begins.
Integration Testing
After unit testing, we have to perform integration testing. The goal here is to see if modules can be integrated properly, the emphasis being on testing interfaces between modules. This testing activity can be considered as testing the design and hence the emphasis on testing module interactions.
System Testing
Here the entire software system is tested. The reference document for this process is the requirements document, and the goal is to see if software meets its requirements.
Acceptance Testing
Acceptance Testing is performed with realistic data of the client to demonstrate that the software is working satisfactorily. Testing here is focused on external behavior of the system; the internal logic of program is not emphasized.
Test cases should be selected so that the largest number of attributes of an equivalence class is exercised at once. The testing phase is an important part of software development. It is the process of finding errors and missing operations and also a complete verification to determine whether the objectives are met and the user requirements are satisfied.
84 | P a g e
White Box Testing
This is a unit testing method, where a unit will be taken at a time and tested thoroughly at a statement level to find the maximum possible errors.
Black Box Testing
This testing method considers a module as a single unit and checks the unit at interface and communication with other modules rather getting into details at statement level. Here the module will be treated as a block that will take some input and generate output.
TEST INFORMATION FLOW
A strategy for software testing may also be viewed in the context of the spiral. Unit testing begins at the vortex of the spiral and, concentrates on each unit, component of the software as implemented in source code. Testing progresses moving outward along the spiral to integration testing, where the focus is on designed the construction of the software architecture. Taking another turn outward on spiral, we encounter validation testing, where requirements established as part of software requirements analysis are validated against the software that has been constructed. Finally, we arrive at system testing, where the software and other system elements are tested as a whole. To test computer software, we spiral out along stream lines that broaden the scope of testing with each turn.
85 | P a g e
System Testing
Validation Testing
Integration Testing
Validation testing
Design
System Engineering Code
System Engineering
86 | P a g e
Conclusion
With Enterprise Java Beans, you can develop building blocks -EJB components- that you or someone else can assemble and reassemble into different applications. EJB lets you focus on the business logic for your business, and leave the underlying services (transactions, networking, security, etc.) to the EJB server vendor. EJB lets you customize and configure reusable components at deploy time, without touching the source code. Enterprise Java Beans are portable- not just to different Java Virtual Machines, but to different EJB servers. One major benefit of EJB is WODA (Write Once Deploy Anywhere). WODA means that you need only one standard API rather than proprietary vendor-specific APIs.
So because of many advantages of the Enterprise Java Beans, they are widely used in the organizations, so this means while developing the EJBs there may at times the developer will encounter the situation that the EJB, he has developed needs to interact with another EJB which is being developed by some other person at will take time to be developed. So then He will have to wait to carry out unit testing of his EJB until the other EJB is developed so in this sort of situation he will lose precious time waiting for the other application to complete so for this we can implement this EJB Simulator which simulate the other EJB and the developer can move ahead with the unit test of his component and thus time will be saved. Thus the simulator has a very practical implementation as in enterprise such situations are encountered very often.
The Simulator is aimed at the providing the output to the calling EJB required for carrying out unit testing. The Simulator will work in the that the user will input the data corresponding to the methods contained in the Home and Remote interface of the EJB which is developed and he wants to carry out the unit testing so this data will be stored by the EJB Simulator and when those methods will call the simulator it will return the data as input to them and in this way it will communicate with the EJB, Hence, the Simulator is able to simulate the other EJB which is unavailable and the EJB at hand needs to interact with.
Thus, following the above approach the simulator we have developed is generic in nature it can be used for any EJB application that needs to undergo unit testing and for that it needs to interact with another EJB which is not available. So this Simulator can be implemented throughout the enterprise wide domain.
87 | P a g e
Future Enhancements
Because of time limitations, difficult decisions had to be made about which ideas to implement and how much time should be spent on them. However, the priorities and the choices made in this project have allowed serving the needs of the clients as the EJB Simulator can meet all the needs of the client for carrying out unit testing in the absence of the actual EJB with which Client’s EJB needs to interact. The project has successfully deployed EJB stub in place of the actual EJB.
The future commendable improvements can be made in the following areas:
The Graphical User Interface can be improved to make it more users friendly and thus it will improve the user’s ease of using the application. The Simulator at present can be used by the single EJB application; one enhancement that can be done is that it can handle 2 or more applications at the same time. The Simulator only provides the output object required by the calling method in the home and remote interface of the EJB, in future we can add the testing automation in simulator itself so that it can carry out unit testing as well and then the client will only need to provide with the data corresponding to the methods and the simulator will give output as the test results for the given EJB and thus whole process of the testing of an EJB will be automated.
88 | P a g e
References
Sun Microsystems: Java home page Sun Microsystems: Developer Resources for Java Technology.
Chamber of Chartered Java Professionals International: Professionalism for Java Technology.
Sun Microsystems: Java Language Specification 3rd Edition.
Java SE 6 API Javadocs
A Brief History of the Green Project
Michael O'Connell: Java: The Inside Story, SunWord, July 1995
Sun's EJB Product main page
Java EE 6 API Javadocs
EJB 3.0 API Javadocs
The EJB 3.0 Specification
Sun's EJB 3.0 Tutorial
EJB (3.0) Glossary
JSR 318 (EJB 3.1)
W3C XML homepage
Introduction to Generalized Markup by Charles Goldfarb
89 | P a g e
Making Mistakes with XML by Sean Kelly
The Multilingual WWW by Gavin Nicol
Retrospective on Extended Reference Concrete Syntax by Rick Jelliffe
XML, Java and the Future of the Web by Jon Bosak
XML tutorials in w3schools
Largest collections of JBoss tutorials
JBoss application server website
Securing JBoss
JBoss Wiki
JBoss.Org Community Projects
JBoss: The Evolution of Professional Open Source Software
Eclipse Plugin Central
Eclipse Marketplace
Eclipsepedia
IBM Rational and Eclipse
90 | P a g e