CAS Technology Upgrade

Das Kreditentscheidungssystem CAS (Credit Approval System) ist seit mittlerweile fast vier Jahren sehr erfolgreich im Kundeneinsatz.

CASThe credit decision system (CAS Credit Approval System) has been successfully used by customers for almost four years now. The technical and architectural foundations of the system were developed in the concept and planning phases on the basis of the technologies available five years ago. In the relatively fast evolving world of application server based web applications, that is a long time, during which the technical components used (JAVA EE2, JBOSS 4.3, JBOSS Portal 2.7, JSF 1.2, Hibernate, etc.) have to a degree significantly evolved. In addition, there have been a lot of experiences and insights as to how individual architectural features have been proven in practice, with regard to the factors of costs and benefits.

The ReDesign - The Inception of CAS NT


In the course of 2013 it was decided to develop CAS in a new version based on the current technology stacks. To this end experiences with the first version were analysed in order to derive better approaches that could be incorporated into development. Since the system is successfully in operation, the process and interface ought to change as little as possible for the user, to largely avoid conversion and training costs. Since with regard to technology stacks JBOSS technology package had proved itself the most, the current JBOSS package (7.2) was selected as a basis. There were some other important design changes, which will be explained in detail below.

How to do you implement an SOA most effectively?

A fundamental decision in designing the first version of CAS was to realize it as a service-oriented architecture (SOA). The application should react as flexibly as possible internally with the help of loosely coupled services that can be accessed either as a web service or as an EJB service.

CAS Portal

To this end an architecture was developed with a strong vertical parsing of the individual building blocks in accordance with technical considerations, such that in theory it corresponded with the ideal SOA approach. As a result, per technical function block there was a module that contained the entire technical code including interfaces, e.g. a security module, a calculation module, etc. A seamless integration had to be produced out of this, such that from this collection of services a user would be provided with an easy to use and consistent application.

It has been shown in the analysis that this ideal SOA architecture approach does work, and the application is therefore technically extremely flexible, but this flexibility is not used at all in many areas. In addition, an extreme decoupling brings true benefits such as separate deployment and release management of the individual technical components, but this is paid for with performance drawbacks (for example a very common serialization of objects between blocks) as well as significant redundancy of code components.

Additionally, as part of the imaging process (the credit decision), the coupling between the individual components is so close that a separate application is not useful anyway, and separate deployment thus provides no advantages. To resolve this dilemma, the basic concept of an SOA application has been maintained and functions will still be used in coupled services. However, individual modules will only be provided and engaged with the necessary flexible interchangeability, when a specific instance of application is in use by various customers. An example of the need for such a flexible module is with customer master data administration, which looks different for each CAS customer and therefore must be coupled with the appropriate adapter. And in the design of SOA applications, it is thus extremely important to carefully weigh the balance between the costs and disadvantages of a strict SOA concept, and a concept in terms of "SOA where it is actually useful and is being used". Extreme flexibility always takes effort and therefore costs money, and hence cannot be an end in itself, but must rather provide added value in terms of reusability and especially lower TCO.

Portal vs. Web Application

Another important decision had to be made with regard to the implementation and integration of the interface. JSF as a means of programming the individual portlets (or pages, as the case may be) of each function, was out of the question. In the first version of the CAS, JBOSS portal was used as an interface coupling and central control component. In the case of changing this component to the new JBoss GateIn portal, the question would have to be asked as to how we could further proceed within CAS. An analysis also showed that we have used only about 20% of the actual portal functions, key functions such as user-specific portal configuration are not required in an application such as CAS, or even contradict a consistent user interface, thus possibly endangering support capacity. 

CAS Agora

That is why we decided to transfer the amount of portlets into a closed web application in JSF 2.1. This change allows for much better control and maintainability of the interface, as it is no longer dependent on an underlying portal component. The functions that were used in the portal such as single sign-on or a consistent design, are made available either centrally by the JBOSS Application Server, or we developed and optimized the corresponding functions in our own code. The "user experience" is better and the program code used is also leaner and more efficient.

JSF2 facilitates the implementation of particular surface components through its composite components. Within individually isolated deployments, components together with interfaces can be made seamlessly available to other applications. As such the central advantage of reusability is still present: a function used in various places, such as the client search, is still developed only once, but used in many places within the CAS, as well as in other Internet applications of this architecture.

In order not to lose the portal idea of a process portal, there is a central AGORA component to which all web applications that have been developed in this framework are logged, and which form the single access point for the user. 

In terms of the SOA architecture, this component serves as a central service for all applications (data regarding the logged in user, statistics and management components, etc.).

Contact: Olaf Port; Turn on Javascript!