Pluggable Services for Tailorable E-content Delivery

Pluggable Services for Tailorable E-Content Delivery Christos KK Loverdos, Kostas Saidis, Anya Sotiropoulou and Dimitrios Theotokis Department of Informatics and Telecommunications University of Athens Panepistimiopolis, 157 84 Ilissia, Athens Greece e-mails: {loverdos,saiko,anya,dtheo}@mm.di.uoa.gr

Abstract. Delivering e-content as a service to end users involves addressing various cross-cutting aspects, including the heterogeneity of source and data, user needs, business rules as well as the evolution of the content itself. Catering for these aspects when modeling information systems calls for an architecture that accommodates evolution through separation of concerns and tailorability, and provides uniform access to the underlying content. Based on the notions of services and servicing rules, modules, providers, and module composition we show that effective modelling of service-based e-content delivery system is accomplished.

1

Introduction

This work deals with the design and the development of a framework for the delivery of multi-source heterogeneous e-content. From a business perspective, it is necessary to facilitate the incorporation, modification and incremental addition of business logic in a transparent, consistent, and flexible manner. In other words, the system’s tailorability is of upmost importance, as it enables its evolution according to emerging business needs. Consequently, the framework must be free of rigid design decisions, and as such abites to the principles of Deffered Design Decisions (DDD) [4]. From the end-user’s perspective, as well as that of developers, uniform access to the system’s data, whether internal or external, irrespective of their formats, structure and source, is also of great importance. Following this the infrastructure that generates the publishable form of the content from its raw data representation should be as transparent as possible and should not require any special programming skills. That is, an average knowledge of HTML should suffice for this purpose. To achieve all of the above, it is necessary to separate all such concerns and provide the appropriate infrastructure for their composition into something robust, meaningfull, and well-defined. The system’s adaptation is achieved along the following levels: (a) At the programmer level in order to ease the programming cost and minimize editive changes. In effect, the maximization of code

reusability (modules) and resource transparency (provision) is sought. (b) At the business-logic level to cope with ever changing business requirements (services). The remainder of this paper is organized as follows. Section 2 focuses on the key concepts of the architecture. In Section 3 the elements of the application framework are presented. Section 4 presents related work. Section 5 concludes the paper and presents future work directions.

2

Key Concepts

A Service is a process invoked by a user request, consisting of a set of actions that need to be taken in order to fulfill the request. Services implement business logic and are constructed by the composition of modules. A Module implements an action needed as part of a service. A Module is the fundamental building stone of the architecture and the framework. It describes first level atomic operations, thus wrapping programming logic into reusable, independent units. A module exhibits a well-defined behavior as specified by its input and respective output. Examples of modules include user authorization, user profiling, dynamic HTML creation, database querying etc. The Provision of any resources needed by modules and, consequently, services must be done in an as dynamic and uniform way as possible. Resource handling is, in our opinion, of fundamental value and as a result is treated as a key element in the work presented herein. What follows is a detailed description of the above. Modules, enable the separation of the servicing process into its operational components. This provides the flexibility to set up new services by composing modules and/or other services. Module composition reflects the adaptability of the approach with respect to the business requirements and usage patterns. Consider a web application where registered users access a specific service, namely dbSearch, and where session management is needed, so that the semantics of “controlled access” business rule are realised. Given the above requirements, we identify the actions, authentication, session management, and reply construction, represented by the modules Authenticator, SessionManager, and PageGenerator, respectively. Now, assume that the business policy regarding the dbSearch service changes to “free access”. Consequently, the use of the Authenticator and SessionManager becomes redundant. Later in this paper we describe a module composition mechanism based on a boolean expressions to model business logic. To support a unified way of acquiring and manipulating resources, we have based our work on the concept of provision. This is the heart of the proposed architecture, a general concept that can be specialized in more concrete cases, according to the needs of an application. For example, one may refer to the provision of: a set of tuples stored in an RDBMS, text stored in files, XML entities, in-memory objects, the result of a computation, etc. For identification purposes, resources within the system are supplied with unique identifiers. Grouping of conceptual related resources is achieved in terms

of realms. For example, all the modules in the system could belong to the same realm, called ModuleRealm. Realms may contain sub-realms, producing in this way a hierarchical model for resource naming. In other words, we define a scheme for supporting hierarchical namespaces. Each realm, is administered by an entity called Provider which “knows” how to handle and provide objects belonging to that realm. Thus, we can decouple “how to get” data from “where to use” them, allowing for their independent evolution. As long as we keep the same qualified name for a resource, it can be uniformely referenced throughout the system and the editive changes needed in source code are minimized.

