FIELD OF INVENTION:
[1] Present invention relates to software application architectures such as N-tier application architecture. More particularly this invention relates to a key component in the N-tier application architecture which provides a system and method for balancing of services between providers of business services and users of business services.
PRIOR ART:
[2] In software engineering, multi-tier architecture, or more commonly referred as N-tier architecture is a client-server architecture in which an application is executed by more than one distinct software agent. For example, an application that uses middleware to service data requests between a user and a database employs multi-tier architecture. The most widespread use of "multi- tier architecture" refers to three-tier architecture. The N-tier Architecture provides the flexibility of
: combining the functionalities of different tiers relatively independently through a loosely coupled component framework. It also enables an effective integration of business services offered by r • different service providers through application integration.
[3] There are several service scenarios in the govemment-to-business (G2B), government-to- citizens (G2C), and business-to-business (B2B) areas where the back-end application systems of service providers are at varying levels of service maturity, thereby making it difficult to provide
CO integrated services to the users at the front-end.
O [4] Issues such as uneven development of back-end application systems of service providers, and varying business logic for the same services across service providers make it all the more difficult to provide seamless integrated services.
[5] From a user's perspective, having to deal with different types of front-end interfaces for various services would be cumbersome and would defeat the very purpose of a web application such as a portal providing integrated services. The portal itself would lose its functional scalability if it seeks to design one-off solutions to the varying requirements of different service providers participating in the provision of the integrated services.
o
OJ
[6] The challenge, therefore, is to design an application architecture that can provide (i) a uniform look and feel as well as functionality, hiding the complexities and unevenness of the

