![](bg3.png)
Fig. 1. shows how the systems and system
components used in the service are combined into
unified e–service system architecture. For every data
object that is required in the implementation of e–
service, an XML Schemas Catalog has to be
developed. Data call from the relevant functional
system is done by means of the web services. When
web service calls are done, also metadata that
describe the request are sent. Also any information
that is required for the audit trails is sent together
with the metadata. Web services can be distributed
into two groups: simple and complex. Complex web
services in fact are logical combinations of several
simple web services that result from the process
integration requirements; a combination may
comprise simple services of one or several
independent functional systems. Complex web
services can be executed by using a BPEL processor.
A BPEL processor is used as the orchestration
(integration) environment for the e–service’s web
services. Portals, one–stop agency applications etc
ensure the delivery of e–services to the users. E–
service entry forms, stop points, information on
payments and execution results are transferred
through HTML or HML pages that can be used in
the portal to implement the service using the XSLT
transformation. Web service and e–service holders,
i.e. institution specialists and system administrators
who are responsible for the maintenance and
development of web services and e–services, must
have a possibility to intercommunicate on various
issues connected with the execution and
advancement of web services and e–services. Also,
asynchronous e–services have to be executed.
Messaging systems are designated for this purpose.
The messaging system enables working with text
messages and work tasks. The application is inter-
integrated with the e–services register, from which it
receives data on XML schemas, web services and e–
services. On the other hand, the messaging
application is a client of the orchestrations as
messages on the execution of web services and e–
services are received from them. Data on all XML
schemas, web services and e–services are entered in
a single register called E–services Register. The
register keeps all the versions of schemas, services
and e–services so that this information is accessible
to anyone who is engaged in the development and
advancement of e–services.
The main problems in the e-business system
architecture are related to the e-service’s data
standardization, audit, the creation of a web service
catalog (UDDI), the execution of asynchronous e-
services, security and the development of e-service
orchestration that is connected with web service
design. If e-business environment components that
ensure quality e-services are once created, they can
be later used repeatedly, whereas web services of
particular e-services and their orchestration must be
developed for every e-service individually.
Furthermore, the development of web services and
their orchestration significantly affects the e-
service's performance metrics and, consequently, the
overall quality of e-service (QoS). To design web
services and their orchestration, the Quality
Attributes Driven Web Services Design Method,
which ensures swift and quality designing, can be
used.
3 QUALITY ATRIBUTES DRIVEN
WEB SERVICES DESIGN
METHOD
The offered e – business system architecture design
method consists of the following steps (Fig. 2.):
1. Initially it is necessary to create the e-service
algorithm graph G that describes the e-service to
be designed;
2. In the e-service algorithm graph, it is necessary
to determine the possible restrictions for inter-
segmentation of vertexes;
3. By recursively segmenting the e-service
algorithm graph, the web service graphs
are obtained that are then used as the basis
for the development of the e-service system
architecture; The e-service algorithm graph is
assumed as the initial web service graph;
4. The numerical vales of quality metrics of the
obtained web service graphs are calculated;
5. From all the web service graphs, the Pareto
optimality set
is obtained;
6. Web service graphs of the obtained set P can
serve as the basis for selecting an acceptable e-
business system architecture. The web service
graphs that are contained in the obtained Pareto
optimality set can be designed in detail and
implemented in the e-business system
architecture;
7. In most cases, the Pareto optimality set P
contains more than one solution. If the obtained
set is sufficiently small, the selection of web
service graphs from the set can be left to the
system designer. However, if there are many
possible solutions, then in order to select a
particular web service graph, the criteria can be
decreased or combined with another optimisation
or design method.
SOA BASED E-BUSINESS SYSTEMS DESIGN
267