Service Communautaire d'Information sur la Recherche et le Développement - CORDIS

LAURA system architecture

The architecture of the LAURA solution must cope with the specific business issues while also satisfying a set of requirements, dictated by the RBVO model itself, the application domain and the basic software engineering principles.

One of the possible ways to model an RBVO is to consider it as composed of a collection of interacting services; this approach fits the "request on demand" concept, which is pivotal to the RBVO. Each service provides access to a well-defined collection of functionality. The system as a whole is designed and implemented as a set of interactions among these services.

Exposing functionality as services is the key to flexibility. This allows other pieces of functionality (perhaps themselves implemented as services) to make use of other services in a natural way regardless of their physical location. A system evolves through the addition of new services. The resulting service-oriented architecture (SOA) defines the services of which the system is composed, describes the interactions that occur among the services to realize certain behaviour, and maps the services into one or more implementations in specific technologies. This service-oriented architecture (SOA) approach is the latest in a long series of attempts in software engineering that try to foster the reuse of software components.

However, the notion of Services, together with the necessary provision of discovery, binding, invocation modes, etc. make answer only a part of the questions. The discussed application domain is primarily associated with the business processes occurring between the business partners; therefore the solution architecture must explicitly reflect this aspect and take a business process management approach to integration. Emerging e-business models are becoming more ambitious and the ability to support a rapidly changing business environment is obligatory. Companies want to automate and manage complete business processes, not just specific steps of a business process, therefore the services need to be business-oriented. The tools and techniques of the modelling layer aim to graphically represent interaction flows among participants in a process and to abstract the models from the underlying technologies. The resulting business process models can be used later by the integration engines, transformed into the appropriate specific formats and enacted at business run-time.

In addition, the architecture must support the emerging notion of e-business frameworks, which specify the coordinated the use of low-level standards and technologies. The aspect of standardisation at every level is very important here, as the architecture must facilitate integration software interoperability, platform independence and portability in order to ensure the widest possible adoption.

The two main alternatives for the Internet-ready e-business based on widely adopted standards today are:
- Electronic Business XML (ebXML) integration framework sponsored by OASIS (Organization for the Advancement of Structured Information Standards) and UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) and supported by other influential standards bodies including NIST (National Institute of Standards and Technology) and W3C (World Wide Web Consortium) as well as the major industry players.
- Advanced Web Services Architectures. Building on the success of Web Services for Internet-based platform-neutral application integration, the major industry players (IBM, Microsoft, BEA and others) attempt to make Web services more secure, more reliable, and better able to support transactions while retaining the essential simplicity and interoperability found in Web services today.
The two approaches are different in certain aspects. The ebXML framework, for example, is engineered using top-down business process and a collaboration centric approach, while Web Services grow from the low-level integration techniques into the business process area as required. The two frameworks also overlap in certain areas in terms of functionality and efforts are made to reuse as much effort as possible to minimize the overlap. There are also some core technical elements shared by both frameworks (such as XML, SOAP, etc.), which increase the degree of interoperability.
While not mutually exclusive, these two approaches are substantially different to the extent that it requires making a choice quite early on when defining the solution architecture.

In our project and research work we have chosen the ebXML framework as the primary architectural basis because of its completeness of vision and business collaboration orientation on one hand and the opportunity to start from scratch with our architecture on the other hand.

Reported by

Kingston University - School of Computing & Information Systems
Kingston University - School of Computing & Information Systems
KT1 2EE Kingston-Upon-Thames
United Kingdom