A service-oriented architecture is an
approach to joining up systems within enterprises. It
is a relatively new approach, but is rapidly gaining popularity because of the lower costs
of integration coupled with flexibility and simplification of configuration. Service-oriented
architecture builds upon the experience of using Web Services for integration.
In a service-oriented architecture, the
application logic contained in the various systems
across the organisation – such as student record systems, library management
systems, VLEs, directories and so on – are exposed as services, which can then be
utilised (consumed) by other applications. For example, a student record system may
expose services for working with enrolment and registration information, which can then
be used within a VLE or library system (figure 4).
This approach is somewhat different to
two other common ways of integrating systems,
which are to integrate at the user interface level using portals, or at the data level by
creating large combined datasets (figure 5.).
A service-oriented approach does not preclude
also using portals or data warehouses,
and is in fact agnostic about how the rest of the enterprise is configured, which is why it
makes a good approach for a framework.
However, because integration occurs in
this fashion, it becomes a simpler task to
replace the systems that provide services within the architecture. Because service
consumers are configured to access a service without any knowledge of the system that
provides the service, we can replace the underlying system without affecting systems
dependent on its capabilities (figure 6.).
This diagram shows how access to
the course management functions of the
Student Record System (SRS) can operate in a service-oriented architecture.
The SRS provides a course management
web service. This service is
"consumed" (ie used) by the student portal to display student data, by the library
management system to synchronise data, and in this case a teaching tool has
been developed within a department that needs access to enrolment information.
However, this is not the only way
to access SRS data, and the SRS Course
Management forms can still be used to directly access the SRS by administrative
staff.
Once the SRS provides the web service,
additional applications can take
advantage of the capabilities exposed without any changes to the SRS or the
service.
Figure 4: Course management within
a service-oriented architecture
This diagram shows three different
approaches to joining up systems.
The solid "orange route"
integrates system capabilities at the end-user level by
wrapping their interfaces in a portal.
The dotted blue route" integrates
system data by combining it in a single large
database.
The dashed "green route"
integrates systems by exposing their application logic
as a service and sharing them with other applications (and end-users via portals).
Because the application logic is
abstracted from both the physical storage and
the user interface it is less "fragile" with respect to changes.
Figure 5: Different approaches to
integration
This diagram demonstrates replacement
of systems in a service-oriented
architecture.
Applications which used the Course
Management Web Service continue to do
so, unaffected by the replacement of the SRS providing the service.
However, the forms provided by the
old SRS are now obsolete and cannot be
reused.
Figure 6: replacing a student record
system in a service oriented architecture
There are other integration approaches
that also operate at the application logic level:
However, these technologies are either
very costly to implement (CORBA) or restrict
platform choice across the organisation (J2EE, DCOM). Web services can take
advantage of existing integration using these approaches, however, and many service
implementations build upon J2EE integration.
In summary, service-oriented architectures
have a number of features that make them
attractive for MLEs.
- They are agnostic with regard to platform choices and types of existing systems
- They are less expensive to implement
- Services can be used without knowledge of the internal workings of the system
providing the service, allowing systems to be replaced without causing widespread
disruption
- Services enable non-replaceable legacy systems to interact with new applications
- By providing access to functionality rather than user interfaces or data it enables
institutions and departments to develop applications that relate better to the tasks
they want to perform without duplicating the functionality of existing systems, but
instead leveraging existing investment in software.
Service-based architectures can be reconfigured
to meet changing operational
requirements or reflect organisational change.