' A
A
maturity of back-end application systems, and (ii) can also make the varying business logic for similar services across service providers, transparent to the end users.
[7] The application architecture should take into consideration the varying needs of different service scenarios across different service providers.
[8] The concept of a Service Balancer has arisen in the context of provision of seamless and integrated services to the business entities through a G2B portal, so as to cope with the varying levels of development of the backend service provider applications and the different business processes prevalent across these service providers.
[9] The role of the Service Balancer, as a key component in the N-tier application architecture, is therefore quite relevant for the design of application architectures, especially in the G2B, G2C and B2B scenarios, and is discussed in this invention.
SUMMARY OF THE INVENTION:
[10] The business goal of an integrated services portal, such as a G2B portal, is to provide services integrated seamlessly across the jurisdictional and geographical boundaries of multiple back-end service providers. Several problems arise in achieving this goal, the chief among them being that - the backend application systems of the various service providers are un-evenly developed, and the business logic and procedures for the same service (say for example a G2B service like payment of sales tax a state/province) vary considerably across multiple service providers.
[11] A solution to the problem defined above, and described in this invention, is to add a new component in the N-tier application architecture called Service Balancer, that can dynamically handle the requirements of a variety of service scenarios, and iron out the un-evenness of service provider back-end application systems, thus enabling the web application portal to present a uniform interface to the front-end users.
The following objects had been identified for carrying out the investigations for the development of the Service Balancer.
1) One object of the present invention is to develop a Service Balancer which can receive service requests from multiple sources such as standard internet browsers or through mobile phones, handhelds or PDA's. In addition, user requests to the web application might also come through another client application(s). The user requests to the web application come through standard web protocols such as HTML (111), WAP (112), and XML (113) including other forms of communication over the web such as RPC or other middleware protocols which may also be used.
2) Another object of the present invention is to have a system where the granularity can be at the level of Forms, databases or portions of applications. Compared to the granularity offered by web services, which can be too atomic to be of great use in such situations.
3) Another object of this invention is to develop a system which possess the ability to handle service-related context-sensitivity, where same services or category of services need to be handled differently vis-a-vis different back-end service scenarios.
4) Another object of the present invention is to develop an integrated services portal which provides business services as distributed applications.
5) Yet another object of the present invention is to develop a system which provides flexibility for deployment of applications and fragments of applications in a manner that is best suited to each service scenario without any constraints of the back-end systems, or for other reasons.
The following objects had been identified for carrying out the investigations for the development of the Service Balancer.
1) One object of the present invention is to develop a Service Balancer which can receive service requests from multiple sources such as standard internet browsers or through mobile phones, handhelds or PDA's. In addition, user requests to the web application might also come through another client applications). The user requests to the web application come through standard web protocols such as HTML (111), WAP (112), and XML (113) including other forms of communication over the web such as RPC or other middleware protocols which may also be used.
2) Another object of the present invention is to have a system where the granularity can be at the level of Forms, databases or portions of applications. Compared to the granularity offered by web services, which can be too atomic to be of great use in such situations.
3) Another object of this invention is to develop a system which possess the ability to handle service-related context-sensitivity, where same services or category of services need to be handled differently vis-a-vis different back-end service scenarios.
4) Another object of the present invention is to develop an integrated services portal which provides business services as distributed applications.
5) Yet another object of the present invention is to develop a system which provides flexibility for deployment of applications and fragments of applications in a manner that is best suited to each service scenario without any constraints of the back-end systems, or for other reasons.
6) Yet another object of the present invention is to develop a system which can run a full-fledged centralized application from out of the data centre where the application is hosted. This is required in situations where service providers providing certain services do not have ready back-end applications to service the requests or do not find it economically feasible to design and maintain the necessary back-end systems due to various reasons.
7) Another object of the present invention is to develop a Service Balancer that can be demonstrated by developing generic service applications for the service providers
8) Another object of the present invention was to provide a system architecture that can provide for the applicability of multiple technology options such as J2EE, .NET, web services, EJB's, etc to implement the architectural components.
9) One more object of the present invention is to develop a system which is based on - standard protocols such as RMI / SOAP 434 and XML 435.
BRIEF DESCRIPTIONS OF THE FIGURES :
[12] Fig.1 illustrates an exemplary web application environment of a typical N-tier web portal application that interfaces with multiple service providers at the back-end, and with the Service Balancer as the additional component that brings the flexibility of dealing with multiple variants of the back-end scenarios.
[13] Fig. 2 highlights the various service scenarios involved in integration with multiple back-end service providers.
[14] Fig. 3 depicts the steps involved in the process of balancing of services between service providers and users using the Service Balancer.
[15] Fig. 4 offers a high level view on the conceptual architecture of the Service Balancer, outlining the main building bricks.
[16] Fig. 5 shows an example of an exemplary computing environment within which the Service Balancer may be implemented.
DETAILED DESCRIPTION OF THE INVENTION:
This disclosure addresses a new component in the N-tier application architecture that can dynamically handle the requirements of a variety of service scenarios that exist at the different service provider applications. More particularly, this new component will be able to invoke an appropriate combination of different tiers in different service scenarios in a context-sensitive manner and provide an answer to the imbalance between the requirements of the front-end users and the preparedness of the back-end service providers to meet such requirements.
[17] The solution proposed involves the design of a Service Balancer that is configurable and programmable to meet the requirements for provisioning of seamless and integrated services to the users through a web portal application, so as to cope with the varying levels of development of the back-end service provider applications and the different business processes prevalent therein.
[18] The word 'service' is used here in a functional sense as in 'business service', and not in a technical sense as in 'web services'.
[19] Exemplary web application environment with service providers and users
[20] Fig 1 is a representation of the application architecture of a typical web portal that has to interface with multiple service providers at the back-end. The architecture consists of typical components like web server, directory server, application server, database server and integration (EAI) server. It may also consist of a forms server (in the case of a G2B or G2C portal that has a large number of e-forms to be handled). The Service Balancer is the additional component that brings the flexibility of dealing with multiple variants of the back-end scenarios.
[21] The web application environment includes representative users 101 (1), 101 (2), 101 (n), which access the web application portal to request for services provided by the service providers. The users can access the web application through standard internet browsers or through mobile phones, handhelds or PDA's. In addition, user requests to the web application might also come through another client application(s). The user requests to the web application come through
standard web protocols such as HTML (111), WAP (112), and XML (113). Other forms of communication over the web such as RPC or other middleware protocols may also be used.
[22] The web application environment also includes representative service providers 160 (1), 160 (2),..160 (n), servicing requests from the web application through a standard web protocol like XML for information exchange.
[23] The service provider applications, referenced as 160, are back-end systems implemented by agencies such as government, and other service providers providing fulfilment of G2B, G2C and B2B types of services. These applications can be implemented in various ways such as web services, service oriented architectures, web applications, etc.
[24] The web application environment depicts a situation where the state of readiness/ uniformity of the same business service to be rendered by the service providers have 3 variants namely, 'Application is Ready', 'Application Not Ready', and 'Non-uniform Business Logic'.
[25] The web application 130, itself is a typical example of an integrated services application such as a G2B, G2C or a B2B portal that is hosted in a data centre networked environment, and uses the service provider applications to service requests from users. The web application is composed of many software applications deployed in an N-tier architecture framework and executing on various typical servers such as Web Server (132), Forms Server (134), Database Server (136), Enterprise Application Integration (EAI) Server (138), Application Server (140), and Directory Server (142).
[26] The Service Balancer 144 is the new component in the N-tier architecture that orchestrates the flow of application logic depending on the nature of the user request and the composition and sequence of the events required to fulfil the service request.
[27] Application servers and integration servers handle business services or stacks of services at the application level. However, there are several scenarios, as explained in this invention, where the granularity can be at the level of forms, databases or portions of applications. The granularity offered by web services, on the other hand, can be too atomic to be of great use in such situations. The Service Balancer seeks to handle these situations efficiently by offering a granularity that is midway between that of the application server and a typical web service.
[28] Application servers and integration servers typically work with different back-end service providers on a one-on-one basis through interfaces, connectors or adapters. They do not possess the ability to handle service-related context-sensitivity, where same services or category of
services need to be handled differently vis-a-vis different back-end service scenarios. In this situation, the Service Balancer provides the necessary orchestration by routing the service requests to the appropriate back-end service provider application based on service scenarios in a context-sensitive manner.
[29] In the context of development of an integrated services portal, most often, there is a need to provide a business service that is so infrequently used that it is not cost-effective to provide the same as a distributed application. There are other scenarios as well, like the back-end service provider application not being ready. Service Balancer provides a ready solution in such scenarios, as it can combine centralized solutions with distributed solutions seamlessly and transparently.
[30] Given the capability of the Service Balancer to provide flexibility for deployment of applications and fragments of applications in a manner that is best suited to each service scenario, the Service Balancer becomes ideally suited to achieve a quicker time to market. Typical application architectures will have to make do with fewer services at the initial stages of the portal, either because the back-end systems are not ready, or for other reasons.
[31] Service Scenarios
[32] Fig 2 classifies different service scenarios in accordance with (i) the state of readiness of the corresponding back-end applications, and (ii) the varying business logic of the back-end systems across different service providers.
[33] The information in column 208 indicates that a normalization of the user experience at the front-end, while providing the service through a web portal, can be possibly achieved by an appropriate combination of the use (invocation) of the Presentation layer, Presentation Logic layer, Business Logic layer, Data Access layer and Database layer of the N-tier application architecture.
[34] Presentation layer (tier) is an application component of the N-tier architecture which is deployed on the front-end system or the end-user's machine, and is responsible for accepting the user requests, showing the results of the requests, and presenting the related information in a user-friendly manner. Standard web applications such as internet browsers are used to achieve the presentation layer functionalities.
[35] The core functionality of the Presentation Logic layer is to convert the user requests accepted by the Presentation layer into a form that can be understood by the Business Logic layer, and to transform the results obtained by the Business Logic layer into a form presentable to the user. Open standards using web technologies such as HTML, XML are used for the data exchange between the Presentation layer and Business Logic layer. Component technologies such as VB Script and JavaScript are used for the transformation logic, whereas middleware technologies like SOAP, CORBA, DCOM, and RMI are used for providing the reliable messaging infrastructure.
[36] The Business Logic layer is responsible for implementing the business objects and rules associated with the services provided by the N-tier application. Distributed object-oriented and component technologies, and web services technologies, such as Enterprise JavaBeans (EJB), Java Servlets, JSP, .NET, etc. are the well known technologies employed to achieve the business logic functionality. Technologies such as Business Process Execution Language (BPEL), ebXML are used to program the business rules associated with the business services.
[37] The Data Access layer is responsible for interfacing with the underlying data mechanisms such as a database or directory. Standard database connectivity and directory technologies such as ODBC, JDBC and LDAP are used for this purpose.
[38] The Database is the logical representation of the data in an N-tier application and the Database layer is responsible for storing and managing this data.
[39] The use of the Data Access and the Database layers as part of the web application portal infrastructure would mean running a full-fledged, centralized application from out of the data centre where the application is hosted. This is used in situations where service providers providing certain services do not have ready back-end applications to service the requests or do not find it economically feasible to design and maintain the necessary back-end systems due to various reasons.
[40] As depicted in Fig. 2 column 208, the first service scenario SS #1 presents a scenario of a service for which the back-end service provider has an associated application, which may be a simple client-server application, or a much more sophisticated application such as a web application with web services. Also, the scenario shows that the business logic for the service is the same across multiple service providers, which essentially means that multiple service providers exist providing the same service and having the similar service business logic. As an example, consider the case of a G2B portal providing integrated online services, such as a service which enables a business entity to pay sales taxes of all the states/provinces in which the business operates. Each of these states/provinces may have the back-end application systems or service provider applications to process the service requests from the G2B portal. In this context, it is worthwhile mentioning that the business logic involved in payment of sales tax may be the same across the various service providers. To provide integrated services through the G2B portal it is necessary to hide the complexities of the service provider applications and present a consistent look & feel to the user. Service balancing in this service scenario is limited to invoking the presentation layer to provide a consistent look and feel for the users.
[41] The service scenario SS # 3 shows a situation in which the service provider does not have an associated back-end application for a service, but the business logic associated with the service is uniform across multiple service providers. Using the same example cited above of the service for payment of sales tax for a state/province, the challenge for the G2B portal providing integrated services would be to provide the service when the back-end service provider application is not ready. In this case, the service balancer can provide a generic presentation layer along with the necessary business logic and database access logic in a uniform manner, to enable the G2B portal to seamlessly provide integrated services from multiple service providers across the various states/provinces.
[42] In case of service scenario SS # 2, though the service provider has an associated back-end application for the service, the business logic for the service is not common and varies across other service providers providing the same service. So, the challenge in providing integrated services through a G2B portal is to iron out the differences in the business logic and provide a consistent look & feel to the user. Considering the same example cited in case of service scenarios SS #1 and #3, it may also be possible that the business logic involved in payment of sales tax may not be uniform and may vary across various service providers. In this case, service balancing provides an easy solution for coping with the differences in business logic by invoking the necessary presentation and presentation logic layers for proving integrated services through the G2B portal.
[43] Scenario SS #4 depicts a service scenario where neither there is a back-end service provider application nor is the business logic for the service uniform across multiple service providers providing the same service. The challenge in providing integrated services in this service scenario is to cope with the lack of back-end service applications and differences in business logic, and yet provide a consistent look & feel to the user. The service balancer helps in achieving this objective by invoking the presentation layer, presentation logic layer and also the business logic layer to provide fulfilment of the service.
[44] Process of service balancing between service providers and users
[45] Fig. 3 depicts the steps involved in the process of balancing of services between service providers and users using the Service Balancer.
[46] The column 302 represents the users of the web application portal, such as a G2B portal providing integrated G2B services. The users request for services provided by service provider applications 306.
[47] The example shows four service requests - Service 'A' 320 provided by service provider SP1, Service 'B' 322 provided by SP2, Service 'C' 324 provided by SP3, and Service 'D' 326 provided by SP4, as user requests from the portal.
[48] The service provider applications are the same as depicted in fig. 1 - 160 (1), 160 (2),..160 (n), servicing requests from the web application portal.
[49] The web application environment 130 from fig. 1, is also represented here, but depicting only the Service Balancer. The other elements in the web application environment have their defined roles and need not be elaborated in this invention.
[50] The interactions between the users, service balancer and the service provider applications are shown as 308,310, and 312
[51] The first step in the service balancing process is to check for the maturity level of the service provider application providing the service, by accessing the service profile associated with the service. The service profile is explained in more detail in fig. 4.
[52] The service profile indicates the service name, service description, maturity level, and location of the service provider application along with other parameters.
[53] Based on the maturity level of the service provider application, the service balancing decision is made.
[54] Each of the service requests 'A' 'B' 'C' 'D', can be based upon the service scenarios SS #1, SS #2, SS #3, and SS #4, depicted in column 202, fig. 2.
[55] Based on the service scenarios, the Service Balancer will provide the necessary presentation, presentation logic, business logic or database access logic modules required for fulfilment of the service requests.
[56] The data associated with the services may be stored in the DB server 136 shown in fig. 1, or in the database of the service provider back-end system.
[57] In this case, it is worthwhile noting that in certain scenarios, it is possible that services of similar nature and business logic are being offered by more than one service providers. The real success of the Service Balancer can be demonstrated by developing generic service applications for these service providers. So, with one such generic application, the Service Balancer can seamlessly integrate with different service provider back-end systems irrespective of their maturity levels.
[58] High-level conceptual architecture of the Service Balancer
[59] Fig. 4 offers a high level view on the conceptual architecture of the Service Balancer, outlining the main building bricks. The architecture provides a framework with the infrastructure! components I modules involved in the design of the Service Balancer, with the interactions between them.
[60] One of the key aspects in the design of the Service Balancer architecture is the applicability of multiple technology options such as J2EE, NET, web services, EJBs, etc to implement the architectural components.
[61] The Service Balancer is designed as a component within the overall N-tier architecture framework of a web application portal, such as a G2B portal providing integrated online G2B services.
[62] The function of the Service Balancer is to accept requests from the web application server and to invoke the required services in a context-sensitive manner transparent to the user. The core principles used in the design of the Service Balancer are: it should be configurable and programmable, standards-based, and should be based on a service-oriented architecture. The interactions of the Service Balancer with the web application servers and with the service provider applications may be based on industry standard protocols such as RMI / SOAP 434 and XML 435. Concerns related to security, access1 control, and authentication of requests addressed by the Service Balancer, though not specifically shown in the conceptual architecture view, are the responsibility of the Service Balancer. These may be addressed through mechanisms such as server-server authentication. In addition, the Service Balancer architecture must be capable not only of responding to a high rate of service requests, but also to satisfy a request as quickly as possible.
[63] The Service Balancer maintains a directory of all the services offered by the web application portal along with the profile of each service. The Service Profiles 414 contain information adequate to enable the portal to access or invoke the different layers in the application architecture like the presentation layer, presentation logic layer and the business layer or any desired combination thereof. The Service Profile associated with a particular service contains a number of configurable parameters like: Service Description, Service Name, Service Code, Maturity level of service provider application, Uniform resource identifier of service provider application, Database connectivity to the service provider application. This is not a comprehensive set of parameters. As and when new services and service provider applications are developed, more configurable attributes may be added.
[64] The Service Profiles can be configured through a web client 432. The configuration file itself may be based on XML standards, so that changes to the configuration will not need any software code changes. The Service Profile Configuration Module 402 is the architectural component responsible for the configuration of the service profiles. The Service Profiles 414 itself may be stored in a database or a directory, based on open standards. In this way, the Service Balancer is designed to be programmable to enable changes to be effected in the service profiles in tune with the changes in the service scenarios, say for example: the development of service provider backend systems / applications, changes in the business logic across the service provider applications.
[65] As opposed to a monolithic server architecture in which all the activities are done by a single unit (in which different parts of handling a request are poorly delimited), the Service Balancer takes a modular approach. There is a core part of the Service Balancer called the Service Balancer Controller Module 404 that is responsible for defining and following the steps in servicing a request and several modules that actually implement the different phases of handling the request. In addition the controller module also implements a number of utility functions, not shown in the conceptual view.
[66] The controller module accepts requests from the web application server, interprets the requests in terms of services required, accesses the service profiles of the services, checks the maturity levels of the services, and provides the necessary service balancing decision. The request is then forwarded to the Orchestration Module 406 for orchestration of the sequence of events for the fulfilment of the service request.
[67] The Orchestration Module 406 takes care of flow-based transactions such as: identifying the layers to invoke and creating the necessary sequence of events for service fulfilment.
[68] The Service Fulfilment Module 412 invoked by the orchestration module takes care of identifying the sources (locations) of the presentation, presentation logic, business logic, and database logic required for complying with the service request.
[69] The Application Modules 410 such as Presentation Module 418, Presentation Logic Module 420, Business Logic 422, and Data Access Logic Module 424, may be programmed as generic components based on service scenarios.
[70] The Context-sensitive Routing Module 408 is responsible for: routing the sequence of events in a context-sensitive manner such that the output at the user front-end is consistent; ensure that the sequence is followed in fulfilment of the request; and maintain the request-response-reference logs.
[71 ] Exemplary computing system environment
[72] Fig 5 shows an example of an exemplary computing environment within which the balancing of services between service providers and users can be implemented (either partially or fully), using the computer and network architectures described herein.
[73] The exemplary computing environment is only one example of a suitable environment, and is not suggestive of the scope or functionality required of the computer and network architectures.
[74] More particularly, the environment consisting of the Service Balancer 142 may be implemented using well known computing systems such as server computers, server blades, multiprocessor systems, and mainframes etc. Servers tend to read data from the hard drive into memory, process the data with the CPUs, and then send it out to the requesting computer via the network (e.g., web server).
[76] The environment includes a generic server computing device 520. The components of this generic server include but are not limited to, a system bus 522 connecting various system components, two or more processors / processing units 524, network and video adapter cards 526 and 528, a memory controller hub 530, a hard disk controller card 532, memory modules such as DIMM' 534, PCI slots 536, and system memory 538.
[77] The system bus 522 represents one or more of possible types of bus structures, such as the PCI (Peripheral Component Interconnect) bus, capable of handling 64 bit data transfer, ideally suited for server environments. Older bus structures such as ISA (Industry Standard Architecture) and EISA (Extended ISA) provide up to 32 bits of data transfer. The PCI slots 536 can handle 64 bits of 64 bits of data at a time.
[78] The system memory 538 includes computer memory in the form of random access memory (RAM) 540, and read only memory (ROM) 542. A basic input/output system (BIOS), containing the basic routines within the computing device, such as start-up, is stored in the ROM. The RAM typically contains the program code and data of the program currently in execution by the processing unit.
[79] The memory controller hub 530 helps communication between the memory, CPU and I/O helps maintain memory.
[80] The I/O controller hub 544 helps with the initial boot-up of the system and deals with slow speed I/O devices such as keyboard, mouse.
[81] The memory module DIMM's 534 provide for high speed storage of code and data used by the CPU and are available as DIMM - Dual In-line Memory Modules from many DIMM manufacturers.
[82] Hard disk controller card 534 provides several connections, such as SCSI, to the hard drive, thus providing for many hard drives with large storage capacity
[83] Network adapter card 528 provides several 100Mbps ethernet connections, which go to a switch or router
[84] The server computer 520 also includes other removable/non-removable, storage media, such as a hard disk drive 548 for reading from and writing to a magnetic media (not shown), and an optical disk (CD ROM) drive 510 for reading from and/or writing to a go removable, non-volatile optical disk such as a CD, DVD, or other optical media. The hard disk drive 548 and the CD disk drive 510 are each connected to the system bus 522 by one or more data interfaces 546.
[85] Any type of program information can be stored on the hard disk 548, optical disk 510, ROM 522, and/or RAM 540, including an operating system, one or more application programs, and application data.
[86] Input devices such as a keyboard 562 and a mouse 562 are connected to the computer 520. These and other devices such as printer, scanner, are connected to the processing unit 524 via the I/O controller hub 544 coupled to the system bus 522, but may also be connected by other interface and bus structures, such as a parallel port, serial port, or a universal serial bus (USB).
[87] A monitor console 512 can also be connected to the system bus 522 via an interface, such as a video adapter 528.
[88] The service balancer server computer 142 is connected to a data centre in a 100 Mbps or gigabit ethernet LAN networking environment. The data centre LAN which hosts the web application environment as shown Fig. 1 also connects the other servers such as the web server (132), forms server (134), database server (136), EAI Server (138), application Server (140), and directory Server (142). It should be noted that the illustrated networking connections are exemplary in nature and other means of connecting the servers can be established.
[89] Possible areas of deployment of Service Balancer
[90] Though the concept of Service Balancer has been evolved to meet the specific needs of a G2B portal, the principle behind it is sufficiently generic to enable its deployment in a wide variety of application architectures, such as: G2B and G2C portals that aim to provide integrated and joined-up services through a single window; electronic public procurement that seeks to serve the needs of a wide variety of procurement agencies and suppliers; B2B portals that intend to assume the shape of an extended enterprise, integrating with the IT environments of the buyers and suppliers; and enterprise portals of multi-location businesses with large number of legacy applications.

