Patent Application
20090313599
The invention relates generally to handling cross-cutting concerns at business level while developing enterprise business application, and more particularly to creating context aware enterprise business applications through managed variations.
A common requirement while developing enterprise applications is to support variations in the behavior of the applications based on factors like customer segment, delivery channel, user location, line of business (LOB) where the application is deployed etc.
For example in the insurance domain, the insurance calculations usually vary based on the state, country etc and similarly the steps in business processes like the insurance application processing, claims processing etc are typically different for different lines of business like for say property insurance, auto insurance etc. Similarly the interface applications and their behavior are different for different marketing channels like self service, assisted, retail, wholesale, partner etc. Until a few years ago, these requirements used to be addressed by developing separate applications in silos for the different LOBs, marketing channels, locations etc.
Traditional strategies for addressing these requirements have been to develop multiple applications/systems for different LOBs, Marketing Channels, Geographies etc. The problem with this approach is that it results in creation of silos of applications/systems with the impact that there is no seamless flow of information across the enterprise. This strategy also results in duplication of the applications and business processes resulting in inconsistencies and thus bad end user experience. This strategy also results in rigid IT systems resulting in high Time to Market and so lost business opportunities.
Other alternative is to develop one application that addresses the requirements of all contexts applying techniques like SOA, Object Orientation etc. The limitation of this approach is that the variations for the various contexts are interspersed across various locations of the application implementation resulting in spaghetti of variations. This makes the application fragile and also makes it hard to analyze what has been varied for a context to make any further variations as needed.
Presently Aspect Orientation techniques have been applied at programming level through AOP (Aspect Oriented Programming) and frameworks like AspectJ. Existing AOP techniques and frameworks like AspectJ are designed for handling cross cutting concerns at object level like enabling extra processing before and after a method execution by providing mechanisms (called PointCuts) like Before & After Method PointCuts. The problem with this is, these PointCuts are too fine grained and can't be used to express cross cutting concerns that make sense at business level.
The industry is moving towards a Service Oriented Architecture (SOA) to address these problems. So, instead of creating monolithic silos of applications, enterprises are increasingly looking at developing the required IT capabilities as Services that are then composed to create the required applications for the different LOBs, Channels, and Geographies etc.
Services are used in multiple business contexts like in different LOBs, different marketing channels and across multiple geographies. So, there is a need for variations to enable them to operate in these different contexts. One of the limitations with the current SOA strategies of several enterprises is that they lack a well defined solution for managing these variations. The variations are interspersed so much that they quickly become unmanageable.
Thus there was a need for better strategy to look at these requirements for variations based on usage context like LOBs, Channels, and Geographies etc as cross cutting business concerns and accordingly define strategies for architecting enterprise applications with well defined mechanisms for handling the variations for these concerns. In the non technical terms—“The IT architecture strategy should enable creating multiple Operating Contexts for the enterprise through managed variations”.
In one embodiment of the present technique, a method for handling multi business concern or cross-cutting concerns at a business level while developing enterprise application is disclosed. The inventive method identifies the various variation points and variations at the various architectural layers of a typical business application. The method also identifies the decision parameter that determines the usage context and accordingly the variations needed for the cross-cutting or multi business concern.
The inventive method identifies the common variation requirements for the common cross-cutting business concerns, then identifies the architecture strategies to enable such variations and then, based on those strategies define an architecture with well defined variation points and finally defines mechanisms for bundling such variations as a group to enable better management. The method also defines the mechanisms for associating the variation bundles to the usage contexts that will enable contextualizing the enterprise application characteristics to different operating contexts. The method also defines the mechanisms for determination and propagation of context across the various architectural layers of the enterprise application implicitly and injecting the variations based on the context and the configuration of the variation bundles to the contexts.
In another embodiment of the present technique, it is described how to take this inventive method to execution level by explaining how to develop a business aspects framework. The method enables developing context aware business enterprise applications.
These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
The following description is full and informative description of the best method and system presently contemplated for carrying out the present invention which is known to the inventors at the time of filing the patent application. Of course, many modifications and adaptations will be apparent to those skilled in the relevant arts in view of the following description in view of the accompanying drawings and the appended claims. While the system and method described herein are provided with a certain degree of specificity, the present technique may be implemented with either greater or lesser specificity, depending on the needs of the user. Further, some of the features of the present technique may be used to advantage without the corresponding use of other features described in the following paragraphs. As such, the present description should be considered as merely illustrative of the principles of the present technique and not in limitation thereof, since the present technique is defined solely by the claims.
As a preliminary matter, the definition of the term “or” for the purpose of the following discussion and the appended claims is intended to be an inclusive “or” That is, the term “or” is not intended to differentiate between two mutually exclusive alternatives. Rather, the term “or” when employed as a conjunction between two elements is defined as including one element by itself, the other element itself, and combinations and permutations of the elements. For example, a discussion or recitation employing the terminology “A” or “B” includes: “A” by itself, “B” by itself and any combination thereof, such as “AB” and/or “BA.” It is worth noting that the present discussion relates to exemplary embodiments, and the appended claims should not be limited to the embodiments discussed herein.
The present invention relates generally to handling cross-cutting concerns at business level while developing enterprise business application, and more particularly to creating context aware enterprise business applications through managed variations.
In one embodiment of the present technique, an inventive method is described for taking care of cross-cutting concerns that make sense at the business level while developing enterprise business applications through “Business Aspects”. It is also described how “business aspects” can be developed for applying cross-cutting business concerns using the Infosys Proprietary RADIEN Framework. And the method also enables creating context aware enterprise business applications through managed variations. Thus what is proposed—is a solution for creating coarse-grained aspects that will make sense at business level—which is called “Business Aspects” solution.
Following is the terminology which is used to describe the inventive method and explained the “Business Aspects” solutions.
“Context” can be defined as the combination of factors that sets the business operating and usage environment for a business application in an enterprise. It is defined in terms of parameters that influence business decisions, like Line of Business (LOB) in which the business application is being used, Geographical location of the organization providing the business service, the marketing channel (retail, wholesale, self-service etc) through which the business service is being provided, the delivery channel through which the service is being provided (internet, intranet, mobile etc) etc and external user factors like the user role (UI and access to functionality is sometimes dependent on the user role), the user geographical location, the time at which the service is used etc.
“Cross-Cutting Business Concern” can be defined as a business requirement that would need considerations across multiple architectural layers of a business application to address the requirement. Like for example: For a business application to operate in a self-service retail environment, there would be user layer (UI) considerations( like what functionality is accessible and what is not), business logic layer considerations ( like a wholesaler may get discounts that may not be applicable to retail marketing channel), the business process steps followed for a request coming from a teller in an e-banking application may be different from those coming from a user using internet self-service channel, integration layer considerations like the back-ends systems to integrate may be different and similarly persistence layer considerations may also be different.
“Variation” can be defined as a well defined architectural component that can be modified and applied to alter the behavior of an enterprise business application.
“Variation Point” is a well defined plug-in point in the architecture for the variation to be plugged in.
“Variation Bundle” can be defined as a mechanism provided to group a related set of variations within an architectural layer.
“Business Aspects” can be defined as a mechanism provided to group a set of related variation bundles across multiple architectural layers to address a cross-cutting business concern
The proposed inventive method Business Aspects Solution identifies the various variation points, variations at the various architectural layers of a typical enterprise business application. It also defines the mechanisms for bundling each of these variations as a group to enable better management.
To map to AOP terminology, the “Variation Points” are similar to PointCuts but the key difference is that Variation Points are much more coarse-grained that what are defined as PointCuts in AOP, similarly Variations are similar to Advice and “Variation Bundles” are similar to Join-Points and “Business Aspects” are similar to Aspects.
The inventive method identifies the common variation requirements for the common cross-cutting business concerns, and then identifies the architecture strategies to enable such variation and then, based on those strategies define architecture with well defined variation points and finally define mechanisms for bundling such variations.
In one embodiment of the present invention, it is described how to take this method to execution level by explaining how to develop a business aspects framework solution. And what is proposed is a solution for creating coarse-grained aspects that will make sense at business level—“Business Aspects” Solution.
The “Business Aspects” solution solves the problem by applying Aspect Orientation techniques at Architecture level. The proposed solution looks at the variations needed at the various characteristics of an enterprise application as cross cutting architectural concerns that cut across the various architectural layers and then applies Aspect Orientation techniques at Architecture level.
“Business Aspects” solution defines how to create Business Aspects for addressing cross-cutting architectural concerns. The proposed solution explains the design of various mechanisms needed to enable changes in application characteristics in different contexts including:
mechanisms for capturing the various decision parameters that influence changes in application characteristics through a “Context” component
the various Architectural “Variation Points” needed
the different Architectural “Variation” mechanisms
the “Architectural Variation bundling” mechanisms
mechanisms to associate different variation bundles to different contexts
and mechanisms to resolve and inject the variations based on currently active context
Following is the description of how “business aspects” can be developed for applying cross-cutting business concerns and how this inventive method enables creating context aware enterprise business applications through managed variations.
Referring to
Referring to
In
In
Referring to
In
To understand the proposed method, consider the following example.
Scenario: Customize how say “limits check” functionality is implemented in calculating transaction limits for financial transactions in an e-banking scenario based on the operating context (limits are different if the channel is self-service vs say through assisted channels like through teller)
Considerations & Pain Points: Monolithic service implementations make it difficult to modify specific request handling
Architecture Strategy: Design the Service implementations to use pluggable request handlers and design a mechanism that will plug in different request handlers based on the currently active context.
In another embodiment of the present invention, how different layers in architecture of an enterprise application framework will be designed based on the above examples is discussed here.
Business Logic Layer:
Referring to
The recommended logical architecture for the business logic tier based on the strategies listed is shown in
Architecture Strategies for Business Logic Layer:
Interface driven business services 130
Pluggable service request handlers 120
OO Domain Layer 140
BPEL 100 for macro process flows
XML driven request handler chaining for micro flows
Workflow engine 110 for process flows with human interaction
Variation Points and Variation Bundles for Business Logic Layer:
The Variation Points and the Variations mechanisms and the mechanisms for bundling the variations to create a business aspect for the business tier are shown below in a
User Interface Layer:
The recommended logical architecture for the UI Layer with the variation points and the mechanisms for bundling the variations together as a business aspect are shown in
The Table 3 below has the list of common scenarios and the architecture strategies for the User Interface Layer in an enterprise application.
The recommended logical architecture for the UI layer based on the strategies listed is shown below and also in
Architecture Strategies for UI Layer:
MVC with pluggable view layer
Configurable screen flow
Pluggable input validations 210
Resource bundles for display text
Pluggable UI request handlers 200
Variation Points and Variation Bundles for UI Layer:
The Variation Points and the Variations mechanisms and the mechanisms for bundling the variations to create a business aspect for the business tier are shown below in Table 4.
Integration Layer:
The recommended logical architecture for the Integration Layer with the variation points and the mechanisms for bundling the variations together as a business aspect are shown below and in
The Table 5 below has the list of common scenarios and the architecture strategies for the integration layer in an enterprise application.
The recommended logical architecture for the Integration layer based on the strategies listed is shown below and in
Architecture Strategies for Integration Layer:
Configurable message definition 300 and message mapping 310
Configurable message routing and transformation 330
Configurable communication protocols with pluggable adaptors 350
Variation Points and Variation Bundles for Integration Layer:
The Variation Points and the Variations mechanisms and the mechanisms for bundling the variations to create a business aspect for the integration layer are shown below in Table 6.
Data Layer:
The recommended logical architecture for the Data Layer with the variation points and the mechanisms for bundling the variations together as a business aspect are shown below and also in
The Table 7 below has the list of common scenarios and the architecture strategies for the Data Layer in an enterprise application.
The recommended logical architecture for the Data layer based on the strategies listed is shown below and also in
Architecture Strategies for Data Layer:
Interface driven DAOs 400
Configurable Data Storage Mechanism 410
Configurable mapping between Objects and storage representations 420
Externalized and configurable queries
Extensible Entity objects 430
Variation Points and Variation Bundles for Data Layer:
The Variation Points and the Variations mechanisms and the mechanisms for bundling the variations to create a business aspect for the data layer are shown below in Table 8.
Proposed Solution Execution:
Following is the description of how “business aspects” can be developed for applying cross-cutting business concerns using the Infosys RADIEN Framework. And it also explains how this solution which is based on inventive method enables creating context aware enterprise business applications through managed variations.
In one embodiment, the variations problem and the design solution to address the problem have been described. The next step is to develop a framework that enables defining and implementing business aspects through managed variations.
In another embodiment, the various variation points along with the variation mechanisms and variation bundling mechanisms required at the various tiers have been identified. Implementing this would require an application framework with the variation points. The implementation framework for the business aspects in J2EE is the RADIEN Framework that has been designed and developed incorporating all these variation points.
The implementation specifics for some of the key variation points in RADIEN are described below. RADIEN Framework consists of several sub-frameworks for the various tiers and they are designed to incorporate the variations points of the corresponding layer.
Business Logic Layer:
The various variation points of the Business logic layer along with the variation mechanism and the variation bundling mechanisms are described below.
Service Implementation Variation:
RADIEN services framework provides the components for lookup and use service instances and is the core to plugging in variations based on context. It is interface driven and allows different service implementations to be plugged in.
The UML model in
Let's take a scenario where a Business Service named say PaymentService needs to be developed. The following steps describe how to define, develop, configure and use the service through the RADIEN services framework and how to plug-in variations through different service implementation based on context and how to group/bundle such variations for a given context.
Step 1: A functional interface is defined for the service 510 as say
Step 2: A management interface 520 is defined for the service as say
Step 3: The service functional and management interfaces are implemented and the service instance is configured with a logical service name in RADIENServiceConfig.xml 530 as shown below.
For a simple Java POJO implementation 540 it's configured as shown below.
To plug-in variations of the service implementations 540 by changing the ClassName parameter which is used to specify the implementation class.
There is a similar configuration mechanism for an EJB/WebService 550 based implementations with capabilities to vary implementations.
The usage code as shown below is tied only to the logical name of the service and the functional interface and so allows different implementations to be plugged in.
The RADIEN Service Config XML 530 thus provides a variation point to plug in different service implementations based on context. The service locator 560 provides an appropriate service implementation 540 instance for a given logical name based on context. The RADIEN Service Config XML 530 also provides the variation bundling mechanism to group the service implementations 540 related to a context. Like for example all service implementation 540 instances for a particular context say an LOB can be defined in one RADIEN Service Config XML 530 and those for another LOB in another RADIEN Service Config XML 530 and so on.
Service Request Handler Variation:
Another variation mechanism is service request handler mechanism. A common requirement is to vary how a service request is handled based on context for some requests while the request handling logic for most other requests is same across different contexts. Service implementation variations mechanism described above can be used for this but that could result in duplication of the logic across the different implementations. A better solution is to provide pluggable service request handlers and then enable different request handlers to be plugged in based on context.
To address these requirements, a service in implemented in terms of service requests and service request handlers with a service controller having a map of requests to handlers.
The UML model in
Referring to
Referring to
Object Inheritance Variation:
Another variation mechanism available is Object inheritance mechanism.
As shown in the UML model in
RADIEN leverages Spring for the OO (Domain Model) Layer implementation. The objects are configured with a logical name as beans and the dependencies among the objects are defined in the spring configuration XML as shown below.
This allows the domain model 710 objects to be sub classed for any context specific variations and to be plugged in by modifying this XML This spring configuration XML thus helps to bundle the variations based on object inheritance.
Workflow, Business Process and Rule Variation:
Variation mechanism for Business processes, Workflows and Business Rules are explained below.
The business processes which are service orchestration based are modeled using a COTS BPEL engine like OracleBPEL engine or IBM BPWS4J engine etc and these engines are leveraged to define multiple processes for multiple contexts. Similarly, business processes involving human interactions with manual and automated steps are modeled using a COTS Workflow engine like Staffware engine or JBPM engine etc and these engines are leveraged to define multiple workflows for multiple contexts. Business reules are externalized using COTS Rule engines like Drools, ILOG JRules etc. This enables varying the rules for different contexts. A layer of indirection is provided over these BPEL, Workflow and Rule engines through adaptors which provide a mapping of logical workflow IDs to the actual workflow IDs, logical BPEL process ID to actual BPEL process ID and similarly logical RuleSet IDs to actual RuleSet IDs. These adaptors are XML configuration driven which provides the mechanism for bundling the Workflow/BPEL Process/Rule variations related to a context. The Table 9 below provides the summary of the various Business Logic layer variations in RADIEN.
User Interface (UI) Layer:
RADIEN framework offers multiple implementation choices for the presentation tier. The default implementation choice for UI is based on Apache Struts framework. The various variation points of the UI layer based on the default framework along with the variation mechanism and the variation bundling mechanisms are described below.
View Layer Variations:
The UI Layer Views (in the MVC) are defined using a component based framework like tiles. The views are defined as a composition of reusable UI components using a templating mechanism as shown below. This enables the UI components to be customized based on context and also to change the composition of the components in a view based on context and thus provides variation mechanisms in the view layer. The View definitions are defined using an XML (like TilesDefintion.XML) which helps bundle the view layer variations belonging to a context.
UI Request Processing Layer Variations:
The UI request processing is performed through a central controller with pluggable UI request handlers. For struts based implementation, the request handlers are Struts Action classes and the controller is the Struts Controller Servlet. UI Request to handler mapping is configurable and for Struts based implementation, the request to handler mapping and the routing to appropriate views based on the result of the request handling is configured in StrutsConfig xml as shown below. This enables plugging different request handlers for different contexts and the struts config xml provides the mechanism for bundling related handlers.
UI Input Data Validation Variations:
UI input validation is another common place for variations based on context. To enable easy plugging in of different validations, RADIEN leverages the apache commons validation framework. The validations XML provide the mechanism for defining the validations and for grouping the validations. For struts based implementations, the validation rules are plugged in through the plug-in configuration in Struts Config XML as shown below.
UI Display Data Variations:
Another common variation point in the UI layer is the messages displayed to the user in the views. To enable variation of the messages displayed in the views based on context, the messages are externalized from the views and are plugged in through ResourceBundle mechanisms. For struts based implementations, the message resource configuration in the Struts Config XML is used to plugin the resource bundles corresponding to a context as shown below. The resource bundle property file provides the mechanism for bundling the message variations of a context.
<message-resources parameter=“con.infosyssetlbank.ApplicationResources”/>
The Table 10 below provides the summary of the various User Interface (UI) layer variations in RADIEN
Integration Layer:
Message Variations:
Another variation mechanism available in the integration layer is the Message variation which is explained below.
A common requirement for variations in the integration layer is in the structure of the messages used to communicate with the external system.
RADIEN provides a XML configuration driven mechanism for message definition along with the mapping of the internal object structures to the external message structures similar to the entity object to table mapping described earlier. This XML enables defining the variations and also in bundling the related variations based on context.
Message Routing Variations:
Another common requirement for variations in the integration layer is in the routing of the messages to different external systems based on context.
RADIEN integration framework includes a message broker which routes messages to different systems based on a XML configuration. This XML enables Message Routing Variations to be defined and also to bundle related routing variations.
Transport/Communication Variations:
Another common requirement for variations in the integration layer is in the transport/communication mechanism used in interfacing with external systems based on context.
RADIEN integration framework includes an interface driven transport layer that allows different transport implementations to be plugged in based on a XML configuration. This XML enables Transport Variations to be defined and also to bundle related transport variations.
The Table 11 below provides the summary of the various Integration layer variations in RADIEN.
Data Layer:
Persistence Logic & Storage Mechanism Variations:
The first variation mechanism available in the data layer is the persistence logic implementation variation which is explained below.
RADIEN framework provides a persistence framework with a configuration driven mechanism that enables different persistence implementations to be plugged in.
With RADIEN, the persistence logic is implemented using DAO (Data Access Object) design pattern and is interface driven. The usage code is in terms of the DAO interface and the implementations are looked up using a logical name as shown below. This enables different implementations of the persistence logic implementations sticking to the DAO interface to be plugged in easily through configuration changes.
A DAO Config XML configuration driven mechanism is used to enable plugging in different DAO implementations as shown below with a mapping of the DAO logical name to the implementation details. This DAO Config XML provides the mechanism for bundling the persistence logic implementation based variations for a context.
Query Variations:
Another variation mechanism available in the data layer is the query variation which is explained below.
Persistence logic for a request especially for a RDBMS datastore usually involves the following 3 steps:
1) Create a Query
2) Update query with values from the input request objects
3) Execute query and create response objects from the ResultSet
To enable easy variation of persistence logic for a particular request, RADIEN persistence framework provides a XML driven configuration mechanism that enables defining the Query to be used, then mapping of request object fields to place holders in the query and finally mapping of the resultset values to response objects as shown below. This provides a mechanism to vary the query or the input request object structure or the output response object structure through changes to this XML and this XML also enables bundling related variations for a context.
Entity/DTO Variations:
Another variation mechanism available in the data layer is the Entity Object variation which is explained below.
A common requirement for variations in the data layer pertain to the structure of the entity objects and the data transfer objects (input/outputs to the data layer) in terms of need for more fields to an entity or other such changes. These changes result in further changes in the mapping of the entity fields to the transfer objects and the mapping to the underlying data store structures like say tables in case of RDBMS data stores.
RADIEN provides the following variation points for these:
Extensible Entity/DTOs based on Map data structures
XML driven Object to Object mapping mechanism
Query mapping mechanism explained above for entity object fields to table columns
The Table 12 below provides the summary of the various Data layer variations in RADIEN.
The proposed solution can be applied to create context aware business applications. This solution can be applied for creating context aware enterprise business services as well as context aware enterprise business processes. The behavior of the services or processes or entire business application can be varied based on context through the variations that are plugged in at static pre-compilation stage or at runtime. These variations can be managed effectively through the variation bundling mechanisms. This enables creating shared services and processes across multiple Lines of Business (LOBs), organizations, regions within an enterprise. Like for example, this solution can be leveraged to create an enterprise shared business service for say insurance premium calculation that can be used in multiple context like different LOBs like property, auto etc and also across multiple regions like different states or countries etc. Since the variations are plugged in, it enables true sharing of the commonalities across the multiple LOBs, regions in the shared service through a common skeleton and externalized variations.
Thus, the problem with unmanaged variations and the proposed solution to address the challenges down to the implementation details are described and discussed. This solution enables creating context aware services and applications with managed variations defined as business aspects. This solution can be further enhanced to handle more architectural styles.
Exemplary Computing Environment
One or more of the above-described techniques may be implemented in or involve one or more computer systems.
With reference to
A computing environment may have additional features. For example, the computing environment 900 includes storage 940, one or more input devices 950, one or more output devices 960, and one or more communication connections 970. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 900. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment 900, and coordinates activities of the components of the computing environment 900.
The storage 940 may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which may be used to store information and which may be accessed within the computing environment 900. In some embodiments, the storage 940 stores instructions for the software 980.
The input device(s) 950 may be a touch input device such as a keyboard, mouse, pen, trackball, touch screen, or game controller, a voice input device, a scanning device, a digital camera, or another device that provides input to the computing environment 900. The output device(s) 960 may be a display, printer, speaker, or another device that provides output from the computing environment 900.
The communication connection(s) 970 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video information, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.
Implementations may be described in the general context of computer-readable media. Computer-readable media are any available media that may be accessed within a computing environment. By way of example, and not limitation, within the computing environment 900, computer-readable media include memory 920, storage 940, communication media, and combinations of any of the above.
Having described and illustrated the principles of our invention with reference to described embodiments, it will be recognized that the described embodiments may be modified in arrangement and detail without departing from such principles. It should be understood that the programs, processes, or methods described herein are not related or limited to any particular type of computing environment, unless indicated otherwise. Various types of general purpose or specialized computing environments may be used with or perform operations in accordance with the teachings described herein. Elements of the described embodiments shown in software may be implemented in hardware and vice versa.
In view of the many possible embodiments to which the principles of our invention may be applied, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.
While the present invention has been related in terms of the foregoing embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments depicted. The present invention may be practiced with modification and alteration within the spirit and scope of the appended claims. Thus, the description is to be regarded as illustrative instead of restrictive on the present invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 52/CHE/2008 | Jan 2008 | IN | national |
