X-S Framework Leveraging XML on Servlet Technology

Transcription

1 X-S Framework Leveraging XML on Servlet Technology Rajesh Kumar R Abstract This paper talks about a XML based web application framework that is based on Java Servlet Technology. This framework leverages the XML technology to create a high performance presentation engine for the web-based applications, that helps in overcome the limitations of the widely used JSP (Java Server Pages) and ASP (Microsoft Active Server Pages) by giving a means to develop the application in multiple layers. The framework provides many common services and a centralized component based approach for web application development with which only the application specific code need to be written using the services API provided by the framework and the other infrastructure services are taken care by the framework. With this approach the application is developed with least dependency across various layers and the impact to the application due to enhancement of services, changes in functionality, etc is highly shielded. This framework can be deployed in to any servlet engine or any J2EE platform. Index Terms Component Based Architecture, J2EE, Servlet, XML I. INTRODUCTION IN present days web applications are becoming more and more critical for enterprise solutions and they are getting more complex with requirements such as multi-channel application delivery, multi-lingual presentation, personalized content, security, access control, etc. The framework is aimed at providing infrastructure that is required to develop complex web applications faster and easier, overcoming the limitations present with the existing approaches. The framework provides a multi layered approach for developing the presentation tier of a web application, in addition to providing the infrastructure services such as session management, access management for application security, caching, etc. with a light weight component model for scalability and performance. This provides an environment to develop the web application where only the application specific code is developed while the common services are taken care by the framework and it provides a means to develop the presentation tier in multiple layers which make the application faster to develop, avoids interdependencies with the different layers and makes it more adaptable for changes that are inevitable in software projects. It is also aimed to help manage a web application development project better, as this enforces a structured approach to the application development. XML transformation technology is used for producing the presentation output that helps in producing a highly flexible and performing presentation engine and the servlet infrastructure is used for implementing the framework services. This framework is developed in such as way that it can be deployed on any servlet engine and based on open source XML parsers and XSLT processors. II. EXISTING METHODOLOGY FOR WEB APPLICATION DEVELOPMENT AND ITS LIMITATIONS JSP (Java Server Pages) or ASP (Active Server Pages) technologies are used for present days web application development as they provide an easy mechanism for adding dynamic content to the static HTML content. In this approach application is developed by plugging in code in the static content that are to be generated in the beginning of the project. While executing an e-commerce project initially the basic structure of the page layout will be developed, which serves as a prototype for the application, this is often called as wireframes. Normally there will be a separate team that would be working on the final look-and-feel of the application where the styles, colors and finer presentation details for representing the structures in the wire-frames will be decided. Once the final pages are ready with the look-and-feel then it is delivered to the application development team for plugging in the code for introducing the dynamic behaviors. This work was done at MindTree Consulting, an E-Business and Technology consulting organization based in Bangalore, India. This work was created as an initiative to create frameworks that will help deliver robust E- commerce solutions with large complexities in a short duration of time. This framework has been deployed for multiple projects and has been proved to be large success. Rajesh Kumar R is with MindTree Consulting, No. 42, 27 th Cross, 2 nd Stage Banashankari, Bangalore, India Pin: (Telephone: , Fax: , rajeshkr@mindtree.com). Topic area: E-commerce ISBN: Fig. 1. Simplified representation of JSP/ ASP based web application, where the Data, Structure and Visual representation is a single layer In this approach the data access code responsible for getting

