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.