Semantic SOA Governance

Semantic SOA Governance

Keshava Rangarajan,
Applications Architect, Oracle America, Inc.

Arivoli Tirouvingadame,
Principal Member of Technical Staff, Oracle America, Inc.

Oracle Proprietary. Copyright 2008, Oracle Corporation

SOA Governance and Semantics

Gartner defines SOA Governance as “Ensuring and validating that
assets and artifacts within the architecture are acting as expected and
maintaining a certain level of quality.”

Semantic technology allows for the meaning of and associations
between information to be known and processed at execution time


Facilitating Governance: Potential for
Semantics
Added Intelligence
•Enable sharing of services and service artifacts via Semantics
•Manage the lifecycle of services and artifacts (Taxonomies,
Ontologies and
Inferencing)
•Manage quality of services and artifacts
•Define and manage policies
•Associate policies with services and artifacts
•Ensure policy compliance
•Manage contracts between consumers and providers
•Administer and configure services and their policies
•Ensure automatic enforcement of runtime policies
•Monitor runtime systems
•Integrate SOA governance with traditional SDLC and IT
management processes
•Gather metrics and enable reporting


Semantics & SOA Governance

-The potential for application of Semantics in SOA governance is enormous
-Building Governance functions on a base Semantic infrastructure will add
enormous value

The following cross cutting scenarios will hopefully illustrate the possibilities:
-Ontology based Service Browsing (based on Taxonomical Perspectives)
-Contextual Tagging and Association, Rating, Taxonomy and Folksonomy
reconciliation
-Semantic Service Artifact Search (Intelligent Find & Bind)
-Automated Service Classification


The Service Browsing Need
• In both design time and runtime governance contexts, the need for service taxonomies has long been
acknowledged by the technology experts in SOA governance solutions.
• Many service taxonomies have been proposed but none suffice
• Listed below is a small selection of proposed taxonomies for SOA services:

JP Morgenthal: Bill Roth: Randy Heffner: Oracle: SAP:
• Data • Component • Business • WIP • TBD
• Orchestration • Data • Transactional
• Image (Document) • Business • Query & content
• Business Services • Workflow • Analytical
• Management • Application
• Security • Functional
• Data
• Common
• Infrastructure


The Service Browsing need: Service
Ontology
• Despite coming from people of very diverse backgrounds (Architect, Executive, Analyst etc.), the
aforementioned taxonomies are remarkably similar i.e. they are layered, well structured, based on deep
understanding of SOA principles.
• They are not particularly useful to a business service provider who wants to offer a Customer Invoicing
Service, or a business service consumer in need of a Payment Processing Service.
• These taxonomies (by definitions, these are actually not taxonomies but classifications) are too small to
sufficiently narrow services down in order to create a target rich environment
• Business users do not relate to services in these terms; hence acceptance by business community is
difficult
• Domain driven taxonomies solve the problem partially, but still universal taxonomies are not the solution;
multiple role driven taxonomies are more practical


From Core Governance Information
Model
Order
Management
QOS Class
Service
Domain Rdfs:subclassOf
Classification
rdfs:subclassOf
rdfs:subclassOf
rdfs:subclassOf

Inventory rdfs:subclassOf QOS Class

Owl:restriction(belongsTo) Services Domain
OM
High
Owl:restriction(relatedTo) Response
Inventory Services QOS Class
Service Class Owl:restriction(relatedTo)
Owl:restriction(relatedTo) High Availability

Logistics Owl:restriction(relatedTo) Service Class
Owl:restriction(relatedTo)
Owl:restriction(belongsTo)
Services

Logistics
Domain Manufacturing
Manufacturing
Services Owl:restriction
(belongsTo) Domain
Owl:restriction(belongsTo)

Service A Service B Service C

QAOntology( browsed via QATaxonomy)
Business Ontology (browsed via Business Taxonomy) Architectural Ontology( browsed via Architectural
Taxonomy)


Core Governance Information Model


Service Taxonomy Continued

• Service Taxonomies can be represented in OWL
• RDFS subclass (for hierarchical relationships)
• “OWL:same as” and “OWL:equivalence” relations (for
interrelations within and across taxonomies)
• Tree View for Taxonomy visualization
• Faceted views for multiple taxonomies
• Contextual Popups for cross referencing relationships
• Allow user to browse multiple services
• Allow user to search multiple services
• Allow user to cross-navigate between different views/domains