2 the data for the presentation and the presentation layer itself consisting of the layout of the data and the final presentation formatting with the correct colors, fonts, etc form a single physical entity as shown in Fig 1. Limitation associated with this approach In many cases the wire frame will be available in the beginning of the project, but the final look-and-feel may not be decided, in that case, it may not possible to start the presentation tier development as the HTML files may not be available to plug-in the dynamic logic or it may involve large amount of code changes to implement the look and feel at a later point of time. Some structured approach could be followed to change the look and feel at a later point so that the impact is less, but this will involve the effort of a design in place that would enable to do this, which if not done correctly will end up in lot of re-work if the user interface (UI) changes at a later point of time. Also when the UI changes it will not be a zero impact, meaning some amount of data access code will need to be re-touched, at least for the correct positioning in the pages In certain cases the structure of the web site may change while the project is being executed, but keeping the look-and-feel consistent. This would most likely involve lot of re-work if the pages are not structured correctly with page includes, where the individual components of a page is constructed individually and assembled, so that the common components that appear on all pages can be re-used. This again would involve considerable effort in designing the individual page components and technically there are overheads in page-includes, which would impact the performance. It may not always happen that the business tier or the middleware design is available for the presentation tier to design for the data objects to be used for presenting the data. In most cased this will happen parallel and may be done by different teams, there is possibility of changes in one layer impacting the other. There is no general specification for presentation layer development such as EJB specifications available for middleware, hence it is totally up to the individual project teams to design, which would involve considerable effort and may not result in a consistent design. III. MULTI-LAYERED PRESENTATION APPROACH Any presentation consists of three components namely data, structure & visual that constitute the final presentation entity, as illustrated in Fig 2. For a presentation for an E-commerce application the data will be the dynamic content that is typically fetched from middleware or a database, which would involve programming logic. The layout of the data and applying a final presentation style are purely presentation related details that should be isolated from the data access logic. Fig. 2. A web presentation showing the list of clients of an organization, illustrated with the different layers. Data Layer: In the above example the data contained in the presentation entity are the list of clients. Basically the data layer consists of the data that is presented through the web presentation. It should be noted that this data is purely domain or business specific and does not contain any information or details about how it is presented. Structural Layer: The structural layer consists of the structure of the data presentation. Like in the above example, the structural information will be that the data should be presented as a bulleted list below the page header. The structural layer does not have any information about how the final presentation is done; it only states the structure of the presentation. For the above example, the structural layer will not contain any information about the final representation of the bulleted list, like the font, type of bullet, the page background, etc, it only states the structure of the presentation. Visual Layer: The rules for defining how the structure should look in the final representation constitute the visual representation layer. Like in the above example: The final representation is in HTML Page background is in yellow The top menu consists of the title and the menu with blue background Logo appears on the right The bulleted list s font is Times New Roman, etc. The visual representation layer basically consists of the rules for translating the structures described in the structural layer in to final representation IV. X-S FRAMEWORK OVERVIEW The XML technology is leveraged over the servlet

3 infrastructure to develop a framework that enables to develop a web application in three different layers as mentioned above namely Data, Structure & the Visual layers. As a result of this the limitations associated with the typical development approach using JSP or ASP are overcome and because of the layering it becomes easier to manage issues related to multichannel, multi-lingual presentations, character encoding, etc as this will mean changes only to the visual layer. The XSL Transformation (XSLT) is used for generating various layers in the presentation. Since the different layers are developed and deployed as separate physical entities that are not closely coupled, each layer can be modified independently with out impacting the other for implementing any changes. Also this approach defines a clear agreement between each layer about the way they are integrated, basically XML documents are passed across, hence it provides a means to develop the different layers independently once the XML interactions are decided based on the presentation and this provides a means to control and manage the application development better. Standard authentication & authorization checks DB connection management V. FRAMEWORK DETAILS The framework is based on a servlet that receives the HTTP requests and delegates the action based on the request to the corresponding request specific components that is designed to handle it. It goes through some standard operations based on the request before processing it. Then the final response for the request will be constructed and delivered by the request specific components. The servlet consists of the wiring code for connecting the various components that constitutes the framework and establishes the communication flow between them. Before processing a request the framework will do the basic checks such as session checks to verify if the request needs a login, access checks to confirm that the logged in user has the access to the requested module, etc, based on the request. The checks that is required to be carried out for a request is configurable by setting attributes in the request specific component. Based on the request received the framework will delegate the operation of getting the necessary data for the request to the appropriate request specific component. The request specific component will construct the data XML and return it to the framework. Then the framework will transform the XML using a XSL designed for that request, and apply the final presentation details over it and the final response is constructed. Fig. 3. The basic layers in X-S Framework based development The Data access component is the one responsible for obtaining the data required for presentation from various sources and once the data it obtained it is represented as XML and delivered to the framework for transformations that would result in the final presentation as illustrated in Fig. 3. While developing applications using frameworks the amount of code written to create an application also reduces very much as only the application specific logic is coded, thereby reducing the chances of errors and eventually the applications resulting will be of better quality. The framework-based approach as reduced the impact to the application code as anything other than the application specific logic are managed centrally through the framework components. Following are some of the standard operations managed by the framework: Access of session data Access management authorization Translation for multi-lingual implementation Multi-channel delivery Processor instantiation management using object pooling Caching for performance Application Flow management The building blocks of the framework could be classified mainly into two categories namely A. Framework Components B. Application components A. Framework Components The framework components are the general modules that are responsible for the basic operation of the framework. These are application independent. Base Framework: This is basically the servlet that receives the requests and delivers the response. This servlet wires all the other components of the framework and delegates the action that needs to be taken to the various modules. The framework receives the structural XML from the application specific components and transforms it to the final response with XSL transformation. Session Manager: The session management mechanism is encapsulated in this module and the functionalities of this module are exposed by means of an interface. The rest of the framework components and the application components will access the session manager using the interface and the implementation is independent of its usage. Hence changing the session management mechanism will not affect the application and at any stage of the project it can be decided to enhance, optimize or modify the session management mechanism. Access Manager: The functionality of the access manager is to check if the logged in user has got the