3

Key Elements of the Application Framework

Fig. 1. Interface definitions of the framework.

Assuming that: (a) modules are composed according to an execution rule – the servicing or business rule – to form a service that fulfills user requests, and (b) provision enables the manipulation of resources as entities grouped into hierarchies we set up an application framework using Java, that can be used to build effective, tailorable, service-based web applications. What follows outlines the framework’s key elements: (a) The Provision Mechanism and its core components. (b) The Module Composition Mechanism – how modules are defined and composed, how they communicate and, finally, how they correspond to the execution of a service. (c) The protocol for the Instantiation and Initialization of

entities in the framework. (d) The manner through which the Provision Mechanism provides uniform access to data, independently of their source and nature. (e) The Dynamic Content Generation Mechanism. 3.1

Providers and Provider Manager – The Provision Mechanism

A provider is realized as an implementation of the Provider interface (Fig. 1.(a)). This interface defines the most general case of provision, leaving the real “meaningful” specifications to be set by the implementor. We shall see several implementations and specializations of this interface later, as we discuss the functionality of different entities of the framework. The usage pattern defined by this interface is rather simple: For a client to gain access to a resource it must query the resources’s Provider. In doing so it must provide information about the resource it requires, along with a search guideline, namely a hint, in order to specialise the provider’s response. Thus, it becomes evident that a Provider, although similar to the Factory [1] design pattern it extends it in terms of semantics incorporated in the notion of provision. Providers register their associated realm in an administration authority called ProviderManager (manager). A provider can also act as a manager for specific sub-realms, resulting in a flexible, recursive resource management schema. Any access to resources is done via the ProviderManager, using their qualified names. The ProviderManager delegates the provision request to the corresponding provider. For clarity, examples of resource qualifiers are given below: db.users.query.userInfo This describes an SQL query which retrieves user information from a database. The manner this specification is parsed and interpreted lies with the specification of the provider associated with the db realm. Once the db provider is registered with the top-level manager, any db prefixed request to the manager is delegated to the db provider. This resource is further explained in Section 3.4. service.request.parameters This identifier represents the parameters provided as part of the user’s HTTP request. A more detailed description is provided in Section 3.4. 3.2

The Module Composition Mechanism

The Module Composition Mechanism (MCM) is based on the the following assumptions: (a) Modules should be coded as separate entities that perform a single, well-defined task, in an atomic way, and (b) every module may succeed or fail under certain circumstances, so its execution should be treated as a boolean operation that returns TRUE in case of success and FALSE, otherwise. Furthermore, the MCM should meet the following requirements: (a) Services or modules may change due to business rule modification, and the composition mechanism must be able to easily adapt such changes, and (b) modules that co-operate in a service should be able to exchange information.

In this section we cover in detail the MCM in terms of: how the module composition is specified and executed,how modules communicate, and how all these result in the execution of a service. MCSL - The Module Composition Specification Language: For the proposed framework we employ a language of boolean expressions, namely MCSL. A module that appears in such an expression corresponds to a boolean variable, as mentioned before. Each service invocation results to the evaluation of such an expression. The boolean expressions supported are build in terms of the following operators, while the MCSL grammar is shown below. 1. Boolean NOT, denoted as ‘!’. 2. Boolean OR, denoted as ‘|’ and implemented with sequential semantics. This means that an OR expression should succeed as soon as possible — if it succeeds at all. 3. Boolean AND, denoted as ‘&’ and implemented with sequential semantics. This means that an AND expression should fail as soon as possible — if it fails at all. 4. Parentheses ‘(’ and ‘)’, to realise priorities.

Communicating Modules - The Service Runtime Information: Module communication is necessary in the context of the execution of a service. For this purpose, we have drawn on the notions behind workflow technology. A workflow, in the higher level of abstraction, consists of rules that govern its execution along with the specification of the data flow between its components. In a similar way, we use the MCSL to define the execution rules of a service and introduce the notion of the Service Runtime Information (SRI) to cover the needs of data communication between each execution step. The similarities between a service process and a workflow process are illustrated in Fig. 2 [3]. We refer to workflow from a rather abstract point of view and use its core semantics. We ommit semantics that are either inapplicable in our context or are unrelated to it such as worklists and BPR and Automation notions. The SRI Object encapsulates the data associated with a given instance of a service process, acting as the data communication channel between its modules. Every instance of a service is associated with its own SRI object, which is accessible by every module participating in the service execution. A module stores the data it generates in the SRI object. A subsequent module in the execution

