What is Java 2 Micro Edition?
Java is known primarily as a server-side programming environment, centered around the technologies that make up the Java 2 Enterprise Edition (J2EE), such as Enterprise JavaBeans (EJBs), servlets, and JavaServer pages (JSPs). Early adopters of Java, however, will recall that it was originally promoted as a client-side application environment. In fact, Java was originally designed as a programming language for consumer appliances. Now Java is returning to its roots with Java 2 Micro Edition, or J2ME for short. This article, the first in a series on J2ME programming, explains what J2ME is.
The Java 2 Platform
What we commonly refer to as "Java" is more formally known as the Java 2 Platform. The Java 2 Platform is split into three editions: Java 2 Standard Edition (J2SE), Java 2 Enterprise Edition (J2EE), and Java 2 Micro Edition (J2ME). Each edition of the platform provides a complete environment for running Java-based applications, including the Java virtual machine (VM) and runtime classes.
The three editions all target different kinds of applications running on different kinds of devices. Desktop-based applications are developed using J2SE, which provides the necessary user interface classes. Server-based applications are developed using J2EE, which emphasizes component-based programming and deployment. Handheld and embedded devices are targeted by J2ME.
What separates one edition from another, then, is primarily the set of class libraries that each edition defines. Loosely speaking, you can think of J2ME as a subset of J2SE and J2SE as a subset of J2EE. It is possible to run the same Java bytecode in each edition, providing the classes referred to by the bytecode are available in all three editions. The catch, of course, is that J2ME-based devices have fewer classes than what J2SE and J2EE provide, especially the smaller devices. After all, there are several thousand core J2SE runtime classes, taking up ten to twenty megabytes of space, which is simply too big for the majority of devices out there today and in the near future.
The various specifications that comprise J2ME are all defined through the Java Community Process (JCP), as is done with J2SE and J2EE. Today, there are close to forty separate Java Specification Requests (JSRs) dealing with J2ME: Small device programming is definitely a hot topic within the Java community. (For more information, see the main JCP Web site at www.jcp.org.)
Java 2 Micro Edition
In J2ME, the Java runtime environment is adapted for constrained devices - devices that have limitations on what they can do when compared to standard desktop or server computers. For low-end devices, the constraints are fairly obvious: extremely limited memory, small screen sizes, alternative input methods, and slow processors. High-end devices have few, if any, of these constraints, but they can still benefit from the optimized environments and new programming interfaces that J2ME defines.
Learning about J2ME is not hard: Once you understand the new terminology, it's mostly about learning new APIs (application programming interfaces) and learning how to work in constrained environments. (If you think writing an applet is challenging, wait until you try to fit an application into the 30K of memory some cellphones provide!) You can use most of the same tools you already use in your code development, and with careful coding you can develop libraries of classes that are portable to any device or computer with a Java virtual machine.
PersonalJava and EmbeddedJava
J2ME is not the first attempt at adapting Java for constrained environments. Two other technologies, PersonalJava and EmbeddedJava, made it possible to run Java 1.1.x applications on high-end devices.
PersonalJava uses the basic Java 1.1 runtime classes and throws in a few features from Java 2. Support for some of the runtime classes is optional, but a PersonalJava implementation still requires a couple of of megabytes of memory and a fast processor to run, so it's not a practical solution for truly constrained devices like cellphones and many personal digital assistants.
EmbeddedJava makes every behavior of both the Java VM and the runtime classes optional - the implementor can choose exactly which classes and methods are required. There is one limitation, however: The Java runtime environment can only be used by the implementor and cannot be exposed to third parties. In other words, you can use it to write Java code that runs inside a device, usually as part of the software to control the device, but no one else can write applications for the device. This is done to preserve the "write once, run anywhere" nature of Java, since an EmbeddedJava environment can do away with fundamental things like runtime class verification and change the public interfaces of core classes. EmbeddedJava is really a way to build a "private" Java runtime environment.
Both PersonalJava and EmbeddedJava are being phased out. There is a migration path from PersonalJava to J2ME, as we'll see later in this series, though the current version of PersonalJava continues to be supported. EmbeddedJava is no longer supported because J2ME defines suitable small-footprint runtime environments.
Monday, June 30, 2008
Saturday, May 17, 2008
What is Struts
Introduction
The Struts Framework is a standard for developing well-architected Web applications. Based on the Model-View-Controller (MVC) design paradigm, it distinctly separates all three levels (Model, View, and Control). It also offers the following features:
* Open source
* Implements the JSP Model 2 Architecture
* Stores application routing information and request mapping in a single core
file, struts-config.xml
* The Struts Framework, itself, only fills in the View and Controller layers. The
Model layer is left to the developer.
This Artical will explain you, what struts is, how it builds itself up and why it is advantage to use it for your web application. First, I will provide you some informations about Java Servlets, Java Server Pages and Java Beans, because they are parts of struts.
Java Servlets
Servlets represents java programs that runs on a web server. They allow the developer to produce dynamic web sites with java.
A Servlet has the following tasks
* It reads and processed data, which a user typed in a HTML form on a web page.
* If necessary other informations will be processed. For Example what browser or
system will be used.
* It generate results with the existing data. It calls the business logic
directly in the servlet or another class, which contain the logic or executes a
database query.
* The results will be formated. If the browser. If the Browser expects an answer
in the HTML format, then the results must be formatted in accordance with the
standard. It is possible to return different formats of data with a servlet.
(gif, jpeg, doc, etc.).
* Suitable answer parameters are set. Befor the servlet return the data to the
browser, it sends some parameter. The parameter contains the format, that will
returned by the servlet, what time the browser use to cache the site and some
more.
* Return the document, in the format that it sends befor, to the browser.
Java Server Pages (JSP)
JavaServer Pages (JSP) are text documents, which are similar to HTML Files. But you find also java code in the JSP File. JavaServer Pages allow you to mix regulare, static HTML with dynamic generated contents of servlets. The java code is inserted in the HTML document on a JSP File, differently to a servlet, where the HTML code is embedded in the java code.
Java Beans
Java Beans are nothing else as classes, which keep a fixed naming convention, defined by Sun, for their event processing and methods. The attributes (variables) of the java beans are private. The access to these attributes is managed by access methods. The java specification specify these access methodes (getter and setter methods). If a java bean contains a attribute name, you can set or get the value of the attributes with the methode setName() or getName().
Business logic
The business logic is the core of the application. The processes are implemented in the business logic to manage the data. For Example: when someone borrows a book in a library, that is a process in the business logic. The process change the state of the data (is the book borrowsed or not) or reads the state and then provide this information for a dialog.
This short outline should be sufficient, in order to understand the structure of struts.
Why is struts helpful?
Sepration of dialogs and business logic (functionality)
Some peoples develop web applications with Perl or PHP and implement their SQL Querys and the business logics directly in the HTML document.
The source code looks like the following example:
You can develop in this way, when you use java servlets or JSP. It is convenient in small projects. But imagine you have 70 dialogs, many database querys in this dialogs and you want to define a field status, setting if a book is deleted or not.
Good luck
In order to alter functions and database querys easily, we should seperate these from the dialogs.
Advantage of separation
* Changes on the functionality, without working in the dialogs.
* Better overview, functionality not mixed with the dialogs.
* Easy maintain a application
* Different dialogs, but the same functionality
Central control
In order to control the interaction between the dialogs and business processes, you need a central control unit. This control unit manage all importants courses of the application, when which business process and which dialog will be used.
You have some disadvantages, if you implement the order of the processes directly to the business logic.
1. You can not reuse a part of the processes. In the following picture the process
"Give Money" will bring you to the process "Select sort of icecream" every
time.
2. If you want to change the order of the processes or add more options, you have
to change it directly in the business logic.
Advantages of the central control
* It is easy to change the order of the business processes.
* Better overview, which dialogs will be used on which business processes.
* A central place to control the interaction between business processes and
dialogs.
Translation into the technical language
The name of this model is Model-View-Controller (MVC)
Model (business logic / business processes ? Java Beans)
View (dialogs ? JavaServer Pages)
Controller (central control unit - Java Servlets)
You will find more about the MVC later in this tutorial.
More helpfully capabilities
Internationalisation
If you do not want to translate a dialog, you put the dialog texts directly into the JSP File.
Struts support resources files. In this files you can define a key for a text.
This key can be used to diplay the text in the JSP file.
Struts call the locale specific resource file by using the browser settings. You may overwrite this setting. It is quite easy to build an internationalized application with struts.
Error handling
Struts saves error messages in the business logic and can display this in the dialogs. You can show all errors or bind an error to a field (ex. Emailaddress incorrect) and show the error beside of it.
The error messages will be added to the resource files, so the errors can be internationalised too.
Validation of input fields
Whether an input field of a form contains a valid date, an email, a number or something else, in each application you have to check it. Struts supports a complete solution to validate form fields. You only have to define which form field will be checked and which error message will be displayed.
Components of struts
JavaServer Pages (JSP) take over the role of dialogs in struts,
Java Beans take over the business logic and business processes and
Java Servlets take over the central control unit
Thats why we talk about three great parts of struts.
Model (business logic / business processes ? Java Beans)
View (dialogs ? JavaServer Pages)
Controller (central control unit - Java Servlets)
The model represent the actual state of the application. Two kinds of java beans are used. There are java beans which contains the data of a form or data to display (ex. The books of a library) and java beans which includes the functionality of the application or call the business logic (when a user borrows a book).
The view component is responsible for the presentation of the data. The java server pages contain HTML, XML and Java Script, like a normal HTML site. Futhermore you can use java code. Struts provide tag libraries, a summary of functions, which can be use to prepare the data for displaying.
The last component is the controller. The controller manage the request of the web browser, which a user called by an address (URL). But also forward to an action which are execute and which dialogs will be used to display the informations.
The picture below illustrates the interaction between these components.
If the user sends a query with a browser, the controller(servlet) gets and processes this query. It decides which action will be called or to which view component it must be forward.
After the controller calls an action, the action can read data from a database and provide this data to the model component, java beans. The action (business logic) returns the "next step" to the controller. The controller checks what kind is the next step. (JSP View, next action, ...) and forwards to it.
The view component (JSP) reads the updated data from the model component and prepare this for the presentation. Then it sends the answer as HTML site back to the browser. The user sees the result of his query.
Struts configuration
Struts will be configured with various configuration files. The following files are very important.
web.xml
struts-config.xml
Struts-Tag-Bibliotheken
Properties-Dateien
The illustration will show you, on which places struts use the configuration files.
web.xml
With the web.xml you configure the web server for the struts application. In this file you can set where the web server find the struts-config.xml and some other global properties.
struts-config.xml
The controller calls the business logic or a view with a name. The allocation of the names to the action classes or JSP Files(Views) will be set in the struts-config.xml. The advantage is that you can change the definition of the Workflows (Action Mapping), without using the long class names everytime. If you change a class name, you only have to change the name in the struts-config.xml. You don´t update any other part of your application.
Struts-Tag-Libraries
The Struts-Tag-Libraries, a summary of functions, extends the functionality of JavaServer pages. They support the internationalisation (multi-language) of your web application, and the easy creation of form elements.
Properties files
This files will be used to keep the internationalized textes of your web application. You can create a seperated properties file for each language, which contain all textes of the application.
Thats all with this short introduction in struts.
The Struts Framework is a standard for developing well-architected Web applications. Based on the Model-View-Controller (MVC) design paradigm, it distinctly separates all three levels (Model, View, and Control). It also offers the following features:
* Open source
* Implements the JSP Model 2 Architecture
* Stores application routing information and request mapping in a single core
file, struts-config.xml
* The Struts Framework, itself, only fills in the View and Controller layers. The
Model layer is left to the developer.
This Artical will explain you, what struts is, how it builds itself up and why it is advantage to use it for your web application. First, I will provide you some informations about Java Servlets, Java Server Pages and Java Beans, because they are parts of struts.
Java Servlets
Servlets represents java programs that runs on a web server. They allow the developer to produce dynamic web sites with java.
A Servlet has the following tasks
* It reads and processed data, which a user typed in a HTML form on a web page.
* If necessary other informations will be processed. For Example what browser or
system will be used.
* It generate results with the existing data. It calls the business logic
directly in the servlet or another class, which contain the logic or executes a
database query.
* The results will be formated. If the browser. If the Browser expects an answer
in the HTML format, then the results must be formatted in accordance with the
standard. It is possible to return different formats of data with a servlet.
(gif, jpeg, doc, etc.).
* Suitable answer parameters are set. Befor the servlet return the data to the
browser, it sends some parameter. The parameter contains the format, that will
returned by the servlet, what time the browser use to cache the site and some
more.
* Return the document, in the format that it sends befor, to the browser.
Java Server Pages (JSP)
JavaServer Pages (JSP) are text documents, which are similar to HTML Files. But you find also java code in the JSP File. JavaServer Pages allow you to mix regulare, static HTML with dynamic generated contents of servlets. The java code is inserted in the HTML document on a JSP File, differently to a servlet, where the HTML code is embedded in the java code.
Java Beans
Java Beans are nothing else as classes, which keep a fixed naming convention, defined by Sun, for their event processing and methods. The attributes (variables) of the java beans are private. The access to these attributes is managed by access methods. The java specification specify these access methodes (getter and setter methods). If a java bean contains a attribute name, you can set or get the value of the attributes with the methode setName() or getName().
Business logic
The business logic is the core of the application. The processes are implemented in the business logic to manage the data. For Example: when someone borrows a book in a library, that is a process in the business logic. The process change the state of the data (is the book borrowsed or not) or reads the state and then provide this information for a dialog.
This short outline should be sufficient, in order to understand the structure of struts.
Why is struts helpful?
Sepration of dialogs and business logic (functionality)
Some peoples develop web applications with Perl or PHP and implement their SQL Querys and the business logics directly in the HTML document.
The source code looks like the following example:
You can develop in this way, when you use java servlets or JSP. It is convenient in small projects. But imagine you have 70 dialogs, many database querys in this dialogs and you want to define a field status, setting if a book is deleted or not.
Good luck
In order to alter functions and database querys easily, we should seperate these from the dialogs.
Advantage of separation
* Changes on the functionality, without working in the dialogs.
* Better overview, functionality not mixed with the dialogs.
* Easy maintain a application
* Different dialogs, but the same functionality
Central control
In order to control the interaction between the dialogs and business processes, you need a central control unit. This control unit manage all importants courses of the application, when which business process and which dialog will be used.
You have some disadvantages, if you implement the order of the processes directly to the business logic.
1. You can not reuse a part of the processes. In the following picture the process
"Give Money" will bring you to the process "Select sort of icecream" every
time.
2. If you want to change the order of the processes or add more options, you have
to change it directly in the business logic.
Advantages of the central control
* It is easy to change the order of the business processes.
* Better overview, which dialogs will be used on which business processes.
* A central place to control the interaction between business processes and
dialogs.
Translation into the technical language
The name of this model is Model-View-Controller (MVC)
Model (business logic / business processes ? Java Beans)
View (dialogs ? JavaServer Pages)
Controller (central control unit - Java Servlets)
You will find more about the MVC later in this tutorial.
More helpfully capabilities
Internationalisation
If you do not want to translate a dialog, you put the dialog texts directly into the JSP File.
Struts support resources files. In this files you can define a key for a text.
This key can be used to diplay the text in the JSP file.
Struts call the locale specific resource file by using the browser settings. You may overwrite this setting. It is quite easy to build an internationalized application with struts.
Error handling
Struts saves error messages in the business logic and can display this in the dialogs. You can show all errors or bind an error to a field (ex. Emailaddress incorrect) and show the error beside of it.
The error messages will be added to the resource files, so the errors can be internationalised too.
Validation of input fields
Whether an input field of a form contains a valid date, an email, a number or something else, in each application you have to check it. Struts supports a complete solution to validate form fields. You only have to define which form field will be checked and which error message will be displayed.
Components of struts
JavaServer Pages (JSP) take over the role of dialogs in struts,
Java Beans take over the business logic and business processes and
Java Servlets take over the central control unit
Thats why we talk about three great parts of struts.
Model (business logic / business processes ? Java Beans)
View (dialogs ? JavaServer Pages)
Controller (central control unit - Java Servlets)
The model represent the actual state of the application. Two kinds of java beans are used. There are java beans which contains the data of a form or data to display (ex. The books of a library) and java beans which includes the functionality of the application or call the business logic (when a user borrows a book).
The view component is responsible for the presentation of the data. The java server pages contain HTML, XML and Java Script, like a normal HTML site. Futhermore you can use java code. Struts provide tag libraries, a summary of functions, which can be use to prepare the data for displaying.
The last component is the controller. The controller manage the request of the web browser, which a user called by an address (URL). But also forward to an action which are execute and which dialogs will be used to display the informations.
The picture below illustrates the interaction between these components.
If the user sends a query with a browser, the controller(servlet) gets and processes this query. It decides which action will be called or to which view component it must be forward.
After the controller calls an action, the action can read data from a database and provide this data to the model component, java beans. The action (business logic) returns the "next step" to the controller. The controller checks what kind is the next step. (JSP View, next action, ...) and forwards to it.
The view component (JSP) reads the updated data from the model component and prepare this for the presentation. Then it sends the answer as HTML site back to the browser. The user sees the result of his query.
Struts configuration
Struts will be configured with various configuration files. The following files are very important.
web.xml
struts-config.xml
Struts-Tag-Bibliotheken
Properties-Dateien
The illustration will show you, on which places struts use the configuration files.
web.xml
With the web.xml you configure the web server for the struts application. In this file you can set where the web server find the struts-config.xml and some other global properties.
struts-config.xml
The controller calls the business logic or a view with a name. The allocation of the names to the action classes or JSP Files(Views) will be set in the struts-config.xml. The advantage is that you can change the definition of the Workflows (Action Mapping), without using the long class names everytime. If you change a class name, you only have to change the name in the struts-config.xml. You don´t update any other part of your application.
Struts-Tag-Libraries
The Struts-Tag-Libraries, a summary of functions, extends the functionality of JavaServer pages. They support the internationalisation (multi-language) of your web application, and the easy creation of form elements.
Properties files
This files will be used to keep the internationalized textes of your web application. You can create a seperated properties file for each language, which contain all textes of the application.
Thats all with this short introduction in struts.
Wednesday, May 14, 2008
ServletConfig and ServletContext
There is only one ServletContext in every application. This object can be used by all the servlets to obtain application level information or container details. Every servlet, on the other hand, gets its own ServletConfig object. This object provides initialization parameters for a servlet. A developer can obtain the reference to ServletContext using either the ServletConfig object or ServletRequest object.
Servlet containers
A Servlet container is a specialized web server that supports Servlet execution. It combines the basic functionality of a web server with certain Java/Servlet specific optimizations and extensions – such as an integrated Java runtime environment, and the ability to automatically translate specific URLs into Servlet requests. Individual Servlets are registered with a Servlet container, providing the container with information about what functionality they provide, and what URL or other resource locator they will use to identify themselves. The Servlet container is then able to initialize the Servlet as necessary and deliver requests to the Servlet as they arrive. Many containers have the ability to dynamically add and remove Servlets from the system, allowing new Servlets to quickly be deployed or removed without affecting other Servlets running from the same container. Servlet containers are also referred to as web containers or web engines.
Like the other Java APIs, different vendors provide their own implementation of the Servlet container standard. For a list of some of the free and commercial web containers, see the list of Servlet containers. (Note that 'free' means that non-commercial use is free. Some of the commercial containers, e.g. Resin and Orion, are free to use in a server environment for non-profit organizations).
Like the other Java APIs, different vendors provide their own implementation of the Servlet container standard. For a list of some of the free and commercial web containers, see the list of Servlet containers. (Note that 'free' means that non-commercial use is free. Some of the commercial containers, e.g. Resin and Orion, are free to use in a server environment for non-profit organizations).
Lifecycle of a Servlet
The Servlet lifecycle consists of the following steps:
1. The Servlet class is loaded by the container during start-up.
2. The container calls the init() method. This method initializes the servlet and must be called before the servlet can service any requests. In the entire life of a servlet, the init() method is called only once.
3. After initialization, the servlet can service client-requests. Each request is serviced in its own separate thread. The container calls the service() method of the servlet for every request. The service() method determines the kind of request being made and dispatches it to an appropriate method to handle the request. The developer of the servlet must provide an implementation for these methods. If a request for a method that is not implemented by the servlet is made, the method of the parent class is called, typically resulting in an error being returned to the requester.
4. Finally, the container calls the destroy() method which takes the servlet out of service. The destroy() method like init() is called only once in the lifecycle of a Servlet.
1. The Servlet class is loaded by the container during start-up.
2. The container calls the init() method. This method initializes the servlet and must be called before the servlet can service any requests. In the entire life of a servlet, the init() method is called only once.
3. After initialization, the servlet can service client-requests. Each request is serviced in its own separate thread. The container calls the service() method of the servlet for every request. The service() method determines the kind of request being made and dispatches it to an appropriate method to handle the request. The developer of the servlet must provide an implementation for these methods. If a request for a method that is not implemented by the servlet is made, the method of the parent class is called, typically resulting in an error being returned to the requester.
4. Finally, the container calls the destroy() method which takes the servlet out of service. The destroy() method like init() is called only once in the lifecycle of a Servlet.
What Is JAVA Servlet
The Java Servlet API allows a software developer to add dynamic content to a Web server using the Java platform. The generated content is commonly HTML, but may be other data such as XML. Servlets are the Java counterpart to non-Java dynamic Web content technologies such as PHP, CGI and ASP.NET. Servlets can maintain state across many server transactions by using HTTP cookies, session variables or URL rewriting.
The Servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a Web container and a servlet. A Web container is essentially the component of a Web server that interacts with the servlets. The Web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.
A Servlet is an object that receives a request and generates a response based on that request. The basic servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet's configuration parameters and execution environment. The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet elements, including session management objects that track multiple requests and responses between the Web server and a client. Servlets may be packaged in a WAR file as a Web application.
Servlets can be generated automatically by JavaServer Pages (JSP), or alternately by template engines such as WebMacro. Often servlets are used in conjunction with JSPs in a pattern called "Model 2", which is a flavor of the model-view-controller pattern.
The Servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a Web container and a servlet. A Web container is essentially the component of a Web server that interacts with the servlets. The Web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights.
A Servlet is an object that receives a request and generates a response based on that request. The basic servlet package defines Java objects to represent servlet requests and responses, as well as objects to reflect the servlet's configuration parameters and execution environment. The package javax.servlet.http defines HTTP-specific subclasses of the generic servlet elements, including session management objects that track multiple requests and responses between the Web server and a client. Servlets may be packaged in a WAR file as a Web application.
Servlets can be generated automatically by JavaServer Pages (JSP), or alternately by template engines such as WebMacro. Often servlets are used in conjunction with JSPs in a pattern called "Model 2", which is a flavor of the model-view-controller pattern.
Sunday, May 11, 2008
Subscribe to:
Posts (Atom)
