590 L – Distributed Component Architecture



590 L – Distributed Component Architecture

Medical Data Analysis

Project 4-2

Testing and System Documentation

Team Members:

Sravanthi Karumanchi

Shalini Pradhan

Galina Walters

I. Test Plan

TEST CASE 1.

Authenticating for valid user.

INPUT INFORMATION

1. Valid Username

2. Valid Password

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|The right login name and a fitting password are |The Output-Screen will be created by the OutputGenerator Servlet |Y |

|typed in. |and then displayed. | |

TEST CASE 2.

Invalid Log in

INPUT INFORMATION

1. Username

2. Password

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|The right login name and wrong password are typed in. |The “Access Denied JSP Page” -Screen will be created by the|Y |

| |OutputGenerator Servlet and then displayed. | |

TEST CASE 3.

Invalid Log in

INPUT INFORMATION

1. Username

2. Password

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|The wrong login name and a password. |The “Access Denied JSP Page” -Screen will be created by the |Y |

| |OutputGenerator Servlet and then displayed. | |

TEST CASE 4.

Request for information by a user logged in as a doctor

INPUT INFORMATION

1. Username

2. Password

3. Role retrieved from User database

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|All values appear once according to the role: doctor |Page formatted correctly with the permissions given is |Y |

|and permissions assigned to him. |displayed i.e., doctor page | |

TEST CASE 5.

Request for information by a user logged in as a researcher

INPUT INFORMATION

1. Username

2. Password

3. Role retrieved from User database

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|All values appear once according to the role: |Page formatted correctly with the permissions given is |Y |

|researcher and permissions assigned to him. |displayed i.e., the researcher page | |

TEST CASE 6.

Request for information by a user logged in as a researcher and a doctor

INPUT INFORMATION

4. Username

5. Password

6. Role retrieved from User database

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|All values appear once according to the role: |Page formatted correctly with the permissions given is |Y |

|doctor/researcher and permissions assigned to these |displayed i.e., the doctor page and researcher page | |

|roles. | | |

TEST CASE 7.

Request for individual patient record based on the Social Security Number queried by a doctor.

INPUT INFORMATION

1. Social Security Number.

|CONDITION |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|1.User is assigned a role as doctor |Page formatted correctly with the details of the patient|Y |

|2.The entered Social Security |whose social security number matches. | |

|Number is valid. | | |

|3. Display the record of the patient when Social | | |

|Security Number matches with the one entered and so| | |

|with the Username entered | | |

TEST CASE 8.

Request for list of patients records supervised by the doctor.

INPUT INFORMATION

1. Username.

2. Retrieve first name and last name of the doctor from the table.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|1. User is assigned the role as a doctor |Page formatted to display the patient records depending on |Y |

|2. Records of the patients that match the username |the last name and first name of the doctor retrieved from the| |

|are displayed |table is displayed. | |

TEST CASE 9.

Request for list of patients records sorted by age.

INPUT INFORMATION

1. Selecting age.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|1.Column consists of age of the patient. |Page formatted correctly with age as one value. |Y |

|2. User is assigned a researcher role | | |

TEST CASE 10.

Request for the list of patients records sorted by duration of disease

INPUT INFORMATION

1. Duration from when the disease prevails.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|1.When the radio button, duration is selected by a |Page formatted correctly with the following information: |Y |

|researcher, the records which show the duration from|Duration | |

|when the disease prevails are displayed. |Age | |

|2.User is assigned a role as a researcher |Admission date | |

TEST CASE 11.

Request for the list of patients records sorted by age.

INPUT INFORMATION

1. Name of the disease

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|1. When the disease is mentioned all records |Page formatted correctly with the following information for every| |

|matching the criteria are displayed |patient: | |

|2. User is assigned a role as a researcher |Age |Y |

| |Duration | |

| |Admission date |Y |

TEST CASE 12

Input transmission, HTML Form to the Servlet.

INPUT INFORMATION

1. Input attributes for database setup

2. Table column

3. Number of Classes

4. Computation actions

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|Valid database / table / column input |All attributes and their values appear correctly in the |Y |

| |Servlet. | |