4 access for the request submitted. The framework carries out this check before processing the request and it will do this check only if the request is marked as access check required. The access manager s implementation is similar to that of the session manager where the implementation is made independent of the usage using an interface. Language Manager: The language manager is used for translating the data that needs to be presented. The development will be done based on one language and all the data will be presented finally after passing it through the language manager. Based on the dictionary attached, the language manager will carry out the translations. The language settings are externalized and controlled by a conf file hence it is easily configurable. Visual Layer Cache: This component is responsible for caching all the requested style sheets that are accessed to avoid disk access every time for delivering the responses, resulting in better performance. The configuration can be set to enable or disable the visual layer cache. Response Cache: Some of the responses may not contain a very dynamic content, for such requests the resulting response itself could be cached to avoid the XSL processing. This module will have the facility for setting the refresh time for the cache through which the cache will be refreshed periodically, so that any updates if it is there can reflect automatically. The enabling or disabling of the response cache is done at the request level, so it gives the flexibility of choosing this caching facility for only those requests, which needs it. Structural & Visual style XSL: The structural style XSL contain the transformation details for the data XML that is constructed from the middleware or business layer calls. This will transform the data XML into an intermediate structural XML that will contain the presentation details for the data, which is independent of the presentation channel or language. The visual XSL contains the transformation rules for converting the structural XML that results from the transformation of data XML by the structural style XSL. The visual XSL transformation will result in the channel specific final response that will be delivered as response through the delivery channels. Multi-channel/ Multi-lingual style chooser: This module chooses the visual style XSL for the final transformation based on the channel and the language of presentation. This module fetches details for making the choice of the right XSL from the configuration XML. Middleware connector: All the middleware connection related activities will happen in this module and the entire application will connect to the middleware through this module. Hence if there is any change in the way the connection happen in the middleware or any change of middleware itself, only this module will undergo changes without affecting the rest of the system. Request Handler: When the request arrives to the servlet this module is the one that handles the request. It instantiate the appropriate request processor and returns it to the framework and the framework will further operate on the request processor to get the final response. The application specific request handlers will implement the required handling code. The request handler is a generalized form of the application specific request handler. Request Processor: This module is responsible for carrying out the necessary processing for the request received. The framework will operate on the request processor to construct the final response. The request specific processors will have to be implemented to handle each request. The request processor is a generalized form of the application specific request processor. Configuration XML: Though it forms an integral part of the framework, it qualifies as a separate component of the framework that controls many of the runtime behaviors of the application. Some of the runtime setting that are controlled by this are: i. The middleware to lookup. It enables hot shifting of middleware servers while the application is running a handy feature during the development phase. ii. Enabling and disabling of the Response cache, Visual cache, etc. iii. The module specific visual style decision. iv. Browser specific shifting of visual style. v. Database connections. vi. Static content delivery vii. Mail configuration viii. Cache configuration ix. Object Pool configuration B. Application Components The application components are developed for a specific application, which gets plugged into the framework. Application specific request handler: This component is developed for each major module in an application. The request handler is passed on with the received request and it contains the code for handling all the requests in the application module. Its overall responsibility is just to return the request processor based on the request received. Request specific processor: For each request or a logical group of requests the request specific processor are to be developed. This will contain the code for getting the necessary data for the request by contacting the middleware and constructing the data XML. This module is also responsible for setting all the request specific parameters such as the structural style XSL, if session check is required, if access check is required, etc based on which the framework will decide on the operations that are to be carried out for the request. On receiving the data XML from the request specific processors the framework will carry out the XSL transformations on the XML and generates the final response.