Failure Authenticator

Success

SessionValidator

PageGenerator

SRI

Fig. 2. A Service process presented as a workflow. The black arrows define the execution order – the control flow – while the gray, dashed ones represent the data flow and highlight the data communication channel supplied by the SRI.

order requiring the data in question, simply posts a provision request to the SRI object to obtain a reference to them. The framework supports the aforementioned module’s interaction is a part of every service execution, but it does not supply a specification scheme for it. It is the implementor of the service and its modules that has the responsibility of the data flow specification. Module Composition Engine: A module is realized as an implementation of the Module interface presented in Fig. 1.(b). This interface defines the basic operation performed by every module, and ignores issues concerning the instantiation and/or initialization, which are discussed later. The Module Composition Engine (MCE) is the runtime environment for the execution of modules and services. Its purpose is to evaluate boolean expressions consisting of Modules that represent a service. The evaluation is accomplished as follows: 1. Parse the expression that corresponds to the requested service. 2. Build an equivalent internal representation of the expression which specifies the modules’ execution order. 3. Create a new (empty) SRI object. 4. Call the execute(SRI) method of the first module in the execution order and store its result (either true for success or false for failure). 5. Remove the module from the execution order. 6. If the expression can not be evaluated because there are modules remaining in the execution order, go to step 4. If its evaluation is possible, perform it by applying to the expression the results available so far and return its value. Boolean expressions, implementing business logic, define the execution order of the modules that participate in a service. The aim is the evaluation of such expressions to TRUE, indicating an overall successful execution. A Module Composition Example: Consider the dbSearch service example in Section 2. There exist a number of possible implementations of this service, depending either on the business rules or the corresponding modules

specifications. The ‘business logic’ of a web server uncoditionally serving content is implemented by the boolean expression: * = PageGenerator

where * refers to any page requested without employing authentication and session management. When the user must be authenticated prior to using the search page, a LoginPage should be presented and a new expression is constructed: LoginPage = PageGenerator SearchPage = Authenticator & PageGenerator

The user reaches the SearchPage only if correct username and password values are given in the LoginPage. This is reflected in the Authenticator module which returns true iff the user’s login and password are valid. If session management is needed, this is accommodated by the following definition: LoginPage = PageGenerator SearchPage = Authenticator & SessionCreator & PageGenerator * = SessionValidator & PageGenerator

All visitors should be able to access the LoginPage. If they login successfully they are provided with the SearchPage. The SessionCreator module, creates a new user session, storing in it information provided by the Authenticator. This information is available through the SRI object. Finally, all pages appearing after the SearchPage should be available only to already authenticated users. That is accomplished by the use of the SessionValidator, which succeeds iff a user session is present in the request. 3.3

Instantiation & Initialization Mechanism

The notion of the InstanceManager is introduced as a core component of the application framework. It operates on its lowest-level, and in fact is part of the framework’s kernel. In accordance with the terminology used so far, it stands for a Provider of instances. The InstanceManager provides the functionality of instance creation hiding the underlying details from its clients. It handles the instance realm and expects the names of the requested recourses to be the fully qualified Java class names of the associated objects. For example, a provision request instance.Authenticator refers to the the class name of the authentication module. Depending on their usage patterns objects may be multiply or singly instantiated. The latter are named Singletons and comply with the Singleton design pattern [1]. Such Singletons are realized in the framework as implementations of the Singleton interface shown in Fig. 1.(c). Under our approach initialisation and instantiation are treated as different tasks. For that purpose we introduce the Initialize interface shown in Fig. 1.(d). Using Java’s reflection capabilities, the InstanceManager can satisfy both instantiation and initialisation needs, by following the steps below: 1. It loads the class that corresponds to the name given,

2. If the class implements the Singleton interface: – Obtains a reference to the instance of that class by calling its getInstance() method. – If the class also implements the Initialize interface it checks if the object needs to be initialized. If so, by means of reflection it calls the instance’s init(Map) method which it supplies with a Map object that contains initialisation data. If not: – Assuming that the hint object in the provision request is an object array (Object[]), the constructor of the class whose arguments’ types match those of the elements of the Object[] is reflectively located. – Once found, the constructor is called and a reference to the newly created instance is obtained. 3. Returns the instance to the client. Providers handling external to the system resources are implemented in the framework as Singletons, such as the database data provider. On the other hand, Providers for resources specific to a service execution, such as request parameters, are created upon each service invocation and destroyed after its termination. This makes efficient use of memory. 3.4

Details of the Provision Mechanism – Uniform Access to Data

