Information Technology Reference
In-Depth Information
separated into access, communication and direction pattern (cf. Fig. 2). Firstly,
the access pattern specifies predefined ways on how to access objects in the
data model, e.g. ”create” or ”change”. Secondly, the communication pattern
describes the type of interaction to be e.g. ”request-confirmation” to define a
request operation that causes some action and a confirmation message being
returned. Thirdly, the direction pattern describes a service operation to be ei-
ther ”inbound” (e.g. incoming request to create a sales order) or ”outbound”
(e.g. outgoing credit card authorization request). We derived these patterns di-
rectly from available SOA Governance information. Referring to (S1), the sig-
nature employs factual concepts ”change”, ”request-confirmation” and ”in” be-
longing to terminological concepts access, communication and direction pattern
respectively:
SalesOrderItemScheduleLineChangeRequestConfirmation In
Naming Conventions.
The examples (N1)-(N3) below illustrate that naming
conventions already come in a pre-structured way (cf. [21]) and are used to guide
the creation of Enterprise Service signatures. The showcased syntax is defined
on the basis of non-terminal symbols, i.e. terminological concepts, and terminal
symbols, i.e. factual concepts.
NC
1
=
<BO>(<BO Node>)
∗
(N1)
NC
2
=
("Change"|"Create"|"Cancel"|"Read")
(N2)
NC
3
=
<CommunicationPattern>
(N3)
In terms of signature definition, (N1) for instance describes that any factual
concept related to a BO Node has to be positioned after the factual concept of a
particular BO. Finally, to receive a single (possibly incomplete) building rule, we
consolidated naming conventions (N1), (N2) and (N3) based on documentation
that outlines how to combine them. We further substituted the access pattern
for the terminal words in (N2). As a result, the building rule (B1) represents one
possible way of (partially) describing our Enterprise Service signature (S1):
BR
=
<BO><BO Node><AccessPattern><CommunicationPattern>
=
SalesOrderItemScheduleLineChangeRequestConfirmation In
(B1)
3 Automated Annotation Framework
In this section, we formally describe the two components used in our framework
to automatically annotate Enterprise Services, i.e. the service knowledge base
and the non-deterministic automaton. These components are based on our mod-
eling of SOA Governance as described in the previous Section. Therefore, we first
define the service knowledge base as an abstract model and data that represents
a given service design methodology (cf. data model and pattern in Section 2.1).
Second, we define a non-deterministic automaton describing a formal language
of Enterprise Service signatures. To illustrate this procedure, we will use the
naming conventions from Section 2.1.
