Applications in a same domain may have lots of common functionalities with each .... It will free the application creator from most of the development tasks, so it ...
IADIS International Conference on Applied Computing 2005
A PATTERN LANGUAGE FOR BUSINESS APPLICATION DEVELOPMENT Jean-Paul Bahsoun, Samar Tawbi IRIT, Paul Sabatier University, 118 route de narbonne, Toulouse, France
Bilal Chebaro Lebanese University, Faculty of Sciences I, Hadath, Lebanon
ABSTRACT In this paper, we define a pattern language that falls under the category of the architectural patterns. It proposes solutions for the development of applications with redundant functionalities. The work was based on a generic server for web application development. The first pattern of the language, ‘Service Provider’, proposes a solution to application development by non-experienced programmers. The ‘Generic Server’ pattern proposes a generic solution to evolving service providers, making it independent from business domains, by defining the server's functionality in the form of standardized services. ‘Encapsulated Layers’ pattern defines a structure of a generic application. And the last pattern ‘Service’ defines the structure of a service in this type of application. KEYWORDS Architectural Patterns, Reusability, Genericity, Web applications.
1. INTRODUCTION Constructing an architecture for software systems, especially for large-scale or industrial systems is a complex process (Buschman 1995). The current trend is to free application developers from the maximum of services in order to let them concentrate on the kernel of their applications. Predefined Service providers seem to be important in this domain as well as efforts done towards standardization of some functionalities in many domains, like for example the communication protocols proposed by CORBA and DCOM (Brown & Kindel 2002). Therefore, one of the most important approaches to facilitate application development is the reusability provided to its highest level (model reusability) by the concept of patterns defined by (Alexander C. et al, 1997). An analysis based on patterns is more efficient because this concept gives the architect a more abstract approach of his/her models and it represents the experience of many other analysts (Shalloway A. and Trott 2002). This is the case, since the patterns determine how the separate parts are combined together (Shaw 1995) in such a way to form a solution to a frequent problem. So, it proved important to propose some patterns for this domain. In this paper, we will define four patterns that representes abstractions of solutions adobted in a framework for automated Web development (Bahsoun et al 2003) (Tawbi et al 2005).
2. SERVICES PROVIDER Context: Applications in a same domain may have lots of common functionalities with each other but different designs and user interfaces. So why redo same development several times. It is a waste of time and effort.
245
ISBN: 972-99353-6-X © 2005 IADIS
In general, these applications have two aspects: the implementation and the formatting. The answer to the requirements of these two aspects requires different types of expertise, analysis and development on one hand and graphics, formatting and ergonomics on the other. One would like to create an application in a certain domain. Therefore, the creator of the application may not be very well experienced in programming but although he/she wants to conceive a robust and performant application. Obviously, it will be more easy to use certain predefined services for sophisticated functionalities rather than spending lots of efforts to develop them. Especially when experienced developers create them. On another hand, if the application creator from the second group would like to add certain sophisticated development to his work, it will not be easy for him as non-specialist. Problem: You would like to minimize the redundancy of the functionalities in order to reduce the development efforts. So, you are trying to reuse functions that have been developed in other applications. On another hand, you have to guarantee a good cooperation between the different sides of the application (developers and designers) without affecting the robustness and the efficacy of the applications. And essentially, you want to offer some functions created by experienced developers to non-specialists or simply less experienced people. Forces: The different applications may very probably have the same kind of services or even exactly some same service. Of course, it is not logical to redo a work that has been developed in the same domain. Especially, in a time everybody is talking about reusability at all levels of abstraction of an application from code reuse to patterns (Alexander C. et al, 1997)(Gamma et al 1995). We cannot always expect to find these different skills in the same individual. The deployment of an application requires the gathering of the efforts and skills of several persons belonging to different categories of expertise. This may lead to certain communication problems or incoherence. The designers face difficulties to achieve development tasks and developers do not have the time to care about format, colors and ergonomics of the application. It is more efficient for someone who is not expert in development to delegate his implementation tasks to more experienced people. But the problem is how to integrate these implementations in his work without making development effort. Solution: Create a services’ provider offering the common functionalities needed by applications in a certain domain, in form of services that could be used by the application creators. This services’ provider could be used by different applications in the same domain (figure1). It has to have a simple interface of use. This interface must be transparent to the services’ user in order to allow him/her to call the services without the need to know the structure of the provider. Services will be called when necessary in the applications. The system could be deployed as a server in a client/server structure, where the applications using the services will act as clients of this server; or as an application where the users will choose their services in some kind of graphical interface for example.
Figure 1. Services' provider
Examples: The web has become now a requirement for every one in all domains. User types are increasing the needs are increasing and the web sites are more and more complex. A study done by the Online Computer Library Center states that there were about 1’500’000 web sites in 1997 and this number has increased to about 8’750’000 in 2001. More than 55% of their creators are not programming specialists [11]. And because not all the site creators are development experts, they have to pay expensive coasts to achieve their sites creation. Besides, a web application like any application has two components: layout and development.
246
IADIS International Conference on Applied Computing 2005
So when the designers decide to do sophisticated programming (like chat rooms, news groups, user control, security…) themselves they may need a certain level of expertise in the domain. Our approach in (Tawbi S. and Chebaro 2002) is to propose a server providing development services for web site creation, as well as the storage, access and processing of the information. This server provides services in a certain domain to ease web site creation. These services can cover all interactions, processing & scripts needed in this domain as submission forms generation, processing of the posted data, DB creation, access and control. The services are called in a simple way. Besides, to use the server, web site creators don’t need to be experts in programming. Our server will help non-specialists to develop sophisticated web sites. All users have to know is a list of the services available and their attributes. They will send HTML (or XML) pages containing service calls and receives these pages with the services results (figure 1).
Figure 2. Web service Generator use
Known uses: From other known uses of the service generator pattern we could list: The html page editors like FrontPage (Edmonds 1995), Dream Weaver (Lowery J. and Deming D. 2002), and others The development environments for programming languages like Borland C++, Symantec Visual Studio, Jbuilder, and many others. The IDLs (Interface Definition Languages). Consequences: The application of the pattern Service Generator has several consequences: It will free the application creator from most of the development tasks, so it makes possible for a large group of non well-experimented programmers to implement relatively sophisticated applications. There is complete separation between the two groups who work on a project while keeping an efficient communication between them. The users who call the services only know the interface of use of these services. Whereas the developers continue to implement and to modify some services and this in complete transparency to the clients. Thus, the site creators are freed of the difficulties and details bound to the implementation of their sites’ functionality. They need only to know the available services list and their possible parameters. Related patterns: Generic Server pattern is the generic version of this pattern. The Service Provider will be applied when the services needed are in a same domain, and the Generic Server will be applied when the services belong to different categories. Our pattern is inspired from Technical Infrastructure (Meszaros 1997) that proposes a solution to system complexity by encapsulating the computing tasks from the application developer. It gives a solution for the development of important systems with clearly separating the computer science domain from the design domain.
247
ISBN: 972-99353-6-X © 2005 IADIS
3. GENERIC SERVER Context: You are designing a services’ provider application, but you need different types of services in different domains. In addition, not all of the services are foreseen at the time the application is created. You want your system to be extensible during its lifetime, and to easily support updates. New services will continuously be added responding to new requirements. Realizing a service provider will soon be insufficient because of the continuously increasing needs. On another hand, the extensions and updates of the services made on the system must not affect the users. These users do not want to redo their work each time the provider’s developers make changes to the system. Problem: How do you design such application in a way to ensure the flexibility and extensibility of the system? What could guarantee the harmony of the work between all actors of the application? They must stay independent from each other without affecting the performance of the system. Forces: A well-defined structure gives the developers the possibility to easily maintain their application. Besides, computer applications evolve permanently to integrate new functionalities answering the evolution of needs. The most important thing that applications’ creators care about is to know how to achieve these updates the easiest way and especially with less cost. So for future developers the structure must be understandable and not complicated in order to allow updates. When working on several domains, one is not always capable to develop all needed services in all domains. In addition, new functionalities could arise during the lifetime of the application. Solution: Conceive a generic application in such a way that it standardizes the manipulation of its services and the communication with users. This could be achieved by defining from one side a certain protocol of communication with the users and from the other side a prototype of services definition. Example: We think of creating a service provider for web application development. It is obviously very difficult to make a server for each domain on the web or to create a universal one for all domains. So, in order not to restrict this server to a certain domain we’ve defined a generic server GenericServ that standardizes the communication protocol with the site creators independently of the web site domains (education, medicine, emailing, banking…). It offers a prototype of all services that would be implemented. It’s an abstract service generator that could be specialized to different specific domains to form operational servers. These servers offer functionalities needed by web sites in these domains. The specialized servers could then be implemented by creating specific services to their domain according to the prototype imposed by GenericServ. As an example, we can create GenericServ servers for publishing, email servers, e-business and so on (figure3).
Figure 3. GenericServ, a web generic server
Known uses: In the domain of distributed applications development, the distributed object norms have produced a communication layer like in CORBA (Daniel 2000) and DCOM (Brown & Kindel 2002), in order to free the developers of such applications, from the implementation of communication functionality. They have imposed a certain standard for the communication and the formatting of the distributed objects in order to abstract all functional domains and programming language. The distributed objects of CORBA and DCOM are generic protocols that are independent from functional domains, development languages and deployment platforms of the applications.
248
IADIS International Conference on Applied Computing 2005
Another known use of this pattern is libraries like CASTOR that illustrates a generic source generator offering services to map between Java objects and XML schemas. Consequences: Applying the Generic Server pattern makes the application more extensible and more flexible. The standardization of the services allows the developers work independently from the control and management of the services. The generic nature that this pattern gives to the system makes it domain independent, so it will be applicable to more categories of applications. Future and unexpected needs could be added automatically thanks to the standard manipulation of the services. Related patterns: The Generic Server could be structured using several architectural patterns as Three Layered Architecture (Shaw 1995), Reflection (Buschman 1996), Pedestal (Rubel 1995). But we suggest that it will be structured according to the ‘Encapsulated layers’.
4. ENCAPSULATED MODULAR LAYERS Context: You want to conceive a generic application. But now you need to make a good architecture. This architecture should reinforce the genericity. You should keep the actors of the application independent from each other in order to maintain a generic domain independent system. Problem: You must find the best way to realize the genericity of your system in a flexible architecture. Forces: Layered architectures have proven themselves in many kinds of applications. But, we must find a way to keep the genericity of the system. Modular architectures are known for their flexibility and their facility of update. At the same time the separation made between the tasks of the different actors of the application (developers and designers) should be respected. A weakness in this characteristic may affect the genericity of the application. This is particularly true if your goal is to build an extendable system where you would like the developers to be free to make changes without affecting the structure of the whole system. Solution: Create a four-layered architecture where you separate the processing core from the services offered by the application. Therefore, conceive each layer in a modular structure. The layers must be opaque so that they could evolve independently from each other. Simplify the interfaces between the layers in order to ease the updates on modules. The first layer will contain the database management (DB creation, access and control). The second layer is the core of the server. It includes general processing like clients management and services control. In this layer, will be defined the generic aspect of the application, because it will contain service management and manipulation but defined independently from their nature and business domains. It defines a standard way to deal with services. The communication with the users and other layers is done via interfaces encapsulating its internal work. So, it will be completely opaque, to the user from one hand and to the other layers from the other. A third layer should be defined containing the basic services that could be used in all domains, we could call them domainless services. This layer will constitute a basis on which will be created all other services. And finally, the last layer contains extended services that are domain dependant, and their utilities. The two central layers are the common layers to all types of servers since they are domain independent. Example: The servers have a common architecture based on a generic server ‘GenericServ’. It standardizes the management of the services and defines a communication protocol between the different actors of the application. Thus, around this core, we define a layer containing the services of a specific domain to form a useful server. For the application, we have created a publishing server: PubliWeb.
249
ISBN: 972-99353-6-X © 2005 IADIS
It defines the generic structure functioning mode of all servers in the previously described context. Therefore, we distinguish in every server, three layers (figure 4): Core layer GenericServ that constitutes the kernel of the system. It is the common part to all servers including general processing. This core layer defines and implements the management of the users and services in a generic way so it would be independent of the business domain of the specified server. It proposes a skeleton for all services that will be defined on this server. It contains four modules: 1. Connection manager: It constitutes the point of entry to the server. Its role consists of the request of a connection, the verification if the request includes the necessary parameters and the management of the interaction between the client and the server. 2. Analyzer: It is a module that takes care of the users’ requests analysis. It must be transparent in order not to put too many constraints for the users. Its role is to capture the service calls, to verify them syntactically (the format of the call) and to extract the attributes of the call. Then it sends this call to the “Service Manager” that will delegate it to the corresponding service. 3. Service manager: It distributes the calls, arriving from the analyzer, to the appropriate services after verifying their existence and their dependencies with other services. This is achieved by keeping a temporary trace of the running services. Thus, the interdependent services will consult the service manager to verify the consistency of their states. 4. Session Manager: It handles the client sessions management, like the acceptance or the rejection of having several sessions of a same client according to the server's type. It also safeguards the state of the client’s work during the session. Basic utilities layer that contain basic services that could be present in all servers like services for database creation, manipulation & access, authentification services, etc… And a Specific layer forming the set of services proposed in a precise domain like article publishing and their utilities. Some examples are: o Online article submission o Article viewing o Article acceptance or refuse The services proposed by the system must be created in accordance with a skeleton proposed by GenericServ. Some utilities could be needed for the processing of the servicves containing some redundant parameters and functions. Connection Manager Session Manager
Analyzer Service Manager
Basic Services Utilities
Extended Services
Figure 4. GenericServ based server’s architechture
Known uses: The Amoeba operating system (Tanenbaum 1992) consists of a kernel providing basic services for processes and network communications, memory management and I/O services. But the difference is that in the ‘Encapsulated Layers’ pattern we restrict the services to have a predefined skeleton in order to generalize their management. Consequences: The opaque Layers with the encapsulating interfaces emphasize the reusability of the system. In fact, to reuse the application in another sub-domain developers have just to implement the set of extended services needed in this domain. Obviously, we say sub-domain because we cannot imagine reusing the application in all kinds of applications. For example, in web programming the same server could be reused for providing e-business, medical, administration services. The evolutions of the three layers are independent from each other due to their opacity. Related patterns: This pattern gives the development structure of an application of the type ‘Generic Server’.
250
IADIS International Conference on Applied Computing 2005
The services offered by an application specifying the ‘Encapsulated Layers’ could follow the structure of the Service Prototype pattern. ‘Layered Architecture’ pattern (Shaw 96) gives an architecture of a system composed of three layers: core level, basic utilities and useful system. Our pattern is a specialization of this pattern. ‘Reflection’ Pattern (Buschman 1996) proposes an architecture divided into two independent parts a base level and a metalevel. The first defines the application logic that consists of an unchanged part of the system, and the second one defines Metaobjects that represent the behavior of the software. The difference with our pattern, although we define core and basic layers and an extended layer these layers are capable to change independently.
5. SERVICE PROTOTYPE Context: These are functionalities proposed by a generic services provider system. The system must propose a determined structure for service creation. The set of the services constitutes the interface of communication between the user and the developer. In other words, it is the interface between the two poles acting on the system. It allows conceiving a protocol of communication between the client using the functionality and the server offering it. Problem: We must guarantee that the integration of new services doesn't alter the harmony of work between the different modules. Forces: We have a system whose services must continuously increase during its life cycle. It is necessary to be able to add new services at any time without being forced to redo the whole work. The services should be called according to the same interface. The system proposes several services having the same structure. We apply the generic server pattern on a system offering functions in the form of services. Solution: Define each category of functions in a class and centralize the management of these classes in one point that constitutes the link to the rest of the system (Tawbi S. and Chebaro 2003). We group these functionalities to five classes (figure5): Service: An object of this class receives the request from the system, delegates the tasks to the corresponding objects, and then sends back the responses. Execution: It handles the execution and the consignment of the answer to the user. Trace: It contains the permanent information concerning the request. It will remain present as long as the data that it contains is relevant. Temporary data: It must keep the temporary information during the execution of a request. The object will be freed at the end of the request processing. Parameters: Such class, generally static, contains the parameters and functionality necessary to the execution.
Figure 5. A service Architecture
Example: The ‘login’ service is composed five classes (Bahsoun et al 2003) login, loginTrack, loginRedThread, LoginRedirection and loginparameters. Consequences: The ‘Service Prototype’ pattern application has several advantages:
251
ISBN: 972-99353-6-X © 2005 IADIS
The breakdown of the job in several classes, each taking care of a very precise work, allows the isolation of the different aspects of the service. As a result, the debugging becomes simpler. The structured design allows a simple and automatic new service implementation. The creator of the services is not forced to go into the details of management of the services, he will only needs to know where to place the processing and the data, depending on their types and their view. The developer of the services, according to his needs, is not forced to implement all classes of the pattern. It is concieved in such a way so that one can implement only the necessary classes without affecting the work of the service. For example a service that doesn't require to keep a trace doesn't have to create the class ‘Trace’. This optimizes the work. The evolution of a service doesn't force the developer to redo everything since he needs only to change the class that corresponds to the required change. Related patterns: The ‘Service Prototype’ pattern could be used when creating a ‘Services Provider’ adopting the ‘Encapsulated Layers’ pattern.
6. CONCLUSION In this paper, we have proposed architectural patterns in the area of service provider applications. These patterns have been designed in order to help reusability. This kind of application is proposed in the first pattern as a solution of the continuous and increasing needs in software development. Then a generic version of this pattern is introduced by the ‘Generic Server’ that maintains a clear separation between the actors of the system. The architecture of such system is described in the pattern ‘Encapsulated Modular Layers’ that has been designed by emphasizing the independency between layers and standardizing the offered services. The proposed architecture ensures the flexibility and extensibility to the system. In the last pattern, we propose the structure of a service offered by a services provider adopting this pattern. With its structured design, the ‘Service Prototype’ pattern facilitates the implementation and the modification of services.
REFERENCES Alexander C. et al, A pattern Language, Oxford University Press, 1977. Brown N. and Kindel C., Distributed Computing Object Model Protocol – DCOM/1.0, www.grimes.demon.co.uk/DCOM/DCOMspec.htm, 2002. Bahsoun J. P. et al, 2003, A Web Services Provider: Generic Architecture and Patterns for Business Applications, In IFIP03 the third IFIP International conference on E-business, E-commerce, E-government, Sao Paolo, Brazil. Buschman F., 1995, A System of Patterns, Pattern Language of Program Design, Vol.1, Addison Wesley. Buschman F., 1996, Reflection Pattern, Pattern Language of Program Design, Vol.2, Addison Wesley. Buschman F. et al, 1996, Sommerlad P. & Stal M., Pattern Oriented Software Architecutre V.1, John Wiley & sons. Daniel J., 2000, Au cœur de CORBA (avec Java), Vuibert. Edmonds T., 2002, Essential FrontPage 2002 for web professionals, Prentice Hall. Gamma E. et al, 1995, Design Patterns: Elements of reusable Object-Oriented Software, Addison Wesley. Lowery J. and Deming D., 2002, DreamWeaver MX bible, John Wiley & sons. Meszaros G., 1997, Archi Patterns: A process pattern language for defining architectures, Pattern Language Of Program Design conference. Rubel B., 1995, Patterns for Generating a Layered Architecture, Pattern Language of Program Design, Vol.1, Addison Wesley. Shaw M., 1995, patterns for software Architectures, Pattern Language of Program Design, Vol.1, Addison Wesley. Shalloway A. and Trott J.R., 2002, Design Patterns Explained: A new perspective on object-oriented design, AddisonWesley. Tawbi S. and Chebaro B., 2002, “GenericServ, A Generic Server for Web Application Development”, the first Eurasia conference, Shiraz, Iran. Tawbi S. and B. Chebaro, 2003, ‘Service Providers patterns for client/server applications’, 5th International Conference on Enterprise Information Systems, IEEE computer society press. Tawbi S. et al, 2005, ‘A framework for Web applications development: A SOAP based communication protocol’, in the proceedings of the ICEIS 2005 conference, Miami, USA.
252