5 VI. FRAMEWORK PROCESS FLOW Fig. 4. The process flow diagram of the framework Fig.4 Represents the simplified process flow in the framework that shows the normal flow along with the flow in case of exceptions. The process description: 1. The requests received by the framework will first be handed over to the request handler, which will instantiate the request processor corresponding to the request received. 2. The instantiated request processor will be handed over to the framework. The request processor will have details about the basic checks that are to be carried out for the request. 3. Based on the information retrieved from the request processor, the frame work will carry out the checks such as session checks & access checks, explained below: a. Session Check: If the request mandates a login, the framework will check the existence of a session and the login requirements, if it is detected that the login has not happened or the session does not exist it will hand over the control to the exception processor by passing appropriate messages. b. Access Check: If the person logged in does not have access to a page and he has submitted a request for that page, this access check will detect and it will pass the control to the exception processor. 4. Once the request passes through all the checks and if all the checks succeed, then the request processor will be requested to process the request. The processing may include contacting the middleware and getting the required data for the request. Once the required data is obtained, a data XML is constructed and passed on to the page content generator. 5. The page content generator will transform the data XML to a page content XML that will contain the structural details of the presentation details, such as the data is represented as title of a page, the data represented as table content, the entry fields present in page, the dropdowns in a page, etc. But the final representation code such as the HTML or WML equivalent of the page contents are not defined in the page content XML. Hence the page content XML is channel independent. 6. The page content XML is then passed on to the response processor, which chooses the final representation of the page content based on the channel and the language of presentation. The response processor will transform the page content XML into HTML or WML by choosing the appropriate XSL based on the configuration, channel of delivery, language, application, etc and the final response is delivered. 7. In case of any exception or failure of any checks, the exception processor will decide the response based on the type of exception and generate a response i.e. it will generate a page content XML based on the message to be shown and hand it over to the Response Processor which will result in generating the final response that would get delivered. VII. FEATURES AND ADVANTAGES Multi layered development: The standard application is divided as data-structure-visual layers. Each layer is independent of the other hence can be developed without dependencies and can undergo changes with minimal impact. Re-use of data layer: Since the data layer is independent of the visual and structural layers, the same presentation data could be shared for multiple visual representations of the data. For example, a data logic developed for a specific look and feel could be re-used with a different visual layer for presenting the same data with a different look and feel or even for a different channel of delivery such as WAP or CHTML Component based: Since the framework is component based, each presentation unit is developed as components responsible for a specific presentation task and plugged into the framework. Hence adding or removing the functionality will be a very standard operation and will not technically impact the rest of the system. Also changing a specific component will

6 mean only operating on that specific unit without disturbing the rest of the system. Descriptor based configuration: Many of the system s runtime behavior is based on a XML descriptor. Hence the runtime behaviors can be controlled by changing the descriptor without any code change, re-compilation or even re-start of the application in most cases. Rapid development: Only application specific components need to be developed. Since the application is developed in multiple layers the development of each layer can happen in parallel. Object Pooling: The page processing components for the application are pooled by framework, thereby reducing the object instantiation overhead during runtime, contributing to the runtime performance of the application. Independent implementation of look & feel changes: Implementing the look and feel changes is a part of visual layer, so it can be implemented by changing only the XSL for the visual representation. This means, once the basic structure of the presentation layer is decided the development of it can go ahead without waiting for the final look and feel. The final look and feel can be implemented any time by modifying the visual layer, without changing the data-logic. Modular: The framework is constructed with many independent modules wired up with one another. This provides more possibilities of performance tuning as each of the modules can be altered independently without affecting the other. For example, if at a later stage it is required to change the session management mechanism using a different technology, only the session manager implementation will change and the rest of the framework or the application is not required to be altered. Auto authentication and authorization check: There is no need to implement the authentication and authorization checks in the application code as it is taken care by the framework. This would mean lot of work being saved from the development perspective and this also gives a means of changing the authentication and authorization mechanism totally, if need arises with zero impact to the application code. Caching: The dynamic web page caching comes as a standard feature with the framework. The cache is highly configurable with possibilities of caching the pages both in memory as well as disk, there by increasing the performance of the overall application. A short Feature comparison with JSP technology XS-Framework High performance is achieved due the use of very fast XML parsers and XSL Transformers, Resource pooling to neutralize instantiation time. Control over proliferation of specific resources to ensure optimal use of server resources. Reusable components available for Multi-lingual capabilities, Database Connection Management, Mail utilities, etc. Highly configurable runtime behavior of the application, as it is based on the parameters defined in the configuration file. Clean and clear division of data, Organization of data for presentation and the visual experience. Performance is not a function of Page complexity, as it depends mainly on XSL transformations and the layout logic does not determine the page complexity Caching is a standard feature of the framework. Pages with dynamic content can be cached, depending on the frequency of change of content. ACKNOWLEDGMENT JSP Technology Performance is impeded due constant shift between access to the file system for static content and processing the dynamic content. Such fine tuned control is more difficult to implement. These components have to be designed and developed ground up. Configurable application behaviors are to be planned and built for each application Structure and Visual experience are highly coupled. Care need to be taken to separate data access from the presentation Performance is a function of page complexity hence response time for complex pages will more. To implement caching an external software will be required Thanks to all the team members who participated in conceptualizing and developing this framework. Thanks to the management of MindTree Consulting for providing the necessary support and encouragement to bring this concept in to a reality. REFERENCES [1] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, "Design Patterns, Elements of Reusable Object-Oriented Software," [2] Deepak Alur, John Crupi, Dan Malks Core J2EE Patterns, Best practices and Design statergies [3] Brett Mc Laughlin Java & XML 2 nd Edition