Service-Oriented Architecture

SOA for optimal integration and interoperability

With an SOA, Linedata makes it possible for the different modules of its offer to communicate together (Front-, Middle- and Back Office) as well as with any other module required for the architecture of the clients’ information system.

To do this, Linedata deploys a comprehensive set of business services through a “ServiceMix” application bus that can support all types of messages (XML, Web Services, API etc.) in synchronous or asynchronous mode. This type of architecture provides flexibility and responsiveness to clients.

When Information Systems support Sales Strategies

The Benefits of a Service-Oriented Architecture for the Lending, Leasing and Asset Finance industry

Numerous applications are connected together within the information systems architectures currently used by finance institutions: these applications are for day-to-day contract management, accounting, risk management and reporting, third party database management etc. and all interact with each other using specific interfaces. In traditional enterprise architecture, applications interact with each other in pairs.

The limitations of this approach relate to the number of interfaces to be developed while the number of systems increases. Upgrading these applications is therefore a difficult task: they must be synchronised simultaneously and they add significant testing costs as well as major operational risks. Modifying one of the applications might involve modifying interfaces, and, in some cases, modifying one or more partner systems.

These restrictions, which are due to the IS architecture, build up inertia and are a major obstacle for the Sales and Marketing departments, which have to wait until the new software versions are finally deployed. In a market environment where laws and regulations are subject to frequent changes and competition is fierce, this type of architecture is a deterrent to competition and product innovation. This is why more and more IT directors are now turning towards a Service-Oriented Architecture (SOA), in which the Enterprise Service Bus (ESB) is the core messaging backbone

Message-oriented middleware

With the Service Bus, all software applications in the Information System no longer communicate directly with each other, but via a standardised and shared communication service. This means that information is collected, transferred and published by the Service Bus, whose task is to forward it to the relevant applications.

Used as a central communication channel, the Service Bus provides a directory service for finding all the information you need. Many value-added services are offered:

  • If one of the systems is unavailable, the Service Bus will try and find information in other back-up systems.
  • If the information you are looking for is stored in different applications, the Service Bus will find and aggregate the data in a transparent way for the end user.

Once the information has been found, it needs “translating”. The same information can have very different names depending on the application used. Translation will be based on a glossary that stores repositories’ translations for all in-use applications.

What are the advantages of the ESB?

Applications can be updated independently through the Service Bus without impacting others: this means that the application glossary (Metadata manager/WSDL) is updated in the Service Bus. In addition, implementing services and new work methods will help to better define and structure processes, which will also ensure sustainability.

It is important to consider:

  • how the application will interact with other applications
  • how to differentiate, from project conception, which data is public and which remains private
  • determine what is in or out of the application scope

Services Buses undeniably bring greater flexibility and responsiveness to data, but they also bring additional security. When upgrading versions, live deployments can be spread over time and might involve only a portion of the portfolio: it then becomes possible to have several versions of the same Front Office application working in parallel. These are different versions of the same software package that are deployed at the desired pace.