TEST CASE 13.

Valid Extraction of data from the User database.

INPUT INFORMATION

1. database is set.

2. table is set.

3. column is set.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|Valid set database / table / column |Return value is a valid, not-empty ResultSet containing |Y |

| |Username, Role, Set of permissions. | |

|Database has entry in ODBC table | | |

TEST CASE 14.

Valid Extraction of data from the data database(1).

INPUT INFORMATION

4. database is set.

5. table is set.

6. column is set.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|Valid set database / table / column |Return value is a valid, not-empty ResultSet containing |Y |

| |patient’s information | |

|Database has entry in ODBC table | | |

TEST CASE 15.

Valid Extraction of data from the data database(2).

INPUT INFORMATION

7. database is set.

8. table is set.

9. column is set.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|Valid set database / table / column |Return value is a valid, not-empty ResultSet containing |Y |

| |patient’s information | |

|Database has entry in ODBC table | | |

TEST CASE 16.

Valid creation of the result Hashtable.

INPUT INFORMATION

1. Computation results.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|class returns valid ResultSet |Creation of a Hashtable with the following possible content | |

|Computations are correctly done |Patient record |Y |

| |Patient records based on age |Y |

| |Patient records based on duration of disease |Y |

| |Patient record based on doctor name |Y |

| |Patient record based on SSN |Y |

| | | |

TEST CASE 17.

Output of the retrieved results as HTML.

INPUT INFORMATION

1. filled result Hashtable.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|Valid filled result hashtable |All chosen results are printed on the screen |Y |

| |Patient Records |Y |

| |Patient Records based on age |Y |

| |Patient Records based on duration of the disease |Y |

| |Patient Records based on the Social Security Number mentioned| |

| | |Y |

TEST CASE 18.

