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.
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.).