Dimitra Pappa and Lampros K. Stergioulas
2 SERVICE-ORIENTED VS. COMPONENT-BASED ARCHITECTURES
Corporate needs call for information systems that aggregate and add value to disparate resources.
As a result, the design process needs to take into consideration multiple viewpoints: the technology
stack (or physical) view, the object (or data) model, and the use case (or behavioural) view (Albin,
2003). In order to support the seamless delivery of value-added services to their intended customers,
the joining-up of IS goes beyond the mere technical linking of disparate corporate applications and/or
networks to include the sharing of information, the establishment of joint workflows and the re-
organisation of administrative operations within the involved functional areas. Yet, while in a
component-based design, components are created to closely match business entities, service-oriented
design features services that go beyond administrative segmentations within the organisation (cross-
border services).
The need for integration translates into new requirements on related software applications and
their integration, including the incorporation of existing legacy applications and commercial off-the-
shelf products in the formation of new business processes. Overall, there are three critical aspects in
system integration (Albin, 2003; European Commission, 2003):
technical interoperability, which is concerned with the technical issues of linking up IS, the
definition of open interfaces and telecommunications;
semantic and functional interoperability, which is concerned with the content of the exchange
(e.g. ensuring that the precise meaning of exchanged data is understandable by any other
application in the system even if not initially developed for this specific purpose) and with the
challenge of functionally integrating different software modules into one comprehensive
system that meets the user needs.
organisational interoperability, which is concerned with adapting the corporate environment to
this new integrated model of work.
2.1 Technical interoperability: software integration
Primarily applications need to be interoperable, in order to provide complete, transparent and real-
time access to data and information and to allow for their seamless exchange and processing across IS
and/or functional areas.
The use of proprietary technologies can lead to the creation of information silos within
departmental borders, which in turn can obstruct the seamless exchange of data. During the early years
of systems development, integration was regarded as a mere technical issue, a ―manual‖ process of
developing point-to-point interfaces between applications (Al Mosawi, Zhao, & Macaulay, 2006).
Direct linkage has several limitations (Gulledge, 2006) as it tends to connect components in a
customised way, via proprietary application programming interfaces (APIs), which were particularly
effort-demanding to build, maintain and/or extend. It results to components being typically tightly-
coupled with changes in one requiring changes in other components as well. In this context, change is
difficult and component replacement an often practically impossible total process. Additionally, the
number of interfaces grows exponentially related to the number of interconnected components.
Similarly middleware software can provide broker services between the different information
resources involved, using the message bus paradigm (Hohpe & Woolf, 2003). Middleware integration
is therefore an advanced form of interfacing, which uses a spoke-and-hub architecture instead of point-
to-point links to add an intermediary communication layer between interoperating units.
While efforts were being made in the direction of better systems integration, the idea of Enterprise
Resource Planning systems (ERP) emerged, as a way to overcome the problems created by application
segmentation. The objective was to develop organisation-wide ERP systems, which would integrate all
data and processes of an organisation into a unified system and realise concrete financial and
operational competitive advantages. Integration and interoperability would be guaranteed within these
―all-encompassing‖ packaged applications. Yet, in reality ERP solutions failed to completely support
the organisation’s IT needs in the majority of cases (Themistocleous, Irani, O’Keefe & Paul, 2001).
The agreement on common communication standards among software components is critical for
achieving information sharing and interoperability. As integration efforts continued, the need to
simplify the process of integrating existing applications and data lead to Enterprise Application
Integration (EAI) technologies. EAI defines a standard methodology for applications and data sources
to communicate. It thus pursues the creation of robust business solutions by combining applications
using common middleware and other viable technologies (e.g. data transformation services, process
management services etc) (Ring & Ward-Dutton, 1999; Al Mosawi et al., 2006). According to the level
in an application it addresses, there are mainly four types of EAI: data level, application interface level,
method level, and user interface level EAI.