The Solution: Semantic Service Browsing Component
The requirements of this ontology based Service Browsing Component (SBC)
are:
• SBC should be able to support multiple hierarchical
• SBC should provide security. There will be three primary
taxonomies.
types of actors using the SBC: administrators who create
• SBC should be able support non-hierarchical (“see also”) and maintain taxonomies, publishers who register their
relationships between nodes. services in the defined taxonomies, and users who browse
• SBC should support typed relationships between nodes in the taxonomies to locate the services they need. Security
taxonomies. The types should be user-definable but should requirements for each type of actor are outlined below.
be able to express generalization, aggregation, refinement, • SBC administrators should be able to create and modify
type-of and equivalence. taxonomies, and delegate administration rights to
• It should be possible to annotate nodes with plain text and individual nodes and sub-trees.
XML descriptions. • Service publishers should be able to register services to
• SBC should allow to import an external taxonomy. taxonomies, individual nodes and sub-trees.
• SBC should support unique identification of taxonomies, • SBC Users should be able to browse taxonomies and
nodes and relationships. search within them. The read access should be granted
• SBC should support federation by stubbing internal or on per-node basis. The users will not be able to go into or
external taxonomies to nodes in other taxonomies. under the nodes to which they do not have access.
• SBC should support versioning of taxonomies, nodes and • SBC should provide GUI-based and programmatic access
relationship types. to all functionality.
• SBC should support deprecation of taxonomies, nodes and • SBC should provide notification capability to inform
relationship types. Users can browse and search in interested parties when certain changes occur. Users
deprecated taxonomies and nodes, but service publishers should be able to register to receive notifications by event
should not be able to publish into them. scope and type. The scopes include taxonomy, node, sub-
• SBC should support both direct (nodes-to-entities) and tree; and the event types: service published, unpublished,
reverse (entities-to-nodes) referential models. This would object deprecation and change.
ensure that category-based searches will be supported with
booth cooperating service registries and repositories, which
can express relationships to the categorizing taxonomy
nodes as part of the metadata associated with services and
with non-cooperative ones.


The Automated Service Classification need
The Problem:
• New Services are being created at a rapid pace
• Enterprises have a large number of services
• Service attributes & behavior are constantly being modified (Service Life
cycle)
• Multiple Taxonomies exist for organization and navigation of services
• Service specifications, contracts, components are also being modified at
a rapid pace (Service Life Cycle)
• Services need to be continually classified and reclassified based on their
attributes such that they appear in the right places in taxonomies both
interactively and periodically
• Service Semantics are typically buried in descriptions, tags and other
textual or service description attributes
• Service classification needs to be done in an automated fashion as
manual categorization could be error prone


Solution: The Service Classification
Component (SCC)
• Service Classification via Text & Service Attribute
Mining (SVM based classification in a Data Mining
provides the right tools to make this happen)
• Classification component (Data Mining) takes in OWL
files that contain standardized Service Taxonomy as
well as the OWL files containing Service definitions
and descriptions, extracts attribute values from the
files and classifies the Services automatically into
appropriate nodes in the Service Taxonomy


The Contextual Tagging and
Association Need
The Problem:
• Service Taxonomies organize Governance artifacts into hierarchical structures that are static and typically
standardized
• Service Folksonomies arise from personal free tagging of governance resources for one's own use and the
aggregate collection of tags that results from a governance group tagging
• While standard Taxonomical structures encourage standardization, they are not necessarily the most user
friendly mechanisms to facilitate easy access
• There is a need for a component to contextually cross reference (i.e cross navigate) tags in a Folksonomy
to a node in one or more Service Taxonomies and vice versa
• When a governance item (say a service) is tagged by a user with a keyword such as “reliable”, what is
implied is “category=reliable”. The issue with this is that sometimes “category” is not enough context for a
tag. Meaning always requires context.


The Contextual Tagging and
Association Need
• A simple approach to connecting tagging to semantics is to allow the user to pick tags from a predefined
controlled vocabulary derived from ontology. When the user shares this tag after it has been validated,
it can be used by the search (semantic/text) engine to improve search relevance and inferencing. It also
helps other users and improves collective intelligence. Thus the user also participates in the knowledge
categorization process.
• A slightly different but more effective approach would be to allow the user to label the context of a tag with
anything (where the default is implicitly “category”). In the “category=reliable” example, the user could label
something as “service-behavior=reliable” or “service-provider=reliable”. The categories here are service-
behavior & service-provider. These groups of category tags i.e. “metatags” allow you to indicate the context
of a tag and give tags greater meaning and less ambiguity.
• Popular web metatags that internet users have already created include “location=” for places and “fav=” for
people’s favorites. When the user picks metatags from a predefined controlled vocabulary derived from
the enterprise ontology and shares this metatagging, it can be used by the semantic search engine to
improve search relevance and inferencing. The advantage of this approach is that this provides the user the
ability to continue to use his/her own custom tags.
• UI navigational constructs can to be provided such that cross navigation b/w taxonomies to contextually
relevant tags and vice versa is enabled. This way a user is not confined to browsing and locating repository
elements by just one metaphor (i.e. predefined taxonomies or just tags).


