17-07-2012, 10:29 AM
A Service-Oriented Architecture Framework for Mobile Services
[attachment=27785]
Abstract
Service-Oriented architectures and Service-Oriented
Computing are the most recent approaches aiming at
facilitating the design and development of applications on
distributed systems. The primary goal of this paper is to
investi-gate how the construction of mobile services can
benefit from the Service-Oriented paradigm. The paper
provides a presentation of the Service-Oriented
architecture. A general discussion of equivalence between
service components is then undertaken, in order to enable
an analysis of Service-Oriented architectures for mobile
services. The paper proceeds with a mapping of existing
mobile services on Service-Oriented architectures. The
requirements of mobile services, which must be taken into
consideration in the Service-Oriented architecture, are
identified from a generic model of mobile services. A
Service-Oriented architecture framework supporting
mobile services is proposed.
1. Introduction
Lately, Service-Oriented Computing (SOC) [1] and
Service-Oriented Architectures (SOA) [2] have gained a
lot of momentum in software engineering. SOC and SOA
are not completely new concepts; other distributed
computing technologies like OMG’s CORBA [3] and
Microsoft’s DCOM [4] have been based around similar
principles. SOA and SOC are merely extensions of the
existing concepts and new technologies, like XML Web
Services, are being used to realize platform independent
distributed systems.
The Service-Oriented architecture appears to be an ideal
paradigm for mobile ser-vices. However, it is currently
focused only on enterprise and business services. One of
the goals of this paper is to verify the feasibility of using
Service Oriented in the design and implementation of
mobile services. The paper starts with an overview of
Service Oriented architectures. A brief study of current
mobile services architectures presented earlier in [5] is
then given. This paper is based on the composition and
distribution principles as well as service continuity and
service personalisation concepts published in [6][7][8][9].
A mapping of existing mobile services on Service-
Oriented architectures will then be done. The
requirements of mobile services, which must be taken into
consideration in the Service-Oriented architecture, are
identified from a generic model of mobile services. A
Service-Oriented architecture supporting mobile services
is finally derived.
2. Service-Oriented Architectures (SOA)
According to [10], a Service-Oriented architecture is a
collection of services which communicate with each
other. The question is how this is different from earlier
concepts of distributed computing. With the SOA
definitions of a service provided above, it is not clear how
a service is different from an application. And if a service
is not different from an application, a service logic
component or a program, then it might seem like the term
Service-Oriented architecture is just another new word
describing the well-known concepts of distributed
systems and distributed computing.
However, the key here is that a service should be selfcontained.
This means that it can always provide the same
functionality, independently of other services. Distributed
systems have previously been tightly interconnected,
i.e., they have been subject to tight coupling. If one
component failed, the entire service provided by the
distributed system would fail. Also, previously distributed
systems would be closed. Their interfaces were internal,
not exposed and only known by the developers of the systems.
There are basically three functions that must be supported
in a service-oriented architecture:
1. Describe and Publish service
2. Discover a service
3. Consume/interact with a service
3. Mobile Services
Proceedings of the Advanced Industrial Conference on Telecommunications/Service Assurance with Partial and Intermittent Resources Conference/ELearning
on Telecommunications Workshop
0-7695-2388-9/05 $20.00 © 2005 IEEE
Let’s first consider voice telephony in GSM [11] to see
how it allows users to roam (i.e., user movement).
Mobile services in GSM consist of components both
located on the mobile device and in the network. Figure 1
shows the simplified architecture of mobile telephony
service and the Short-Message Service (SMS). The
Mobile Station (MS), or mobile phone, consists of two
computing devices; the Mobile Equipment (ME), which is
the phone itself and the Subscriber Identity Module
(SIM), which is a Smart Card. For mobile telephony, the
service components located on the Mobile Equipment and
the SIM interact with the components on the Mobile
services Switching Center (MSC), Home Location
Register (HLR) and Visitor Location Register (VLR).
While a mobile phone is allocated to a unique HLR, it is
communicating with different MSCs and VLRs according
to its location.
Figure 1 illustrates how the system allows a user to move
between two service providers (two operator networks).
The user physically moves, and thus needs to access
another network which is reachable in the new location.
For voice telephony in GSM, the user device now
accesses a new radio network through different Base
Transceiver Stations (BTS), controlled by other Base
Station Controllers (BSC) and a different Mobile services
Switching Center (MSC2). The user and device is also
registered in another Visitor Location Register (VLR2).
However, it still communicates with the Home Location
Register (HLR) of the original network.
For the Short Message Service (SMS), all traffic goes
through the Short Message Service Center (SMS-C) in the
home network.
MS
SIM
ME
BTS
BTS
BTS
BSC
BSC
MSC1
HLR1
PSTN
VLR2
VLR1
SMS_C
BTS
BTS
BTS
BSC
BSC
MSC2
MS
SIM
ME
<<moves>>
Home Network
Foreign Network
Figure 1: A user moves from one service provider to
another in GSM
As shown in Figure 1, as the mobile phone moves, the
components on the ME and the SIM will switch from
interacting with MSC1 and VLR1 to interacting with
MSC2 and VLR2. The functionality and interfaces of the
components are standardised, but the instances, for
examples MSC1 and MSC2, can be built by different
manufacturers. For the Short-message service the service
components on the ME and the SIM always collaborate
with the unique service component in the SMS-C (Short
Message Service Center) with the primary service
provider (home network), no matter where in the world
the mobile phone is. It is possible to summarize as
follows:
1. The composite service (GSM voice telephony) is
realised by service components partly on a user
device and partly in the network
2. The same composite service can be realised by
different service components (different
instances) for different users and different
devices
3. The same service can be realised by service
components developed by different
manufacturers (different implementations) and
located in different service provider locations
4. The composite service in GSM changes its
internal composition to accommodate user
movements
4. SOA and Mobile Services
A mobile service is equivalent to an application realized
by combining several services in a SOA. As seen in the
previous section, a mobile service is composed of several
standardized components, which can be interconnected at
runtime to accommodate user movements.
However, mobile services pose additional requirements to
the service architecture, which are not necessarily
supported by service architectures for other services like
enterprise and business services. For example, mobile
services should tackle several types of movements:
- Movement of users between devices
- Movement of devices across networks
- Movement of services across domains
As in GSM, future mobile services will depend on the
possibility to dynamically select appropriate service
instances, based on the current location of the user. This
could be as in GSM, discrete service instances, or it could
be composite service instances. Nomadic users, however,
move across boundaries of the service environments
(Locations), and access to services should be possible
regardless of such movements.
Traditional mobile services (voice telecommunication and
SMS) are personalized services; the identity of the user is
strongly connected to the service, and personal
adaptations can be performed (e.g. forwarding, answering
machine etc.). One requirement of future mobile services
is that it should be possible to personalize these also.
When a service is personalized, changes done to the
service should always follow the user. For this to happen,
the requirement for service continuity must also be
Proceedings of the Advanced Industrial Conference on Telecommunications/Service Assurance with Partial and Intermittent Resources Conference/ELearning
on Telecommunications Workshop
0-7695-2388-9/05 $20.00 © 2005 IEEE
fulfilled. These two requirements are therefore in one way
strongly interconnected, and they will both depend on the
composition of the services.
A generic mobile service can be said to contain some
specific service components which are required to render
the service; these are the components that supports the
mobile characteristics of the service.
To see how a SOA can be designed to support future
mobile services and their specific requirements, it is
therefore necessary to look at the architecture of a generic
mobile service, i.e. what components does it consist of
and how are they interconnected. The internal
composition of a generic mobile service is illustrated in
Figure 2. The components are as follows:
MobileService – The overall representation of the service,
consists of one or several service logic components. A
Graphical User Interface (GUI) is one of these, exposing
the service to the user. This component is most often a
composite service, or an application in SOA terminology.
ServiceLogic – This is a piece of executable code, e.g. a
program, or more precisely a service in SOA terminology.
ServiceState – These are state variables and other internal
data used by a service logic component (e.g. register
values). These have no equivalent in the common SOA
terminology, but are assumed an integrated part of a
service.
ServiceContent – These are other data that are used in
conjunction with a service, e.g. documents, but which are
not part of the state of the service logic component.
Common SOA terminology does not include such a
component.
Figure 2: The composition of a generic mobile service
ServiceContentMetaData – These are meta-information
used together with ServiceContent. They can be data
which provide additional value to the service content.
Take an internet browser as an example; the
ServiceContent are Web pages and the bookmark list is
part of the ServiceContentMetaData. Common SOA
terminology does not include an equivalent concept.
ServiceProfile – These are profiles (UserServiceProfile
and DeviceServiceProfile) containing information about
how the service should behave towards specific users and
devices. Common SOA terminology does not include this
concept.
In summary, the support for service continuity and
personalization in mobile services is dependent on the
availability of instances (of the same or similar
implementations) of the ServiceLogic component
(considered in the next subsection), access to the specific
ServiceState, the specific ServiceContent and the specific
ServiceProfile.
A. Service Equivalence
S1 S2
S3
S4
Service Environment A
Service Environment B
S5
<<moves>>
Figure 3: Composite services in different service
environments
As mentioned in the introduction, it could be possible to
substitute one service for another, if they can be proven to
be similar enough. In turn, this can be used to
accommodate movements of a user and to realize mobile
services. Any movement might result in the original
(composite) service no longer being available, e.g.
because one of the (discrete) services are out of reach
from the new location (see Figure 3). S1 and S2 represent
composite services used directly by the user. S3 and S4 are
discrete service components, used by S1 to offer the
composite service. When the user moves to a new service
environment, the composite service is offered through S2.
However, this service has only access to S4; S3 is no
longer accessible. A possible solution is to access S5,
which provide a service similar to S3. An analogy to GSM
is that it would not be possible to send an SMS from the
foreign network (Service Environment B), because the
new network can not communicate with the home
network and is thus not able to send messages through the
SMS-C (S3) in the home network of the user.
Proceedings of the Advanced Industrial Conference on Telecommunications/Service Assurance with Partial and Intermittent Resources Conference/ELearning
on Telecommunications Workshop
0-7695-2388-9/05 $20.00 © 2005 IEEE
To allow various movements, it might be necessary to
dynamically change the service architecture, e.g. by
switching from one service provider to another or to
switch between similar service components provided by
the current service provider.
The goal of a SOA supporting mobile services will be to
enable this type of functionality for generic services. I.e.,
the SOA must allow discrete, and possibly composite,
services to be substituted by other instances and
implementations. To be able to do this, a set of definitions
and a framework for describing similarities of services is
required, i.e. how can two service components be
compared. The steps required in such a process are:
1. Discover candidate service components
2. Compare candidates with current component; do
any of the candidates cover satisfactorily
amounts of the functionality provided by the
current component?
3. Switch between the components; i.e., realize the
connection between the components
The first two steps pose the biggest challenges, while the
third is simply a matter of changing a service identifier
(e.g. a URI). The discovery step requires semantic
searching capabilities (as approached by the Semantic
Web[12] and OWL [14]/OWL-S while the description
“satisfactorily amounts” must be formalized so that the
entire process described above can be automatically
performed by computers.
[attachment=27785]
Abstract
Service-Oriented architectures and Service-Oriented
Computing are the most recent approaches aiming at
facilitating the design and development of applications on
distributed systems. The primary goal of this paper is to
investi-gate how the construction of mobile services can
benefit from the Service-Oriented paradigm. The paper
provides a presentation of the Service-Oriented
architecture. A general discussion of equivalence between
service components is then undertaken, in order to enable
an analysis of Service-Oriented architectures for mobile
services. The paper proceeds with a mapping of existing
mobile services on Service-Oriented architectures. The
requirements of mobile services, which must be taken into
consideration in the Service-Oriented architecture, are
identified from a generic model of mobile services. A
Service-Oriented architecture framework supporting
mobile services is proposed.
1. Introduction
Lately, Service-Oriented Computing (SOC) [1] and
Service-Oriented Architectures (SOA) [2] have gained a
lot of momentum in software engineering. SOC and SOA
are not completely new concepts; other distributed
computing technologies like OMG’s CORBA [3] and
Microsoft’s DCOM [4] have been based around similar
principles. SOA and SOC are merely extensions of the
existing concepts and new technologies, like XML Web
Services, are being used to realize platform independent
distributed systems.
The Service-Oriented architecture appears to be an ideal
paradigm for mobile ser-vices. However, it is currently
focused only on enterprise and business services. One of
the goals of this paper is to verify the feasibility of using
Service Oriented in the design and implementation of
mobile services. The paper starts with an overview of
Service Oriented architectures. A brief study of current
mobile services architectures presented earlier in [5] is
then given. This paper is based on the composition and
distribution principles as well as service continuity and
service personalisation concepts published in [6][7][8][9].
A mapping of existing mobile services on Service-
Oriented architectures will then be done. The
requirements of mobile services, which must be taken into
consideration in the Service-Oriented architecture, are
identified from a generic model of mobile services. A
Service-Oriented architecture supporting mobile services
is finally derived.
2. Service-Oriented Architectures (SOA)
According to [10], a Service-Oriented architecture is a
collection of services which communicate with each
other. The question is how this is different from earlier
concepts of distributed computing. With the SOA
definitions of a service provided above, it is not clear how
a service is different from an application. And if a service
is not different from an application, a service logic
component or a program, then it might seem like the term
Service-Oriented architecture is just another new word
describing the well-known concepts of distributed
systems and distributed computing.
However, the key here is that a service should be selfcontained.
This means that it can always provide the same
functionality, independently of other services. Distributed
systems have previously been tightly interconnected,
i.e., they have been subject to tight coupling. If one
component failed, the entire service provided by the
distributed system would fail. Also, previously distributed
systems would be closed. Their interfaces were internal,
not exposed and only known by the developers of the systems.
There are basically three functions that must be supported
in a service-oriented architecture:
1. Describe and Publish service
2. Discover a service
3. Consume/interact with a service
3. Mobile Services
Proceedings of the Advanced Industrial Conference on Telecommunications/Service Assurance with Partial and Intermittent Resources Conference/ELearning
on Telecommunications Workshop
0-7695-2388-9/05 $20.00 © 2005 IEEE
Let’s first consider voice telephony in GSM [11] to see
how it allows users to roam (i.e., user movement).
Mobile services in GSM consist of components both
located on the mobile device and in the network. Figure 1
shows the simplified architecture of mobile telephony
service and the Short-Message Service (SMS). The
Mobile Station (MS), or mobile phone, consists of two
computing devices; the Mobile Equipment (ME), which is
the phone itself and the Subscriber Identity Module
(SIM), which is a Smart Card. For mobile telephony, the
service components located on the Mobile Equipment and
the SIM interact with the components on the Mobile
services Switching Center (MSC), Home Location
Register (HLR) and Visitor Location Register (VLR).
While a mobile phone is allocated to a unique HLR, it is
communicating with different MSCs and VLRs according
to its location.
Figure 1 illustrates how the system allows a user to move
between two service providers (two operator networks).
The user physically moves, and thus needs to access
another network which is reachable in the new location.
For voice telephony in GSM, the user device now
accesses a new radio network through different Base
Transceiver Stations (BTS), controlled by other Base
Station Controllers (BSC) and a different Mobile services
Switching Center (MSC2). The user and device is also
registered in another Visitor Location Register (VLR2).
However, it still communicates with the Home Location
Register (HLR) of the original network.
For the Short Message Service (SMS), all traffic goes
through the Short Message Service Center (SMS-C) in the
home network.
MS
SIM
ME
BTS
BTS
BTS
BSC
BSC
MSC1
HLR1
PSTN
VLR2
VLR1
SMS_C
BTS
BTS
BTS
BSC
BSC
MSC2
MS
SIM
ME
<<moves>>
Home Network
Foreign Network
Figure 1: A user moves from one service provider to
another in GSM
As shown in Figure 1, as the mobile phone moves, the
components on the ME and the SIM will switch from
interacting with MSC1 and VLR1 to interacting with
MSC2 and VLR2. The functionality and interfaces of the
components are standardised, but the instances, for
examples MSC1 and MSC2, can be built by different
manufacturers. For the Short-message service the service
components on the ME and the SIM always collaborate
with the unique service component in the SMS-C (Short
Message Service Center) with the primary service
provider (home network), no matter where in the world
the mobile phone is. It is possible to summarize as
follows:
1. The composite service (GSM voice telephony) is
realised by service components partly on a user
device and partly in the network
2. The same composite service can be realised by
different service components (different
instances) for different users and different
devices
3. The same service can be realised by service
components developed by different
manufacturers (different implementations) and
located in different service provider locations
4. The composite service in GSM changes its
internal composition to accommodate user
movements
4. SOA and Mobile Services
A mobile service is equivalent to an application realized
by combining several services in a SOA. As seen in the
previous section, a mobile service is composed of several
standardized components, which can be interconnected at
runtime to accommodate user movements.
However, mobile services pose additional requirements to
the service architecture, which are not necessarily
supported by service architectures for other services like
enterprise and business services. For example, mobile
services should tackle several types of movements:
- Movement of users between devices
- Movement of devices across networks
- Movement of services across domains
As in GSM, future mobile services will depend on the
possibility to dynamically select appropriate service
instances, based on the current location of the user. This
could be as in GSM, discrete service instances, or it could
be composite service instances. Nomadic users, however,
move across boundaries of the service environments
(Locations), and access to services should be possible
regardless of such movements.
Traditional mobile services (voice telecommunication and
SMS) are personalized services; the identity of the user is
strongly connected to the service, and personal
adaptations can be performed (e.g. forwarding, answering
machine etc.). One requirement of future mobile services
is that it should be possible to personalize these also.
When a service is personalized, changes done to the
service should always follow the user. For this to happen,
the requirement for service continuity must also be
Proceedings of the Advanced Industrial Conference on Telecommunications/Service Assurance with Partial and Intermittent Resources Conference/ELearning
on Telecommunications Workshop
0-7695-2388-9/05 $20.00 © 2005 IEEE
fulfilled. These two requirements are therefore in one way
strongly interconnected, and they will both depend on the
composition of the services.
A generic mobile service can be said to contain some
specific service components which are required to render
the service; these are the components that supports the
mobile characteristics of the service.
To see how a SOA can be designed to support future
mobile services and their specific requirements, it is
therefore necessary to look at the architecture of a generic
mobile service, i.e. what components does it consist of
and how are they interconnected. The internal
composition of a generic mobile service is illustrated in
Figure 2. The components are as follows:
MobileService – The overall representation of the service,
consists of one or several service logic components. A
Graphical User Interface (GUI) is one of these, exposing
the service to the user. This component is most often a
composite service, or an application in SOA terminology.
ServiceLogic – This is a piece of executable code, e.g. a
program, or more precisely a service in SOA terminology.
ServiceState – These are state variables and other internal
data used by a service logic component (e.g. register
values). These have no equivalent in the common SOA
terminology, but are assumed an integrated part of a
service.
ServiceContent – These are other data that are used in
conjunction with a service, e.g. documents, but which are
not part of the state of the service logic component.
Common SOA terminology does not include such a
component.
Figure 2: The composition of a generic mobile service
ServiceContentMetaData – These are meta-information
used together with ServiceContent. They can be data
which provide additional value to the service content.
Take an internet browser as an example; the
ServiceContent are Web pages and the bookmark list is
part of the ServiceContentMetaData. Common SOA
terminology does not include an equivalent concept.
ServiceProfile – These are profiles (UserServiceProfile
and DeviceServiceProfile) containing information about
how the service should behave towards specific users and
devices. Common SOA terminology does not include this
concept.
In summary, the support for service continuity and
personalization in mobile services is dependent on the
availability of instances (of the same or similar
implementations) of the ServiceLogic component
(considered in the next subsection), access to the specific
ServiceState, the specific ServiceContent and the specific
ServiceProfile.
A. Service Equivalence
S1 S2
S3
S4
Service Environment A
Service Environment B
S5
<<moves>>
Figure 3: Composite services in different service
environments
As mentioned in the introduction, it could be possible to
substitute one service for another, if they can be proven to
be similar enough. In turn, this can be used to
accommodate movements of a user and to realize mobile
services. Any movement might result in the original
(composite) service no longer being available, e.g.
because one of the (discrete) services are out of reach
from the new location (see Figure 3). S1 and S2 represent
composite services used directly by the user. S3 and S4 are
discrete service components, used by S1 to offer the
composite service. When the user moves to a new service
environment, the composite service is offered through S2.
However, this service has only access to S4; S3 is no
longer accessible. A possible solution is to access S5,
which provide a service similar to S3. An analogy to GSM
is that it would not be possible to send an SMS from the
foreign network (Service Environment B), because the
new network can not communicate with the home
network and is thus not able to send messages through the
SMS-C (S3) in the home network of the user.
Proceedings of the Advanced Industrial Conference on Telecommunications/Service Assurance with Partial and Intermittent Resources Conference/ELearning
on Telecommunications Workshop
0-7695-2388-9/05 $20.00 © 2005 IEEE
To allow various movements, it might be necessary to
dynamically change the service architecture, e.g. by
switching from one service provider to another or to
switch between similar service components provided by
the current service provider.
The goal of a SOA supporting mobile services will be to
enable this type of functionality for generic services. I.e.,
the SOA must allow discrete, and possibly composite,
services to be substituted by other instances and
implementations. To be able to do this, a set of definitions
and a framework for describing similarities of services is
required, i.e. how can two service components be
compared. The steps required in such a process are:
1. Discover candidate service components
2. Compare candidates with current component; do
any of the candidates cover satisfactorily
amounts of the functionality provided by the
current component?
3. Switch between the components; i.e., realize the
connection between the components
The first two steps pose the biggest challenges, while the
third is simply a matter of changing a service identifier
(e.g. a URI). The discovery step requires semantic
searching capabilities (as approached by the Semantic
Web[12] and OWL [14]/OWL-S while the description
“satisfactorily amounts” must be formalized so that the
entire process described above can be automatically
performed by computers.