All files can be accessed using Jboss (…

INPUT INFORMATION

1. WAR-archive

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|All files are in the right position in the War |If you type … |Y |

|archive |will be displayed or executed | |

| |DataAnalysis.html |Y |

| |Result.jsp |Y |

| |Accessdenied.jsp |Y |

TEST CASE 19.

Pressing “Back to main page”.

INPUT INFORMATION

1. Press the button “Back to home page”.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|The button “Back to home page” is visible. |The page home.html will be displayed. |Y |

TEST CASE 20.

The sending of a request without naming the operation or naming a wrong operation.

INPUT INFORMATION

1.

|CONDITION TABLE |EXPECTED OUTPUT / OBJECTIVE |OBJECTIVE |

| | |MET? |

|The operation name is not valid. |Display of the wrong.jsp page |Y |

System Documentation

Audience

This manual describes what system engineer should know about the Medical Data Analysis System.

System Description

The Medical Data Analysis System includes the use of Object Oriented Middleware technology (EJB), servlets, access to database through the use of ODBC/JDBC code, and output provided in HTML/XML format. Functionally the Medical Data Analysis System authenticates the user and allows a user to query the database consisting of a many tables with many columns to retrieve data. The location of the database is provided by a table, which is accessed by the servlet. This table contains the database name and ODBC/JDBC driver code. The tables within the databases and subsequent columns are dynamically located with SQL commands. When the user is authenticated, depending on the role he plays, the information is displayed to the user. For example if the user is a doctor, he can view all the information but if he is a researcher, certain data is kept from him to maintain privacy and security. The results are returned on the screen and available for printout in HTML/XML format. EJB OO Middleware was used to allow for distributed communication between remote objects.

Detailed Object/Component Description

Web Server Subsystem – technology used (Jetty). This subsystem contains objects.

1. OutputGenerator extends HttpServlet. OutputGenerator provides input as well as displays output (i.e. provides connection to session bean and receives output from the session bean). The Servlet contains the following private attributes: establishBeanConnection().

2. RecordRetrievalBean - Entity bean, which displays a record of the patient queried by the doctor.

3. ListRetrievalBean- Entity bean, which displays records of all the patients queried by the researcher or the doctor.

4. Filter Bean – This is a session bean and the queries and retrieved data are passed through this bean to the rest of the entity bean. The filter bean basically filters data depending on the role played by the user such as a doctor or a researcher.

5. UserBean-This is an entity bean where the user is authenticated.

6. User interface – user interface object. Created through the use of the display or keyboard.

7. Printer interface – output device interface (results of computation generated in HTML). Created by user through selection of print option after computation option selection.

EJB Server Subsystem – technology used (JBOSS). The EJB Server Subsystem contains the following objects:

1. FilterBean (session Bean) - controls the work flow and interaction between the webserver and database options. Attributes include the computation(s) selected, tasks, retrieval, and ctx: SessionContext. Operations include: setSessionContext(context:Session), ejbActivate(), ejbPassivate(), ejbRemove(), ejbCreate(), setTask(_tasks:Hashtable).

2. FilterHome Interface – defines the life-cycle methods of FilterBean.

3. FilterRemote Interface – RemoteObject of the Filter EJB with the methods :

• GetLName(string username, string password)

• GetfName(string username, string password)

• Getaccess(string username, string password)

4. tempCensor interface – system interface object

5. PCI interface – system interface object

6. Patient interface – system interface object

7. Cath interface – system interface object

8. Admit interface – system interface object

Inter-dependency between component or between object (side-effect of changes)

Computation and StatisticsServlet:

The addition or subtraction of code to the filter bean changed the code in the statisticalServlet code.

Between the Application server objects:

The Inter-dependency between the Application server objects are very low. We use for sending Information the very flexible Hashtable, which can store an almost unlimited amount of Objects. The dependency between the objects is reduced to know the Class type and the key-name. If there are any changes in future, the sender can put additional objects in the Hashtable and the receiver can get these additional objects without causing extra traffic or changing the method invocation.

Retrieval and Computation:

The result of the search (ResultSet) is sent directly to the filter class so that changes in the structure of the result of the database cause only a change in the filter class itself and of course in the SQL statement.

Servlet and JSP:

The Inter-dependency between the Web server objects are very low, too. The Web server is using one Main-Servlet. This concentration has the heavy advantage of adding or changing the appearance is very easy with JSP’s and without extra compilation.

Technology and tool description (setup, constraints, steps, etc)

JAVA2 Enterprise Edition 1.3 and 2.0

[pic]

We used the current Enterprise version 1.3 because all application vendors support this specification. The J2EE platform is designed to provide server-side and client-side support for developing enterprise, multitier applications. Such applications are typically configured as a client tier to provide the user interface, one or more middle-tier modules that provide client services and business logic for an application, and backend enterprise information systems providing data management. The J2EE platform specifies technologies to support multitier enterprise applications. These technologies fall into three categories: component, service, and communication. The component technologies are those used by developers to create the essential parts of the enterprise application, namely the user interface and the business logic. The component technologies allow the development of modules that can be reused by multiple enterprise applications. The component technologies are supported by J2EE platform system-level services, which simplify application programming and allow components to be customized to use resources available in the environment in which they are deployed. Since most enterprise applications require access to existing enterprise information systems, the J2EE platform supports APIs that provide access to database, transaction, naming and directory, and messaging services. Finally, the J2EE platform provides technologies that enable communication between clients and servers and between collaborating objects hosted by different servers. In addition to JavaBeans components, which are part of the J2SE platform, the J2EE platform supports the following types of components: applets, application clients, Enterprise Java Beans components, and Web components, which are important for our project. Applets and application clients run on a client platform and EJB and Web components run on a server platform (which is in our case JBOSS and JETTY). All J2EE components depend on the runtime support of a system-level entity called a container. Containers provide components with services such as life naming, cycle management, security (Authentication and Authorisation, which are very important in the hospital), deployment, and threading. Because containers manage these services, many component behaviours can be declaratively customised when the component is deployed in the container. Communication technologies provide mechanisms for communication between clients and servers and between collaborating objects hosted by different servers: Internet protocols, Remote method invocation protocols, Object Management Group (OMG) protocols, Messaging technologies (Java Message Service (JMS), Java Mail) and Data formats (HTML3.2, XML, Image files, JAR files).

Java needs an Operating system which supports Java (e.g. Windows, UNIX, LINUX, Solaris). It is free available at java.. After downloading and installing of the latest version you need to set the Java specific environmental variable JAVA_HOME that has to point to the installation directory of Java. The Java 2 Enterprise Edition (J2EE) needs the Java 2 Standard Edition (J2SE) environment. All Operating Systems that are support J2SE will support J2EE also.

JBOSS 2.4.1

J2EE provides a range of server choices. We used JBOSS 2.4 because it is free, available, and open-source. Because we do not have to use JBOSS specific features, the EJB-jar files can easily be transferred to another Application server. Most times you can get hints from the JBoss forum or ask directly. The Answers are most times very fast (within 24h).

ANT 1.4

Ant is a freely available Java based build tool. Instead of writing shell commands, the configuration files are XML based calling out a target tree where various tasks get executed. Each task is run by an object which implements a particular task interface and gives you the ability to cross platforms. For the development of Enterprise Java beans ANT is a valuable tool easily creating class-files for all our purposes.

JETTY 3.1.0

We needed a web server to generate results as HTML and send the result to the client. Jetty is an open source HTTP Servlet Server written in Java and supports the HTTP/1.0 and HTTP/1.1 protocols. It also supports the 2.2 javax. Servlet API defined by Javasoft and includes a JSP package which is currently the Jasper JSP engine from apache. Jetty uses Sun's JSSE reference implementation to provide support for HTTPS. The Jetty3Extra repository contains extensions such as JMX configuration and SASL authentication. It is designed to be lightweight, high performance, embeddable, extensible and flexible, thus making it an ideal platform for serving dynamic HTTP requests from any Java application. Jetty can be used as a stand-alone server running application servlets or it can be embedded in Java application to provide a WWW interface to the services that they provide. The configuration of a server is controlled by: J2EE deployment descriptors. Direct API calls, and XML configuration. Jetty has been instrumented as JMX model MBeans which allows it to be seamlessly integrated into the JBOSS EJB application server. This gives a complete J2EE container with HTTP, Servlets, JSPs and EJBs all within a single JVM.

JBOSS/Jetty/ANT installation involves the following steps:

Goto and download JBoss- 2.4.1_Jetty-3.1.RC9-1.zip. Unzip it in your Y: drive to have a directory hierarchy such as follows: Y:\JBoss-2.4.0_Jetty-3.1.RC8-1\JBoss-2.4.0_Jetty-3.1.RC8-1\jboss...

Goto ant/release/v1.3/bin/ to download the Ant build tool. Download jakarta-ant-1.3-bin.zip. Unzip this zip file to make a directory structure as follows: Y:\Ant\jakarta-ant-1.3\...

Goto to download the examples. Download documentation-example.zip. Unzip it make a directory structure as follows: Y:\examples\build\...

Assuming you have downloaded and unzipped all the files in the way I have specified above creating the required directory structure on your network drive Y:, run the attached batch file which would set up all the required environment variables.

Goto Y:\JBoss-2.4.0_Jetty-3.1.RC8-1\JBoss-2.4.0_Jetty-3.1.RC8-1\jboss\bin and type run jetty on the command prompt to start the AppServer/WebServer/Servlet Engine.

Remember one thing. Once you open a DOS window and then run the batch file to set up all the environment variables and close the DOS window, the setting up of all the variables in invalidated. So, if u open the DOW window again, make sure that you run the batch file again before trying to start the Server.

MS SQLServer /MS Access 2000

We provided drivers for several databases options that use MS SQL Server or MS ACCESS Technologies. These databases provided the input necessary to do the statistical analysis. Installation includes creating an ODBC/JDBC Java file, and compiling this file to create a class, which allows communication with the database.

To Activate the Medical Data Analysis System do the following:

1. Go to the dos command and type in the path for Y: jboss\jboss\JBOSS\bin. At the prompt type run jetty. This activates the web server.

2. To run the Servlet ….Open a new dos file and go to

MedAccontroller/medical/build

• First type: ant medical-compile-web

• Next type: ant medical-compile-app

• Next type: ant medical-ear

• Next type: ant medical-jar

• Next type: ant medical-war

• Next type: ant medical-deploy

3. Copy the ear file which is in the build files folder to the JBOSS\JBOSS\Deploy folder

4. Type to launch web interface. Select options at will.

Guideline for development process for system developer

Server

Choose a web server and ejb server. Configure each.

Build tool

Choose a build tool.

Classes and Interfaces

To implement an enterprise bean, you need to define two interfaces and two classes:

The remote interface for an enterprise bean defines the bean's business methods: the methods a bean presents to the outside world to do its work. The remote interface extends javax.ejb.EJBObject, which in turn extends java.rmi.Remote. (the entity that actually implements this interface is the EJB object.)

The home interface defines the bean's life cycle methods: methods for creating new beans, removing beans, and finding beans. The home interface extends javax.ejb.EJBHome, which in turn extends java.rmi.Remote. (the object that implements the home interface is the EJB home.)

The bean class actually implements the bean's business methods. Surprisingly, the bean class usually does not implement the bean's home or remote interfaces. However, it must have methods matching the signatures of the methods defined in the remote interface and must have methods corresponding to some of the methods in the home interface. An entity bean must extend javax.ejb.EntityBean; a session bean must extend javax.ejb.SessionBean. Both EntityBean and SessionBean extend javax.ejb.EnterpriseBean.

The primary key is a very simple class that provides a pointer into the database. Only entity beans need a primary key; the only requirement for this class is that it implements Serializable. Session beans don't have a primary key. That's because session beans are not persistent themselves, so there is no need for key that maps to the database. We only used session beans in our system. Therefore we did not have a need for a primary key.

Deployment Descriptors, JAR files, EAR files, and WAR files

Much of the information about how beans are managed at runtime is not addressed in the interfaces and classes discussed previously. Primary services (security, transactions, naming) are handled automatically by the EJB server, but the EJB server still needs to know how to apply the primary services to each bean class at runtime. To do this, use a set of classes called deployment descriptors.

Deployment descriptors are serialized classes that serve a function very similar to property files. Like property files, deployment descriptors allow us to customize behavior of software (enterprise beans) at runtime without having to change the software itself. Property files are often used with applications, but deployment descriptors are specific to a class of enterprise bean. Deployment descriptors are also similar in purpose to property sheets used in Visual Basic and PowerBuilder. Where property sheets allow us to describe the runtime attributes of visual widgets (background color, font size, etc.), deployment descriptors allow us to describe runtime attributes of server-side components (security, transactional context, etc.). Deployment descriptors allow certain runtime behaviors of beans to be customized, without altering the bean class or its interfaces.

When a bean class and its interfaces have been defined, a deployment descriptor for the bean is created and populated with data about the bean. Frequently, IDEs (Integrated Development Environments) that support development of Enterprise JavaBeans will allow developers to graphically set up the deployment descriptors using visual utilities like property sheets. After the developer has set all the properties for a bean, the deployment descriptors are serialized and saved to a file. Once the deployment descriptors are complete and saved to a file, the bean can be packaged in a JAR file for deployment.

JAR ( Java archive) files are ZIP files that are used specifically for packaging Java classes that are ready to be used in some type of application. JARs are used for packaging applets, Java applications, JavaBeans, and Enterprise JavaBeans. The JAR file for an enterprise bean includes the bean class, remote interface, home interface, primary key (EntityBean types only), a manifest, and the serialized deployment descriptor. The JAR's manifest (a kind of table of contents for the JAR) has an entry that points to the serialized deployment descriptor. When a bean is deployed, the JAR's path is given to the container's deployment tools, which read the JAR file. The first thing read out of the JAR file after the manifest is the deployment descriptor.

When the JAR file is read at deployment time, the container tools deserialize the deployment descriptor and then read its properties to learn about the bean and how it should be managed at runtime. The deployment descriptors' properties tell the deployment tools what kind of bean it is (SessionBean or EntityBean), how the bean should be used in transactions, who has access to the bean at runtime, and other runtime attributes of the bean. The person who is deploying the bean can alter some of these settings, like transactional and security access attributes, to customize the bean for a particular application. Many container tools provide property sheets for graphically reading and altering the deployment descriptor when the bean is deployed. These graphical property sheets are the similar to those used by bean developers.

The deployment descriptors help the deployment tools to add the bean to the EJB container. Once the bean is deployed, the properties described in the deployment descriptors will continue to be used to tell the EJB server how to manage the bean at runtime.

An EAR file is used to package one or more J2EE modules into a single module so that they can have aligned classloading and deployment into a server.

A WAR file contains a single web application. As an EAR file can contain multiple web applications, each web application in an EAR file must have a unique deployment context. The deployment mechanism for EAR files allows just such a specification of different contexts.

Deployment descriptors are serializable classes that describe the bean and some of its runtime behavior to the container.

Database Access

EJB offers a standard method of accessing JDBC. Using this method has several advantages. It allows the EJB container to add connection pooling automatically to your JDBC access. Furthermore, it allows you to add several EJBs within a "transaction".

Web Interface

Create an interface to the web server. This can be done using servlets and/or JSP. The web container provides interception for requests sent over HTTP, FTP, SMTP, and other protocols. Most web containers only provide support for HTTP(S), but could support a broader range of protocols if they so chose. The web application container allows JSP pages and servlets to have access to the same resources as the EJB container provides.

Organization of source code

The Source code is organized in 2 subpackages of the “umkc” package. In the subpackage “appserver” are all components for the application server JBOSS:

o All EJB parts (Filterbean.java, FilterHome.java, FilterRemote.java)

o The Connection –Class to the Databases (UserBean.java)

o XML files for building the JAR-archive (build.xml, ejb-jar.xml, application.xml)

In the subpackage “web” are all components for the web server JBOSS-JETTY:

o The MainServlet(OutputGeneartor.java) (includes right now the dataanalysis.jsp , doctor.jsp, reseacher.jsp )

o The Start page (DataAnalysis.html)

o The JSP file (AccessDenied.jsp)

o XML files for building the WAR-archive (build.xml, web.xml, jboss-web.xml)

Also necessary is the main build.xml file in the build subfolder, which is necessary for building the final EAR-archive. The ANT-tool creates a new folder “build-files” with subfolders classes, META-INF, WEB-INF, and classes, and also the archives WAR, JAR and EAR.

Installation guide and platform (or any environmental restriction) specification

To install the application, you need the following programs:

o JBOSS 2.2 or 2.4

o JETTY 3.1 or later

o JAVA J2SE 1.3 or later

o JAVA J2EE 1.3 or later

o ANT 1.4 or later

o Operating system which support Java

First you have to install the programs, and setting the paths for the programs.

Windows 9x : Autoexec.bat

Windows NT/2000 : Settings/ Control panel/System/Advanced at Button Environment Variables :

Set the JAVA_HOME, JBOSS_HOME, JBOSS_DIST variables (e.g. JAVA_HOME=C:\Java1.3.1 )

Set the PATH to java\bin, ant\bin, jboss\bin

(depends where you stored the files, e.g. PATH = C:\Java1.3.1\bin; … )

Set the ODBC Sources:

Settings/Administrative Tools/Data Source (ODBC)

Choose Add and the driver for your database (e.g. MS Access or SQL Server)

and specify then the path to the database.

Do this for all databases you want to use.

For starting the JBOSS-Application server go into the bin subfolder of JBOSS and type “run jetty”.

A successful start means that a DOS-Console appears and after 15-40 seconds the last line appears e.g.:

[JettyService] Started

[Service Control] Started 48 services

[Default] JBoss 2.4.1 Started in 0m:33s

If you want to stop JBOSS use CTRL+C.

If you have problems with starting JBOSS look at the page and then to the forums

or direct: .

To create a new EAR-archive and deploy this archive, open a new DOS-Console, go to the BUILD-subfolder of the source files and type:

ant medical-war

ant medical-deploy

If the deploy was successful the following will be displayed:

[Jetty] successfully deployed file:/Y:/jboss/tmp/deploy/Default/medical.ear/web100/ to /appserver/*

[J2EE Deployer Default] J2EE application: file:/Y:/jboss/deploy/medical.ear is deployed.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download