We Claim:
1) A n-tier system for balancing of services between the providers and users comprising of
- Web applications 130
- A generic server computing device 520,
- Presentation layer, Presentation Logic layer, Business Logic layer, Data Access layer and Database layer
- - Service Profiles 414 contain information adequate to enable the portal to access or invoke the different layers in the application architecture
- The Service Profile Configuration Module 402 for the
configuration of the service profiles. -The Controller Module 404 for defining and following the steps in servicing a request. - The Orchestration Module 406 for orchestrating flow- based transactions
-The Service Fulfilment Module 412 for identifying the sources of the above said layers in compliance with the service request . -The Application Modules 410 wherein the system orchestrates the flow of application logic depending on the nature of the user request and the composition and sequence of the events required to fulfil the service request by means of an appropriate combination of the use (invocation) of Presentation layer, Presentation logic layer, Business Logic layer, Data Access layer and Database layer.
2. A n-tier System for balancing of services as claimed in claim-1 wherein the web applications (Fig-1) execute on various typical servers such as Web Server (132), Forms Server (134), Database Server (136), Enterprise Application Integration (EAI) Server (138), Application Server (140), and Directory Server (142).
3. A system as claimed in claim 1 wherein the generic Server computing device 520 (Fig-5) further comprises of system bus 522, at least two processing units 524, network and video adaptor cards 526 & 528, a memory controller hub 530, a hard disk controller card 532, memory modules such as DIMM 534, PCI slots 536, system memory 538 as herein described.
4. A n-tier System for balancing of services as claimed in claim 1 wherein the Service Profiles can be configured through a web client 432.
5 .A System for balancing of services as claimed in Claim 1 wherein the Service Fulfilment Module 412 is invoked by the orchestration module I
6. A n-tier System for balancing of services as claimed in Claim 1 wherein the Application Module 410 further comprise of Presentation Module 418, Presentation Logic Module 420, Business Logic Module 422, and Data Access Logic Module 424, (Fig-4).
7. A System as claimed in Claim 6 wherein the Applicatin Module 410 is programmable as generic components based on the service scenarios
8. A method for balancing of services between the providers and users comprising the steps of (Fig-3) -
- Accessing the service profiles associated with the requested services
- checking the maturity level of the service provider application providing the service,
- Based on the maturity level of the service provider application, the service balancing decision is made.
- Based on the service scenarios, the Service Balancer will provide the necessary presentation, presentation logic, business logic or database access logic modules required for fulfilment of the service requests.
9. A method for balancing of services as claims in Claim 8 wherein the Service Balancer seamlessly integrates with different service provider backend systems irrespective of their maturity levels.
10. A system for balancing of services as claimed in Claim 1 wherein the providers have atleast 3 variants namely, 'Application is Ready', 'Application Not Ready', and 'Non-uniform Business Logic'.
11. A system for balancing of services as claimed in Claim 1 and 10 wherein the Service Balancer has a granularity that is midway between that of the application server and a typical web service.
12. A system for balancing of services as claimed in Claim 1 wherein the Service Balancer combines centralized solutions with distributed solutions seamlessly and transparently.
13. A system for balancing of services as claimed in Claim 1 wherein the Presentation layer (tier) is an application component of the N-tier architecture, which is deployed on the front-end system or the end-user's machine for accepting the user requests, showing the results of the requests, and presenting the related information in a user-friendly manner.
14. A system for balancing of services as claimed in Claim 1 wherein the Presentation Logic layer converts the user requests accepted by the Presentation layer into a form that can be understood by the Business Logic layer and to transform the results obtained by the Business Logic layer into a form presentable to the user.
15. A system for balancing of services as claimed in Claim 1 wherein the Business Logic layer implements the business objects and rules associated with the services provided by the N-tier application.
16. A system for balancing of services as claimed in Claim 1 wherein the Data Access layer interfaces with the underlying data mechanisms such as a database or directory.
17. A system for balancing of services as claimed in Claim 3 wherein the controller module accepts requests from the web application server.
18. A systen for balancing of services between the providers and the users substantially as herein described with reference to the accompanying figures.
19. A method for balancing of services between the providers and the users substantially as herein described with reference to the accompanying figures.