=Paper=
{{Paper
|id=Vol-440/paper-12
|storemode=property
|title=ICD Wiki – Framework for Enabling Semantic Web Service Definition and Orchestration
|pdfUrl=https://ceur-ws.org/Vol-440/paper12.pdf
|volume=Vol-440
|dblpUrl=https://dblp.org/rec/conf/oic/BrownP08
}}
==ICD Wiki – Framework for Enabling Semantic Web Service Definition and Orchestration==
https://ceur-ws.org/Vol-440/paper12.pdf
ICD Wiki – Framework for Enabling Semantic Web Service Definition and Orchestration
Dean Brown, Dominick Profico
Lockheed Martin, IS&GS, Valley Forge, PA
Abstract – As Net-Centric enterprises grow, the desire processes and user-desired functionality grows.
to rapidly define and build reusable services and create Composite Services logically chain multiple web services
new business processes through the combination of together, ideally using an execution language like WS-
services and workflow will grow. Semantic Web Services BPEL or Google Mashup that can execute the service
is one approach to facilitate automated mediation between without requiring software compilation by software
services based on semantic understanding of the services. developers.
Lockheed Martin is investigating the use of a wiki with an
However, based on the heterogeneous nature of web
underlying RDF data model to provide a collaborative
services, linking web services together where data formats,
framework to define services, document services, manage
names, units, and message formats are different requires an
ontology models, and quickly build composite services.
integrator knowledgeable about the specifics of each
I. Net-Centricity, SOA, and Web Services service; which is usually a software developer.
Net-Centric: Participating as a part of a II. Semantic Web Services
continuously-evolving, complex community of
The vision of Semantic Web services is to
people, devices, information and services
describe and annotate the various aspects of a
interconnected by a communications network to
Web service using explicit, machine-
achieve optimal benefit of resources and better
understandable semantics, enabling the
synchronization of events and their
automatic location, combination, and use of Web
consequences.i
services.iii
A. Net-Centricity
A. Semantic Web Service Overview
The following two principles are what makes Net-
The goal of our research on the IntegrationWare IRAD
Centric different from how we usually build systems:
project is to make service orchestration more in the spirit
• Openness. Information systems can communicate of the net-centric and Web 2.0 paradigm by allowing
across traditional system and enterprise boundaries Composite Services to be built quickly and easily by end-
in an open-ended ways. users in a familiar environment in an intuitive, drag-and-
• Dynamic Interaction. The capability to drop user interface. Semantic Web Services provide the
dynamically change the interaction and foundation to performing automated data-level mediation
organizational scope at run-time versus at system (matching dissimilar data names, formats, units) between
development time.ii services.
Service-oriented architectures (SOAs) implemented This is done by requiring the web service providers to
with web services provides an open, standards-based perform a one-time mapping of their web service to a set
approach to implementing capabilities that can be of ontology models, as well as documenting additional
dynamically linked together to implement a business information regarding the functionality of their services.
process. The movement towards SOA and web services The ontology models either pre-exist (developed
allows service providers to provide high-value capabilities specifically for a particular domain), or are modified as
and services without necessarily knowing the service needed to support the web services. Once the web service-
consumer. To optimize the value of these services, service to-ontology model mappings are complete, the mapping is
providers need to design and build services that are converted into a machine-readable format that will be used
reusable (as agnostic as possible to a specific to facilitate the discovery of services and automated data
implementation) and as stateless as possible (scalable and mediation between the services.
more independent). B. Ontology Models
B. Composite Web Services In order to create semantic web services, several
As the enterprise inventory of reusable web services different ontology models need to be created: at least one
grows, the desire to build Composite Web Services that domain model, a units model, a transformation model, and
leverage these services to quickly support new business a schema model.
The domain model(s) documents the entities, their
relationships, and their properties that are relevant to a
particular domain. For example, for the intelligence
community domain model, some entities could include
ISR assets, sensors, products, reports, tasking, geospatial
locations, collection plans, observations,… Ideally, the
domain model is built prior to performing the web service
mapping to help identify the desired set of web services to
be built or obtained. However, as new web services are
used that don’t map to existing entities and properties, then
the domain ontology model will grow.
The units model documents units for values such as
distance, area, volume, mass, temperature,… and how to
transform between them.
The transformation model documents known “generic”
transformations between different data types that aren’t
units of measurement and aren’t associated with a
particular entity. For example, a transformation service Figure 1. Web Service to Domain Ontology Mapping
that can transform from lat/long coordinates to MGRS Example
coordinates would show a relationship between lat/long
and MGRS. mapping services are supported (ex: we know how to
The schema model documents the message syntaxes to transform meters to feet).
support message transformations between services. For example, suppose a user wanted to create a
C. Web Service Mapping to Ontology Models composite service that computes how far an ISR asset is
off plan from it’s current position. This might require the
Our primary short-term goal in developing Semantic composition of two specific web services like
Web Services is to support data-level mediation between GetAssetInfo (to get position of identified asset in
web services. Because web services can be developed by a lat/long/elev) and GetISR_AssetPositionOffset (to take the
wide range of producers that don’t build their services with position of the identified asset (in MGRS coordinates and
a common data interface model in mind, many services elev) and a plan ID) to compute the offset (see Figure 2).
that reference the same data can have different data
formats (strings, ints, doubles,…), different data names
(asset_id versus AssetId), different data units (meters
versus feet, MGRS versus lat/long), and different data
structures or groupings of data.
The mapping of web service interface elements (data
inputs and outputs) to ontology model object properties
unambiguously “defines” that data element in terms of
“what” it is (domain model), the data format (schema
model), and data unit (unit model) in a machine readable
format (see Figure 1). This facilitates automated data
transformations to address all these data matching issues.
Once the mapping has been completed, the mapped
relationships are converted into a machine-readable Figure 2. Example Composite Service Generation
format.
D. Design-Time Service Composition If both services are mapped to a domain model (which
When multiple web service data interface elements are identifies AssetElev and ISRAssetElev as equivalent), a
mapped to the same ontology model object property, they units model (which knows how to convert feet to meters),
are declared to be semantically “equivalent”; meaning a and a transformation model (which knows how to convert
mapped web service output element can be mapped to an lat/long to MGRS), then the user can simply drag each
equivalent web service input element regardless of data service to the canvas and connect them together. The
type, name, unit, or data structure if the appropriate underlying system will use the ontology model mappings
to determine what outputs from the first service map to
Figure 3. ICD Wiki Functional Diagram
inputs to second service (equivalance). If data file can be either located locally on the user’s workstation
transformations are required, then the appropriate or any network reachable URL.
transformation services are automatically identified and
The import process places copies of all WSDL and
inserted between the user linked services.
related schema files onto a “Resource Bus”, making all
III. ICD Wiki files available via a standard URL reference. Co-locating
each of the required files simplifies the task of inspecting
A. Service Design, Discovery & Composition the interface files and validating references.
Framework
We provide a framework to build semantic web
services that is intuitive for users by using the Wiki
paradigm. The ICD wiki framework allows users to
import web services, perform the service-to-ontology
model mappings, and generate/convert/modify services for
export. It also allows users to “define” desired web
services and to provide feedback regarding the usability of
existing web services.
See Figure 3 for a functional diagram of the ICD wiki
framework vision. The yellow shaded boxes show where
we have done development so far. The following sections Figure 4. ICD Wiki / Resource Bus Interaction
provide more detail regarding the implemention of the ICD
Wiki. After replicating the necessary files to the Resource
B. Service Import Process Bus, the primary file is inspected to determine the format
and version. WSDL v1.1 files are converted to WSDL
Importing existing service definitions is a key v2.0 in order to facilitate the transformation and mapping
component of increasing the usefulness and adoption of stages. Conversion of the WSDL takes place via an
the ICD Wiki system. The wiki provides a user interface Extensible Stylesheet Language Transformation (XSLT).
designed to compliment existing common user interfaces The XSL file utilized to perform this transformation was
on the Web. Through this interface, a user is able to select acquired from the W3Civ. WSDL v2.0 specifications
a Web Service Description Language (WSDL) file to be require no additional conversion before being transformed
imported into the ICD Wiki Semantic Store. This WSDL into semantic representations.
C. Semantic Service Transformations
There are multiple aspects to converting a service support the integration of services without those services
specification into a semantic representation suitable for supporting the exact same mapping.
storage in the ICD Wiki Semantic Store. The OWL-S
D. Service Composition
definition allows for a service specification to be
represented semantically, but it does include the ability to Composition of services into larger, more robust
represent the underlying syntactic structure of the services is one of the primary drivers of the ICD Wiki
messages passed into and out of the service’s respective concept. Utilizing an off-the-shelf product called
operations. Semantic representation of the syntactic mxGraphv, we have a built a canvas-style, drag and drop
structure is required in order to accurately determine how interface for service composition. The available set of
service interfaces can be mapped to one-another. In order services are retrieved from the semantic store for inclusion
to support this level of detail we developed a small model in the new composite service. The composition tool makes
to represent XML Schemas. use of common Web 2.0 tenets to allow a user to drag a
This model represents each of the most commonly used service from the available service pool and place it on the
XSD elements as semantic entities. We are then able to canvas. Once on the canvas, a user can draw linkages
create individuals of those class elements which represent between service inputs and outputs. During this process,
the imported schema. Once the full schema for the service the underlying architecture will continually check for
has been re-represented semantically, that semantic data is assignability between the services linked.
inserted into our semantic data store. In addition to Assignability is the determination “IF” two services
automatically transforming the syntactic schema into a can be linked together. During composition, this is enough
semantic one, the system, at this stage, provides the user information to allow the user to connect two services
with the ability to assign “units” to entities in the semantic without being burdened with type and meaning mapping.
representation of the service schema. Early in our design The necessary transformations and conversions are added
process, it was determined that support for unit conversion during the composed service generation phase.
among service operations would be an integral part of
enabling service composition. A simple model was built After a user has completed laying out the composed
to represent the abstract concept of units and unit service as desired, the canvas will be examined and the
transformations, both simple and complex. If a user generation of the necessary work flow will be begin. The
chooses to include unit designations for various elements current system supports work flow generation as Business
in the schema representation, those units will be taken into Process Execution Language files. Built in to the
consideration during any future composition sessions and generated workflow code is all of the necessary unit and
used to facilitate additional transformations where type transformations to combine the services. The data is
appropriate. not transformed into a semantic format during execution of
the workflow, but rather the semantic data is used to
At this stage, additional user input is required in order determine what values can be assigned to what parameters,
to fully understand the relationship between the imported so a direct assignment is done between parameters inside
schema and the known domain-specific models in the ICD the workflow. Multiple assignments and transformations
Wiki thus far. Automated determination of this may be necessary to progress from one service parameter
relationship is not available at this time in the prototype, so to another, but these complexities are completely hidden
we present the user with an interface to allow point-and- from the user. These composed services are made
click mapping of the imported elements to one or more available within the ICD Wiki for further composition and
domain models. A single entity can be mapped to multiple integration as needed by additional users.
entities across multiple domain models, further enhancing
the intrinsic knowledge within the semantic data store. E. Wiki Page Generation
Mapping from complex objects in the syntactic schema Generation of pages inside the ICD Wiki takes place
to entities and entity –types with in the domain models during the service and model import capabilities. During
facilitates the systems ability at later stages to determine an import of either a model definition file or a service
“assignability” between two service interfaces. definition file, the necessary wiki pages are automatically
created to support the human-readable aspect of the ICD
“Assignability” is a determination made by applying Wiki concept.
semantic rules to the ICD Wiki service domain model and
other domain models to generate an entailment. This Every wiki page in the ICD Wiki is capable of
entailment is used to ensure that an output message for a displaying a side-bar style component which shows all of
service’s operation is “assignable” to the input message of the known semantic relationships between the entity
another service, during service composition. Entities are represented on the current page and other entities in the
assignable in many ways, and can be chained together to semantic store. Using the sidebar, users are able to
explorer related entities in a traditional point-and-click,
web format.
For imported services, a page is created to represent the
service document as a whole, as well as pages for each
Figure 6. Domain Model Start Page
IV. Conclusion
We believe that the ICD wiki framework and semantic
web services will allow all users to better leverage the
growing list of available web services, intuitively define
the services they want built, and provide feedback on the
usability of all services..
V. References
i
‘Net-Centric’, Wikipedia, The Free Encyclopedia,
Figure 5. Operation Wiki Page Example http://en.wikipedia.org/wiki/Net-centric, (accessed 10/2/08)
ii
The Essence of Net-Centricity, Hans Polzer
iii
operation and input/output for those operations. The Dieter Fensel, Holger Lausen, Axel Polleres, Jos de Bruijn,
Michael Stollberg, Dumitru Roman, John Domingue. Enabling
created pages contain little textual content, but instead
Semantic Web Services. Berlin Heidelberg: Springer-Verlag,
there are custom wiki tags injected into the page text in 2007
order to support dynamic generation of various page iv
http://dev.w3.org/2006/wsdlConverter/wsdl11to20.xsl
sections, including the cross-linking of operations and v
http://www.mxgraph.com/
types belonging to the service.
In addition to the semantic side bar outlined above,
every imported model has a page from which a user can
start exploring an imported model. This page provides
access to the Domain Model Explorer.
F. Domain Model Explorer
The Domain Model Explorer is a tool built directly into
the ICD Wiki system which supports a user in their
exploration of the available domain models (see Figure 6).
On each domain model’s starting page, a “web” of
semantic entities is displayed, allowing the user to find
relationships amongst the various entities in the model.
Further, each entity is accessible as a drill down point in
order to find further relationships with in the model.