Data sources are objects that contain or/and generate data. Such data sources could be databases –XML objects, text or binary files, servers residing on the network etc. All these entities are ‘external’ to the application itself and it is a good practice to decouple the code that accesses them from the code that operates on the data they provide. The same should hold for information that exists “within” the application, such as request parameters session information. However, programmers hard code such accesses to internal resources, causing tight coupling of rather irrelevant to each other tasks and operations. Instead we use the provision mechanism, to uniformly access both “internal” and “external” data. We introduce an extension to the Provider interface, namely DataProvider, illustrated in Fig. 1.(e) that allows one to cycle through the underlying data in a simple and efficient way. Classes implementing this interface act as wrappers of the underlying data, hiding the implementation details of how these are accessed. Let an SQL query that retrieves user information depending on the username given be: SELECT USERID, UNAME, PASSD FROM USERS WHERE UNAME = ’{UNAME}’

The results of this query represent a resource, namely db.users.query.userInfo. The corresponding Provider of this resource “knows” how to utilise it, hiding from the developer its underlying implemention. The developer treats it as a resource that requires a UNAME as an argument, denoted in the SQL code by

{UNAME}, and returns (USERID, UNAME, PASSWD) tuples, wrapped by a DataProvider object. Assume that the Authenticator module in the dbSearch example, uses the db.users.query.userInfo resource in order to authenticate the user as shown in Fig. 3.(a). The Authenticator module simply requests the provision of named entities from the ProviderManager. The latter is accessed when client code requires to a resource and for that reason is implemented as a Singleton object globally available in the system. It delegates each request to the registered provider for the top-level realm specified in its subject. Other implementations could follow different delegation policies according to a more complex lookup.

Fig. 3. (a) Code snippet of the authentication module, highlighting the details of data provision, (b)A simple example of an extented HTML template.

The role of the hint object in the Provider interface specification (Fig. 1.(a)) is to enable the parameterisation of the provision process. These parameters are represented in the framework as containers of name/value pairs. The other provision example of Fig. 3.(a) refers to a resource named service. request.parameters.username. It corresponds to a parameter provided by the user, encapsulating the username input element of the HTML form. We use a Provider to handle the service realm and thus represent a service as seen from an HTTP server’s viewpoint, consisting of a request, a response and perhaps an associated session. Such providers are automatically created and assigned to every service process by the framework. The flexibility provided by this hierarchical naming scheme is highlighted by the following table, which outlines the results of provision depending on the resource wanted:

Name of resource: service.request Object returned: The javax.servlet.http.HttpServletRequest object itself Name of resource: service.request.parameters Object returned: A DataProvider wrapping all request parameters Name of resource: service.request.parameters.a-param Object returned: The value of the a-param request parameter Simple implementations of the Provider interface are used to wrap various types of data, even components of the system itself, thus, extending and specializing the notion of provision according to a system’s needs. 3.5

Dynamic Content Generation

Another goal in the design of the framework was to utilize a powerful yet easy to use mechanism for dynamic content generation. Familiar approaches to ours already exist and some of them are widely used, such as JSP [6], ASP [5] and PHP [7] just to mention a few. Although they provide great functionality and ease of of use, their main characteristic is that they are full fleged programming languages, requiring programming skills. On the contrary, we provide a simple extension to HTML, easily adopted by anyone with its basic knowledge. The idea is simple and is based on document templates that contain named placeholders of data to be generated on the fly – upon the document’s request. Our aim is to separate the details of ‘how to get’ the content and ‘how to render’ it, according to the specification of the Model-View-Controller [2] model. The template author, using a language he knows and understands well, is called only to name the data its document needs and specify the places they should appear, not to program the way they will be accessed. The provision mechanism enables us to treat the templates as simple provision specifications. The framework supplies a PageGenerator module responsible for the dynamic generation of content according to the following rules: (a) each URL a user requests should correspond to a template stored in the local filesystem, (b) such templates may contain sub-templates, ad infinitum, and (c) the creation of such templates involves specific XML tags. For that purpose, three XML elements are introduced which define the dynamic content generation process illustrated in Fugure 3.(b). These elements form the aforementioned extension to HTML, but, obviously, are not limited to it. The mechanism can also be used to generate XML, RTF, RDF and any other text-oriented content. In detail these elements are: DEFINE: This element appears at the top of the template and acts as a container of the other two elements (see Fig. 3.(b)), specifically, it declares the entities that will act as the placeholders in the template. All these entities are supplied with unique identifiers in the scope of the template declared. An occurrence of an element named as any of these identifiers elsewhere in the template, represents a placeholder for the corresponding entity. TEMPLATE: This element defines a sub-template in a document template. Its syntax is:



For example, in Fig. 3.(b), we declare a template named MENU in the body of the DEFINE element, which refers to the contents of the file common/main-menu. In the main body of the template, all occurences of the element will be replaced by the contents of the file it refers to. DATASET: This element specifies a resource to be used by the template in which it is declared and follows the syntax:

The DATASET element is also supplied with a unique identifier (the NAME attribute) and specifies a provision request, which will be executed dynamically by the PageGenerator module. Its WHAT and HINT attributes map directly to the parameters of the provide(what, hint) method defined in the Provider interface (see Fig. 1.(a)). The Map object used to encapsulate provision parameters is represented here as name = value pairs separated by commas. The code shown in Fig. 3.(b) creates a page that displays the results of a book search based on its author. This page supplies the user with a list of the book titles, that matched the given criteria along with a hyperlink to the ‘details page’ of each book. We declare a dataset named BOOK that refers to an SQL query which returns the title and ISBN of the books written by a given author. The template author needs not to be aware of the details of the query, he is not even expected to know SQL, Java or anything else but HTML, and the fact that the BOOK dataset accepts a parameter named AUTHOR. The content generation mechanism will locate the code enclosed in the , elements and perform the appropriate substitutions of the placeholders and with their corresponding values from the query’s results. That task will be repeated as many times as are the rows returned. The template author is responsible for the implementation of the template generation logic – the templates turn to web pages without the interference of the programmer. Note the use of the hint in the BOOK dataset. It defines a parameter named AUTHOR and dynamically sets it to the value of the author request parameter, reflecting the logic required for the generation of the page. The use of the PageGenerator module and the content generation mechanism it introduces results in self-contained templates, encapsulating both the rendering information and the content generation logic. The whole process is sped up by the support of sub-templates, which enable code reuse.

4

Related Work

The Turbine servlet-based framework [8] resembles in some aspects our approach for the development of service-based e-content delivery systems. It is of our belief that Turbine addresses the same problems in a far more application-oriented approach. For instance, although the Action, Page, and Layout elements of the

Turbine framework are in many ways similar to Modules, Services, and Templates the underlying rationale is different. In Turbine there is no uniformity in accessing the underlying data and there is no provision for a formal approach to module composition. Moreover, and in contrast to our simple yet powerfull content generation mechanism, Turbine utilises yet another custom scripting language for that purpose. The major difference between the two frameworks however is the lack of a service execution engine in Turbine. This implies that our approach due to the MCSL and the underlying MCE formally defines the notion of a service as a composition of modules and its overall execution.

5

Conclusions and Future Work

We have shown that the underlying notions of services, modules and providers presented here ensure that the framework is flexible enough to accommodate for the evolving requirements of e-content publishing systems. Finally, our architecture is not limited to e-content delivery, but can be used wherever service-based application are required, because of its modular nature. There is concrete evidence that the framework can be used for any type of servicebased applications since only one of the framework’s modules is associated with the generation and delivery of content. Substituting it with an appropriate module the framework could act as an FTP, HTTP or LDAP server. Enhancements of both the architecture and the framework may be carried out, in order to further expand its functionality and application domains. For instance, services may not be resident on the same host as the system. Work is currently undertaken to support distributed services. In order to provide a richer language for expressing business rules and the collaboration of distributed services and modules, extensions to the MCSL are required. Such enhancements will focus on complex module composition as well as the specification of remote modules. Another area that needs thorough investigation is that of transactional services, so that e-commerce and e-government applications may be realized under the proposed architecture. To formalise module communication it is necessary to provide a data-flow specification scheme, so that module interaction is expressed in a similar way to that of module composition.

References 1. E.Gamma, R.Helm, R.Johnson, J.Vlissides. Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley, 1997. 2. A.Goldberg and D.Robson. Smalltalk-80. The Language and its Implementation. Addison-Wesley. 1983. 3. D. Hollingsworth, The Workflow Reference Model, Workflow Management Coalition, Document Number: TC00-1003, 1995. Available from www.wfmc.org

4. D. Stamoulis, D. Theotokis, D. Martakos, and G. Gyftodimos. “Ateleological Development of Design Decisions Independent Information Systems”. in Nandish Patel, editor, Evolutionary and Adaptive Information Systems, IDEA Publishing Group, 2002. 5. http://www.asp.net/ 6. http://java.sun.com/products/jsp/ 7. http://www.php.net/ 8. http://jakarta.apache.org/projects/turbine