Solution: The Contextual Cross
Referencing Component (CCR)
• This component will receive the context of a node in a
Service Taxonomy and will be able to provide a set of
associated Tags that relate to the item in context
• This component could also receive an item in context
from a Folksonomy and be able to provide a set of
associated Taxonomy node points
• This output can be used for cross navigating from the
Taxonomy to the Folksonomy Domain


The Semantic Search Need (Intelligent
Find & Bind)
The Problem:

• For both design time, change time as well as runtime governance, users
need to be able to search on Governance artifacts based on
• Functional description of the Service
• QoS attributes of the Service
• Contractual aspects of the Service
• Runtime characteristics of the Service
• Associated entities or attributes of associated entities in a Service Ontology
• Other informational attributes that require an
• Understanding of the meaning or intent of these Service Artifacts
• Service Relationships


Cross Cutting Need: Semantic Search for
Governace
SPARQL Query SPARQL Rules
Jena Adapter for Oracle Generator Templates

Jena Inferencing
Engine
SOA ORACLE Enterprise Triplets for SPARQL Generator
Registry 10gR3 Taxonomy
<Subject, Object, Predicate>
Jena-Oracle APIs for Triples Generator
Bulk Load of RDF Query Result
Object with Verb, Class and Instance
values already recognized from the
String & striped by the Enterprise
Vocabulary
OWL Schema OWL Instance

Transformation

Triplets to UI
Enterprise

Object
Stanford Naïve Entity
Vocabulary Recognizer
XSD2OWL XML2OWL
Convertor Tool Convertor Tool Trainer

Search String
Enterprise
Vocabulary
Instance

Enterprise Data
Schema Search String

[Instances - XML]
[EBO XSD] Presentation Layer
Dashboard


Solution: The Semantic Service Search
Component (SSS)
A component that performs:
- Intelligent, Business Context based search : Search across structured,
semi-structured and unstructured Governance data
- Guides and assists end-users who want to search using Natural
Language queries
- Powerful Inferencing capabilities for users whose intent is not known:
System can bring to their attention what they need to know, but may not
know that they need it
- Unified UI with ability to take actions across Governance applications via
web services associated with a base Ontology


Link-blogging and Bookmarking need
• There is an intersection between bookmarking and web logging
(“blogging”), where ‘link blogging’, the process of creating governance
content that is a link to a site with a short comment, rather than a full length
blog post, is possibly better handled through a dedicated bookmarking
system
• Examples: Del.icio.us or Wists posting to a blog via standard API’s while
adding to a shared directory in parallel.
• We need to adopt this concept deeply in our Governance applications

Oracle Proprietary. Copyright 2008, Oracle
Corporation

RSS & Metadata need
• RSS 1.0 and 2.0 extend the notion of the earliest versions of RSS as a means to
syndicate simple headlines and links with extensible modules, allowing for any
metadata to be syndicated through RSS.
• Despite the fact that RSS has been around for nearly 10 years and that extending
RSS via modules has been around for 5, there are no RSS aggregators that can
read a new RSS module or extension, on-the-fly, allow for results to be filtered by
this metadata and display it correctly.
• An example would be addition of a tag called “Pricing service performance” -
allowing a user to be informed whenever any pricing service performance related
events/notifications/announcements are raised/made.


RSS, Metatags & Semantics need
• By allowing users to create metatags and attaching these metatags to their
own ‘namespace’, we allow for the possibility of formally defining groups of
metatags as an RSS module for a specific industry/deployment.
• Thus the application can host standard RSS modules (filters) that use metatags
as filters criterion to display information that is meaningful/relevant to
governance application user For e.g. filters could be setup to look for items that
are tagged by “service=inventory availability; performance=high;
provider=reliable” to collectively form an RSS filter module that looks for
“reliable, high performance, inventory availability services”.


SOA Governance and Semantics

Demo


Semantic SOA Governance

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (14)

Andere mochten auch

Andere mochten auch (8)

Ähnlich wie Semantic SOA Governance

Ähnlich wie Semantic SOA Governance (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Semantic SOA Governance