Maintaining the Core – Service Repository - Applied SOA Patterns on the Oracle Platform - page 316

• A Policy is defined as "a statement of direction that a human actor may intend to
follow or may intend that another human actor should follow." First, when talking
about SOA, we immediately exclude, during the functional decomposition phase,
human operations from the composition logic, deeming them unsuitable for auto-
mation. We do not abandon them, but just have another approach for them. Thus,
the policy should have a slightly broader meaning. Second, statements of direc-
tions are usually expressed through certain directives, that is, operations (tasks).
These operations could be performed by units of logic without a contract or pub-
lic interface (service agents, event-driven modules, not the services). Thus, the
whole structure of the Policy class is rather questionable.
Despite these considerably small discrepancies with the classic OOP and generic SOA in
terminology and relations ontology, we can take a lot from the presented approach and use
it in our service metadata classification, optimized for dynamic and agnostic service in-
vocation. We understand that the discussed ontology is an all-purpose model; therefore,
we focus on relations suitable for practical implementation of Service Repository on tradi-
tional DBs.
Other standardization groups, excluding Open Group, have made proposals for the service
metadata taxonomy. Noteworthy is the Reference Architecture Framework for the SOA
(SOA-RA) initiative by OASIS ( http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/csd03/soa-
ra-v1.0-csd03.pdf ; please check for the latest release). At the time of writing, their draft
seemed rather theoretical and the committee members were still debating on the definition
of "service." When asked about the practical value of this reference model for SOA practi-
tioners (at the fifth SOA & Cloud Symposium, where the first draft was presented), the
presenter, Mr. Brown, responded that the purpose is to build a better SOA. Without a
doubt it's a noble cause, and we believe that eventually it will produce something valuable
for SOA practitioners. For now, taxonomy Elements such as Willingness , Social Structure ,
Evidence , Real-World Effect , and Reputation are out of the scope of the SOA patterns' im-
plementation.
Actually, apart from the taxonomy, SOA-RA can be useful to understand the internal
Oracle ER DB structure. As you already noticed, there are so many elements to maintain
with so many relations in both public ontology frameworks that we couldn't avoid main-
taining categorization using the name-value style. SOA-RA Elements Common to General
Description ( Figure 14 in http://docs.oasis-open.org/soa-rm/soa-ra/v1.0/soa-ra.pdf ) is gen-
eric and quite similar to the asset definition domain in OER (please see the following dia-
gram):