Tomcat comprises 2 components:
- Catalina is the servlet container
- Jasper parses and translates JSP to Java servlet and then compile into Java class to be managed in Catalina
Deployment descriptor tells the container details about the servlet. It also provide function such as hiding the internal directory structure by specifying an alternate mapping. The mapping also enable the change of the internal directory without affecting the external access path.
Sunday, November 9, 2008
HTTP Post
It is an erroneous view by many that POST is a more sophisticated form of GET. HTTP standard views POST as a way to request creating an entity in the server. When POST is used, the server can respond in 2 ways:
HTTP 200 or 204 = respond with an acknowledgement and provide no other data
HTTP 201 = indicate the entity has been created and provide more information about the creation
The latter case makes POST appear like a GET.
Static or dynamic GET responses can be cached with uses of HTTP control header such as If-Modified. HTTP 1.1 uses either date or tag (Etag) to validate content from cache. POST is considered as a mutable operation on the server. HTTP methods PUT, DELETE and POST must cause a cache to invalidate its entry. Thus POST is less efficient comparing to GET.
HTTP 200 or 204 = respond with an acknowledgement and provide no other data
HTTP 201 = indicate the entity has been created and provide more information about the creation
The latter case makes POST appear like a GET.
Static or dynamic GET responses can be cached with uses of HTTP control header such as If-Modified. HTTP 1.1 uses either date or tag (Etag) to validate content from cache. POST is considered as a mutable operation on the server. HTTP methods PUT, DELETE and POST must cause a cache to invalidate its entry. Thus POST is less efficient comparing to GET.
J2EE
The J2EE solution for serving application logic is Enterprise JavaBeans (EJBs). EJBs can be contacted directly by servlets, by applet containers or by JMS. In contrast, servlets are primarily meant for HTML-based, thin client session management and for delivering request and response to web user. By offloading the session and interaction to servlet, EJB can focuses on business logic.
EJB has built-in support for many low level technologies to enhance the scalability of server side logic. Comparing to client side logic (fat client), scalability is a challenge for server-side logic. The technologies include object persistence, transaction management and location transparency.
Under the J2EE model, EJBs are distributed objects managed by containers. The container provides surrogates (EJBObject) that interact with individual bean instances, on behalf of the client. The containers manage the lifecycle of its bean instances (creation and destruction). A client communicates with an EJBObject. The EJBObject acts as a middleman in the communication between client and bean. Its assignment to a bean instance is coordinated by the container. Client interacts with EJBs consists of the following steps:
1.A handle to an EJBObject is acquired by client.
2.Business methods of that object are called by client as needed.
3.After use, the client relinquishes the handle to the EJBObject.
The home interface is used for step 1 and 3. A local or remote interface for step 2.
The home interface provides factory-like services to create, destruct and find the EJB requested. The remote or local interfaces provide a clean API to application logics (business methods) encapsulated by the bean. The local interface is meant to be accessed by clients located on the same host as the bean.
Bean provides call-back method for the container to manage its lifecycle:
Creation: When the client demands but no available instance exists, the container must instantiate a new instance.
Destruction: Bean instances can be periodically garbage-collected.
Activation: A lite form of creation. Bean instances are pooled for performance reason. Container draw from the pool to fulfil a request.
Passivation: A lite form of destruction. A bean instance is returned to the pool.
There are 3 basic types of EJB:
Session beans are associated with specific business transaction, particularly one requested during an interactive session.
Message-driven beans are also associated with specific business action, particularly one that is necessary for application integration or batch processing.
Entity beans are associated with an application object that requires persistent storage.
Session beans are either stateful or stateless. Stateful session bean maintain state during communication with a client. They retain the values of their instance variables between client requests. It is important for the client to interact with the same bean. Theoretically, there should be as many stateful session beans as there are concurrent sessions. According to J2EE spec, stateful session beans may be periodically written to persistent storage.
Stateless session beans do not maintain state between requests and therefore can be used to process requests from any client. They are more scalable. However, session bean often requires state management. The state must be stored somewhere: cookies, URL rewrite, in server-side memory or in database.
Entity beans correspond to application objects that are meant to be persistent – contain potentially valuable information across sessions. It may be useful to think of entity bean as tables or relations in a relational database. They contains attributes, foreigh and primary keys to enforce entity integrity. Entity beans can be shared by multiple clients. Entity bean can relate to each other.
Entity bean's persustence can be either container managed or bean managed. BMP is there because J2EE implementation cannot know everything. The main advantages to CMP are simplicity and portability. You do not need to code SQL. You just need to provide a few methods that meet the requirements of your bean contract and specify some key information in the deployment descriptor. J2EE does the rest. As a result, your beans consist of much less Java code.
CMP method and mechanism for persistence vary between vendors. This means that CMP could be implemented by writing serializable Java object to the filesystem or by tight integration with a high performance database.
Since entity beans have relationships with other entity beans, there is a considerable likelihood that they'll be chatty in nature. Just as navigating a relational data model can result in many queries to the database, navigating through entity EJB objects can result in substantial cross-object communication – marshalling and network communication.
EJB 2.0 addresses this by offering a local model. For entity bean that are only called by other entity bean but not directly from client, maintaining a remote interface is a waste. EJB 2.0 develops the bean with a local interface and making it a local object.
The advantages are (1) more efficient argument marshalling – pass by reference rather than by value, (2) more flexibility in terms of security enforcement.
Another CMP feature in EJB 2.0 is container-managed relationships, equivalent to RI in database. Finally, CMP includes dependent objects, which can be thought of as extensions to entity bean. Dependent objects allow complex CMP fields to be represented in a separate class. This is a way of breaking up a more complex object into distinct parts.
BMP results in more time-consuming and complex development responsibilities. It also implies maintenance overhead for code and changes in data model. For performance, BMP may be more desirable but must be done right.
Session bean is unique on the method of invocation. Clients do not interact by calling a remote Java method. Instead, clients send messages via JMS and result in execution of an onMessage() bean function.
EJB has built-in support for many low level technologies to enhance the scalability of server side logic. Comparing to client side logic (fat client), scalability is a challenge for server-side logic. The technologies include object persistence, transaction management and location transparency.
Under the J2EE model, EJBs are distributed objects managed by containers. The container provides surrogates (EJBObject) that interact with individual bean instances, on behalf of the client. The containers manage the lifecycle of its bean instances (creation and destruction). A client communicates with an EJBObject. The EJBObject acts as a middleman in the communication between client and bean. Its assignment to a bean instance is coordinated by the container. Client interacts with EJBs consists of the following steps:
1.A handle to an EJBObject is acquired by client.
2.Business methods of that object are called by client as needed.
3.After use, the client relinquishes the handle to the EJBObject.
The home interface is used for step 1 and 3. A local or remote interface for step 2.
The home interface provides factory-like services to create, destruct and find the EJB requested. The remote or local interfaces provide a clean API to application logics (business methods) encapsulated by the bean. The local interface is meant to be accessed by clients located on the same host as the bean.
Bean provides call-back method for the container to manage its lifecycle:
Creation: When the client demands but no available instance exists, the container must instantiate a new instance.
Destruction: Bean instances can be periodically garbage-collected.
Activation: A lite form of creation. Bean instances are pooled for performance reason. Container draw from the pool to fulfil a request.
Passivation: A lite form of destruction. A bean instance is returned to the pool.
There are 3 basic types of EJB:
Session beans are associated with specific business transaction, particularly one requested during an interactive session.
Message-driven beans are also associated with specific business action, particularly one that is necessary for application integration or batch processing.
Entity beans are associated with an application object that requires persistent storage.
Session beans are either stateful or stateless. Stateful session bean maintain state during communication with a client. They retain the values of their instance variables between client requests. It is important for the client to interact with the same bean. Theoretically, there should be as many stateful session beans as there are concurrent sessions. According to J2EE spec, stateful session beans may be periodically written to persistent storage.
Stateless session beans do not maintain state between requests and therefore can be used to process requests from any client. They are more scalable. However, session bean often requires state management. The state must be stored somewhere: cookies, URL rewrite, in server-side memory or in database.
Entity beans correspond to application objects that are meant to be persistent – contain potentially valuable information across sessions. It may be useful to think of entity bean as tables or relations in a relational database. They contains attributes, foreigh and primary keys to enforce entity integrity. Entity beans can be shared by multiple clients. Entity bean can relate to each other.
Entity bean's persustence can be either container managed or bean managed. BMP is there because J2EE implementation cannot know everything. The main advantages to CMP are simplicity and portability. You do not need to code SQL. You just need to provide a few methods that meet the requirements of your bean contract and specify some key information in the deployment descriptor. J2EE does the rest. As a result, your beans consist of much less Java code.
CMP method and mechanism for persistence vary between vendors. This means that CMP could be implemented by writing serializable Java object to the filesystem or by tight integration with a high performance database.
Since entity beans have relationships with other entity beans, there is a considerable likelihood that they'll be chatty in nature. Just as navigating a relational data model can result in many queries to the database, navigating through entity EJB objects can result in substantial cross-object communication – marshalling and network communication.
EJB 2.0 addresses this by offering a local model. For entity bean that are only called by other entity bean but not directly from client, maintaining a remote interface is a waste. EJB 2.0 develops the bean with a local interface and making it a local object.
The advantages are (1) more efficient argument marshalling – pass by reference rather than by value, (2) more flexibility in terms of security enforcement.
Another CMP feature in EJB 2.0 is container-managed relationships, equivalent to RI in database. Finally, CMP includes dependent objects, which can be thought of as extensions to entity bean. Dependent objects allow complex CMP fields to be represented in a separate class. This is a way of breaking up a more complex object into distinct parts.
BMP results in more time-consuming and complex development responsibilities. It also implies maintenance overhead for code and changes in data model. For performance, BMP may be more desirable but must be done right.
Session bean is unique on the method of invocation. Clients do not interact by calling a remote Java method. Instead, clients send messages via JMS and result in execution of an onMessage() bean function.
Interactive web page experience
The advantage of browser based client is the ease of deployment. However user is always held back by the synchronous nature of the request-response underpinnings of the Internet – the latency of complete page refresh.
Microsoft has introduced the concept of remote scripting (MSRS) to overcome this limitation. It allow developer to interact with the server asynchronously. For example, user can select the drop down list and causing a script to run at the server to download the value for the drop down list, without a complete page refresh. MSRS works with Microsoft technology only and requires Java.
Brent Ashley developed JSRS (JavaScript Remote Scripting) using client-side JavaScript library and DHTML to make asynchronous call to server. Other people uses IFRAME to reload only part of the page or make hidden call to the server.
AJAX is another solution. It is not new. It is the “newest” technology related to XMLHttpRequest object (XHR) which has been around since IE5 (1999) as an ActiveX control. XHR since then has also implemented in other browser such as Mozilla and Safari. It is even covered in a W3C standard: DOM Level 3 Load and Save Specification. AJAX is a client-side approach and can interact with J2EE, .Net, PHP, Ruby and CGI scripts. In other words, it is server-agnostic.
Load and Save is the culmination of an effort that began in 1997 as a way to solve the incompatibilities in the browsers. DOM Level 1 was finished in 1998 giving HTML 4.0 and XML 1.0. DOM Level 2 completed in 200 giving CSS. Load and Save gives Web developer a common, platform-independent API to access and modify the DOM.
DOM is based on a concept from OMG. DOM defines the data and structure on a page. DOM give you a standard way to interact with your documents. By modifying the structure of a web page, you dynamically change the display, resulted in giving a rich client interactive environment to the user. For example, when the user client on the search button, your page makes an aynchronous call via XHR to do the search. After the server returns the search result, you use DOM call to modify the web page to display the search result (for example, in the form of a table). The broswer adjust the display and thus give a interactive sensation to the user.
Microsoft has introduced the concept of remote scripting (MSRS) to overcome this limitation. It allow developer to interact with the server asynchronously. For example, user can select the drop down list and causing a script to run at the server to download the value for the drop down list, without a complete page refresh. MSRS works with Microsoft technology only and requires Java.
Brent Ashley developed JSRS (JavaScript Remote Scripting) using client-side JavaScript library and DHTML to make asynchronous call to server. Other people uses IFRAME to reload only part of the page or make hidden call to the server.
AJAX is another solution. It is not new. It is the “newest” technology related to XMLHttpRequest object (XHR) which has been around since IE5 (1999) as an ActiveX control. XHR since then has also implemented in other browser such as Mozilla and Safari. It is even covered in a W3C standard: DOM Level 3 Load and Save Specification. AJAX is a client-side approach and can interact with J2EE, .Net, PHP, Ruby and CGI scripts. In other words, it is server-agnostic.
Load and Save is the culmination of an effort that began in 1997 as a way to solve the incompatibilities in the browsers. DOM Level 1 was finished in 1998 giving HTML 4.0 and XML 1.0. DOM Level 2 completed in 200 giving CSS. Load and Save gives Web developer a common, platform-independent API to access and modify the DOM.
DOM is based on a concept from OMG. DOM defines the data and structure on a page. DOM give you a standard way to interact with your documents. By modifying the structure of a web page, you dynamically change the display, resulted in giving a rich client interactive environment to the user. For example, when the user client on the search button, your page makes an aynchronous call via XHR to do the search. After the server returns the search result, you use DOM call to modify the web page to display the search result (for example, in the form of a table). The broswer adjust the display and thus give a interactive sensation to the user.
Saturday, November 1, 2008
What is Marshalling
In RPC, an IDL is similar to a header file in C. IDL generates client stub and server skeleton, a piece of C code compiled and linked edit into the host programs. The stub converts paramters into a string of bits and sends message over the network. The skeleton does the reverse. The process of converting parameters to message is called marshalling. The advantage of marshalling is that it handles differing data format between the client and the server (e.g. 32-bit on client and 64-bit on server). Serialization is to take an object and convert it to a message to be stored on disk or sent over the network.
Subscribe to:
Posts (Atom)