Model Generation

This generator, developed by Optare Solutions to the TMForum, is used to the ontology generation for data models.

Web Ontology Language (OWL) was chosen to generate the semantic description of the data model. This ontology is a knowledge representation, thus, it is capable of adding semantic capacity to the data model. Also, this language enables us to describe all artifacts from the model and all the corresponding links or relationships between them.

The ontologies created by this generator have as starting point the definitions of the outcomes of the European project IP-SUPER. Nevertheless, these ontology descriptions are in WSML and the project was focused in an old version of the Frameworx. Actually, this project was finished on March 2009.

Generation

As a result, the OWL generator will produce one OWL file. To generate this file we use two global rules:

• analyzeTypeClosure: This rule checks all dependencies of the models, including inheritance and references. It is the responsible for constructing the closure with all artifacts needed to generate the ontology.
• OWL_Model: This rule creates one OWL file with the artifacts of the entire model, including dependency artifacts referenced in the model.

To perform this generation, both rules need access to helper classes.

Mapping rules

In this section we will explain the design guidelines for the model generation.

Mapping rules for Entities, Datatypes, Enumerations, Events and Exceptions

Mapping rule for artifacts

• All artifacts are generated as classes in the OWL ontology.
• Example: In this example there are two artifacts (Enumeration and Entity), that they will be mapped as classes.
  
  

Figure 1: Example artifacts.

<owl:Class rdf:ID="Granularity"/>

<owl:Class rdf:ID="MeasurementJob"/>

Mapping rules for inheritance

• Each class is a subclass of the artifact it extends from.

• Example: In the figure 2, we can see that the Agreement artifact has BusinessInteraction as parent artifact.

   

Figure 2: Agreement artifact definition.

<owl:Class rdf:ID="Agreement"> 

	<rdfs:subClassOf rdf:resource="#BusinessInteraction"/>

</owl:Class>

• In case a specific artifact is not a subclass of any artifact (or in other way, it does not extend any artifact), it will be subclass of “SID + artifact type” (SIDEntity, SIDDatatype, etc.).
• Example: BusinessInteraction artifact has no parent artifact. Then it extends from SIDEntity.
  
  

Figure 3: BusinessInteractionRole definition.

<owl:Class rdf:ID="BusinessInteractionRole">

	<rdfs:subClassOf rdf:resource="#SIDEntity"/>

</owl:Class>

Mapping rules for attributes

• Attributes defined in the artifacts are mapped as properties in the class definition. If the attribute type is another artifact, "owl:onClass" is used to refer to the attribute type. If it’s a primitive type, it is mapped as "owl:onDataRange".
• Example: In the figure 4, we can see CapacityDemand attributes.
  
  

Figure 4: CapacityDemand attributes.

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#priority"/>

		<owl:onDataRange rdf:resource="&xsd;string"/>

		<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>

	</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#capacityDemandAmountTo"/>

		<owl:onClass rdf:resource="#Quantity"/>

		<owl:cardinality rdf:datatype="&xsd:nonNegativeInteger">1</owl:cardinality>

	</owl:Restriction>

</rdfs:subClassOf>

• If an attribute type is other artifact, the attribute is mapped as an “ObjectProperty”.
• Example: “quantity” attribute (BusinessInteractionItem) has other artifact as type.

<owl:ObjectProperty rdf:ID="quantity">

	<rdfs:domain rdf:resource="#BusinessInteractionItem"/>

	<rdfs:range rdf:resource="#Quantity"/>

</owl:ObjectProperty>

• If the attribute type is a primitive type, the attribute is mapped as “DatatypeProperty”.
• Example: “action” attribute (BusinessInteractionItem) has a primitive element as type.

<owl:DatatypeProperty rdf:ID="action">

	<rdfs:domain rdf:resource="#BusinessInteractionItem"/>

	<rdfs:range rdf:resource="&xsd;string"/>

</owl:DatatypeProperty>

• If attribute has “tipAttribute” stereotype with “isPassedById” property checked, the type of the property is EntityIdentifier.
• Attribute multiplicity is mapped inside the class property definition.

   If  an attribute definition has multiplicity “0..*”, “1..*” or “*”, then property type is mapped as “ArrayOf + attribute type” and type multiplicity is mapped as “0..1”.

   In any other case multiplicity is mapped as it is defined in the attribute.

• Example: MatrixFlowDomain artifact (package org.tmforum.tip.resource.res.log.tip.nrf) has “transmissionParameterList” attribute with multiplicity “1..*”.

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#transmissionParameterList"/>

		<owl:onClass rdf:resource="#ArrayOfTransmissionParameterList"/>

		<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#transmissionParameterList"/>

		<owl:onClass rdf:resource="#ArrayOfTransmissionParameterList"/>

		<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

• Generated classes have another property that defines the domain the artifact belongs to. This domain is defined in the attribute “SIDPackage” of the “tipPackage” package stereotype.

   This property is mapped as “ObjectProperty”.

• Example: In figure 5, we can see the domain definition for org.tmforum.tip.cbe.bi package.

Figure 5: Domain definition.

<owl:ObjectProperty rdf:ID="belongsToDomain">

	<rdfs:domain rdf:resource="#BusinessInteraction"/>

	<rdfs:range rdf:resource="#BusinessInteractionABE"/>

</owl:ObjectProperty>

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#belongsToDomain"/>

		<owl:onClass rdf:resource="#BusinessInteractionABE"/>

		<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1 </owl:cardinality>

	</owl:Restriction>

</rdfs:subClassOf>

Mapping rules for Associations

• Association end is mapped as classed property if the end of the association meets the following condition:  it has as type the artifact that is being mapped. This class property can be “ObjectProperty” or “DatatypeProperty”, depending on the type of the end (other artifact or primitive type).
• Example: Association AgreementAcceptedVia has the ends that can be seen in figure 6.

Figure 6: AgreementAcceptedVia association.

   In Agreement class definition, “AgreementAcceptedVia” is defined as “ObjectProperty” with AgreementApproval type.

<owl:ObjectProperty rdf:ID="AgreementAcceptedVia">

	<rdfs:domain rdf:resource="#Agreement"/>

	<rdfs:range rdf:resource="#AgreementApproval"/>

</owl:ObjectProperty>

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#AgreementAcceptedVia"/>

		<owl:onClass rdf:resource="#ArrayOfAgreementApproval"/>

		<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0 </owl:minCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf> 

	<owl:Restriction>

		<owl:onProperty rdf:resource="#AgreementAcceptedVia"/>

		<owl:onClass rdf:resource="#ArrayOfAgreementApproval"/>

		<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1 </owl:maxCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

• If and end has “tipAttribute” stereotype with “isPassedById” property checked, the type of the property is EntityIdentifier.
• Example: “affectedResources” end (ServiceProblemHasAffectedResources association) has “tipAttribute” stereotype with “isPassedById” property checked.

<owl:ObjectProperty rdf:ID="ServiceProblemHasAffectedResources">

	<rdfs:domain rdf:resource="#ServiceProblem"/>

	<rdfs:range rdf:resource="#EntityIdentifier"/>

</owl:ObjectProperty>

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#ServiceProblemHasAffectedResources"/>

		<owl:onClass rdf:resource="#ArrayOfEntityIdentifier"/>

		<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#ServiceProblemHasAffectedResources"/>

		<owl:onClass rdf:resource="#ArrayOfEntityIdentifier"/>

		<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

• Multiplicity is mapped just as in the case of the attributes.

   If end definition has multiplicity “0..*”, “1..*” or “*”, then property type is mapped as “ArrayOf + end type” and type multiplicity is mapped as “0..1”.

   In any other case multiplicity is mapped as it is defined in the end.

• Example: BusinessInteractionItem has “BusinessInteractionItemInvolves” property, which comes from an association.

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#BusinessInteractionItemInvolves"/>

		<owl:onClass rdf:resource="#ArrayOfBusinessInteractionRole"/>

		<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#BusinessInteractionItemInvolves"/>

		<owl:onClass rdf:resource="#ArrayOfBusinessInteractionRole"/>

		<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

Mapping rules for AssociationClasses

Association class artifacts are mapped as Entities, Datatypes… (as in section 1.2.1.3). The singularity is that these artifacts can also define an association. This association is treated as in the case of Association artifacts (section 1.2.2).

Mapping new types

The definition of certain stereotypes on artifacts and other variables generates some new classes in the OWL model file. These artifacts are not defined in the model.

• If the artifact is an entity and a non-abstract artifact, then the classes “Entity name + AVCN”, “Entity name + OCN”, “Entity name + ODelN” and “Entity name + ODisN” are created.
• If the entity has the stereotype “tipEntityCreate”, the class “CreateDataFor + Entity name” is created.
• If the entity has the stereotype “tipEntitySet” or “tipEntitySetMultiple”, the classes “SetDataFor + Entity name”, “AddDataFor + Entity name” and “RemoveDataFor + Entity name” are created.
• If the entity has the stereotype “tipEntityGetMultiple” or “tipEntitySetMultiple”, the classes “Entity name + Template”, “ArrayOf + Entity name + Template”, “Entity name + TemplateFilter” and “Entity name + FilterChoice” are created.

Interface Generation

To generate interface ontologies we have chosen Web Ontology Language for Services (OWL-S) given its simplicity and strength.

This ontology language is based in OWL but it is used to describe semantic web services, thus being appropriate to describe interfaces. This semantic definition allows automating web service discovery, execution, composition and interoperation.

Generation

For each interface that exists in the model six files are generated to complete the OWL-S schema (Figure 7: OWL-S schema.). These files are:

• Grounding OWL file: This service grounding details how an agent can access a service. (Rule OWL-S_Grounding)

   Grounding definition involves complementary use of the OWL and WSDL languages. These two languages are required for the full specification of grounding, because the two languages do not cover the same conceptual space.

• Messages OWL file: This file contains the definitions of the interface messages. (Rule OWL_ServiceInterface)
• Process Model OWL file: Process model tells a client how to use the service. (Rule OWL-S_ProcessModel)
• Profile OWL file: Describes the functionality of the service, detailing what the service does. (Rule OWL-S_Profile)
• Service OWL file: This class service provides an organizational point of reference for a declared Web Service. All files are linked from this service file. (Rule OWL-S_Service)
• WSDL file: contains the WSDL definition of the interface. (WSDL_ServiceInterface)

Figure 7: OWL-S schema.

To generate these files we need one rule per file. All the needed rules are artifact rules, which will be executed once for each interface in the project. The results will contain one new file for each rule execution (six files for each model interface).

Mapping rules

In this section we are going to explain the design guidelines followed for the generation of different files. These guidelines are based on the W3C specification for OWL-S.

Generic mapping rules

If an interface operation has “tipOperation” stereotype defined with “isOneWay” property checked, only Resquest message is defined for this operation.

Mapping rules for Grounding OWL file

• For each interface operation define a “WsdlGrounding” with the service and a reference to the atomic process grounding.
• Example: “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

<grounding:WsdlGrounding rdf:ID="groupResourceAlarms_ServiceGrounding">

	<service:supportedBy rdf:resource="&ResourceAlarmHandlingService_Service;#groupResourceAlarmsService"/>

	<grounding:hasAtomicProcessGrounding rdf:resource="#groupResourceAlarmsGrounding"/>

</grounding:WsdlGrounding>

• Create a “WsdlAtomicProcessGrounding” for each operation. Inside this element we reference the process, WSDL operation, input message and output message. All these referenced definitions are performed in the WSDL file.
• Example: “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

<grounding:WsdlAtomicProcessGrounding rdf:ID="groupResourceAlarmsGrounding">

	<grounding:owlsProcess rdf:resource="&ResourceAlarmHandlingService_Process; #groupResourceAlarms"/>

	<grounding:wsdlOperation>

		<grounding:WsdlOperationRef>

			<grounding:portType>

				<xsd:uriReference rdf:value="&ResourceAlarmHandlingService_Wsdl; #ResourceAlarmHandlingService"/>

			</grounding:portType>

			<grounding:operation>

				<xsd:uriReference rdf:value="&ResourceAlarmHandlingService_Wsdl; #groupResourceAlarms"/>

			</grounding:operation>

		</grounding:WsdlOperationRef>

	</grounding:wsdlOperation>

	<grounding:wsdlInputMessage rdf:resource="&ResourceAlarmHandlingService_Wsdl; #groupResourceAlarmsRequest"/>

	<grounding:wsdlInputs rdf:parseType="Collection">

		<grounding:WsdlInputMessageMap>

			<grounding:owlsParameter rdf:resource="&ResourceAlarmHandlingService_Process;#groupResourceAlarmsRequest"/>

			<grounding:wsdlMessagePart>

				<xsd:uriReference rdf:value="&ResourceAlarmHandlingService_Wsdl; #body"/>

			</grounding:wsdlMessagePart>

		</grounding:WsdlInputMessageMap>

	</grounding:wsdlInputs>

	<grounding:wsdlOutputMessage rdf:resource="&ResourceAlarmHandlingService_Wsdl; #groupResourceAlarmsResponse"/>

	<grounding:wsdlOutputs rdf:parseType="Collection">

		<grounding:WsdlOutputMessageMap>

			<grounding:owlsParameter rdf:resource="&ResourceAlarmHandlingService_Process;#groupResourceAlarmsResponse"/>

			<grounding:wsdlMessagePart>

				<xsd:uriReference rdf:value="&ResourceAlarmHandlingService_Wsdl; #body"/>

			</grounding:wsdlMessagePart>

		</grounding:WsdlOutputMessageMap>

	</grounding:wsdlOutputs>

</grounding:WsdlAtomicProcessGrounding>

• If an interface operation has “tipOperation” stereotype defined with “isOneWay” property checked, only InputMessage is defined for this operation.

Mapping rules for Messages OWL file

One OWL file is generated for each interface in the model.

• All messages are generated as Classes in this file. Each operation has Request, Response and Exception messages.
• Example: “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

<owl:Class rdf:ID="groupResourceAlarmsRequest">

<owl:Class rdf:ID="groupResourceAlarmsResponse">

<owl:Class rdf:ID="groupResourceAlarmsException">

• If an interface operation has “tipOperation” stereotype defined with “isOneWay” property checked, only Request message is defined for this operation.
• Operation arguments are mapped as class properties. The definition of these properties is equivalent the section Mapping rules for attributes, except the belongsTo property definition which is not performed in message definition.

   IN arguments are defined in Request message classes and OUT arguments in Response message classes.

• Example: argument “failingAlarms” of type BadAlarmReference (“groupResourceAlarms” operation)

<owl:ObjectProperty rdf:ID="failingAlarms">

	<rdfs:domain rdf:resource="#groupResourceAlarmsResponse"/>

	<rdfs:range rdf:resource="&model;#ArrayOfBadAlarmReference"/>

</owl:ObjectProperty>

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#failingAlarms"/>

		<owl:onClass rdf:resource="&model;#ArrayOfBadAlarmReference"/>

		<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

	<owl:Restriction>

		<owl:onProperty rdf:resource="#failingAlarms"/>

		<owl:onClass rdf:resource="&model;#ArrayOfBadAlarmReference"/>

		<owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:maxCardinality>

	</owl:Restriction>

</rdfs:subClassOf>

• Exception message classes need different definition, because is necessary to create a “choice” between all the exceptions defined in the interface (in order to choose only one of the exceptions).

   To do this, exceptions have to be disjoint between them. Once this is done, exception message class is defined with the union of all of the interface exceptions.

• Example: Exception message class for “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

          Example of interface exception definition, disjoint with other exceptions:

<owl:ObjectProperty rdf:ID="entityNotFound">

	<rdfs:domain rdf:resource="#entityNotFound_groupResourceAlarmsException"/>

	<rdfs:range rdf:resource="&model;#EntityNotFound"/>

</owl:ObjectProperty>

<owl:Class rdf:ID="entityNotFound_groupResourceAlarmsException">

	<rdfs:subClassOf rdf:resource="#groupResourceAlarmsException"/>

	<owl:equivalentClass>

		<owl:Restriction>

			<owl:onProperty rdf:resource="#entityNotFound"/>

			<owl:onClass rdf:resource="&model;#EntityNotFound"/>

			<owl:cardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:cardinality>

		</owl:Restriction>

	</owl:equivalentClass>

	<owl:disjointWith rdf:resource="#notImplemented_groupResourceAlarmsException" />

	<owl:disjointWith rdf:resource="#communicationLoss_groupResourceAlarmsException" />

	<owl:disjointWith rdf:resource="#invalidInput_groupResourceAlarmsException" />

	<owl:disjointWith rdf:resource="#unableToComply_groupResourceAlarmsException" />

	<owl:disjointWith rdf:resource="#accessDenied_groupResourceAlarmsException" />

	<owl:disjointWith rdf:resource="#internalError_groupResourceAlarmsException" />

</owl:Class>

   Union of all interface exceptions definitions:

<owl:Class rdf:ID="groupResourceAlarmsException">

	<dc:title>groupResourceAlarmsException</dc:title>

	<rdfs:subClassOf rdf:resource="#SIDOperation"/>

	<owl:unionOf rdf:parseType="Collection">

		<owl:Class rdf:about="#entityNotFound_groupResourceAlarmsException"/>

		<owl:Class rdf:about="#notImplemented_groupResourceAlarmsException"/>

		<owl:Class rdf:about="#communicationLoss_groupResourceAlarmsException"/>

		<owl:Class rdf:about="#invalidInput_groupResourceAlarmsException"/>

		<owl:Class rdf:about="#unableToComply_groupResourceAlarmsException"/>

		<owl:Class rdf:about="#accessDenied_groupResourceAlarmsException"/>

		<owl:Class rdf:about="#internalError_groupResourceAlarmsException"/>

	</owl:unionOf>

</owl:Class>

Mapping rules for Process Model OWL file

• Create a “ProcessModel” for each operation, with the service described and the process that describes it.
• Example: “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

<process:ProcessModel rdf:ID="groupResourceAlarmsProcessModel">

	<process:describes rdf:resource="&ResourceAlarmHandlingService_Service;#groupResourceAlarmsService"/>

	<process:hasProcess rdf:resource="#groupResourceAlarms"/>

</process:ProcessModel>

• Create an “AtomicProcess” (one per operation) with the input, output and exception messages. These element definitions make reference to Messages OWL file.
• Example: “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

<process:AtomicProcess rdf:ID="groupResourceAlarms">

	<process:hasInput>

		<process:Input rdf:ID="groupResourceAlarmsRequest">

			<process:parameterType rdf:resource="&tns;#groupResourceAlarmsRequest"/>

		</process:Input>

	</process:hasInput>

	<process:hasOutput>

		<process:UnConditionalOutput rdf:ID="groupResourceAlarmsResponse">

			<process:parameterType rdf:resource="&tns;#groupResourceAlarmsResponse"/>

		</process:UnConditionalOutput>

	</process:hasOutput>

	<process:hasEffect>

		<process:UnConditionalEffect rdf:ID="groupResourceAlarmsException">

			<process:ceEffect rdf:resource="&tns;#groupResourceAlarmsException"/>

		</process:UnConditionalEffect>

	</process:hasEffect>

</process:AtomicProcess>

• If interface operation has “tipOperation” stereotype defined with “isOneWay” property checked, only Input process is defined for this operation.

Mapping rules for Profile OWL file

• Create a “Profile” for each operation. In this element we make reference to the service, the process, defined in Process Model OWL file, and the messages that describe the operation, also described in Process Model OWL file.
• Example: “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

<profile:Profile rdf:ID="groupResourceAlarmsProfile">

	<service:presentedBy rdf:resource="&ResourceAlarmHandlingService_Service;#groupResourceAlarmsService"/>

	<profile:has_process rdf:resource="&ResourceAlarmHandlingService_Process; #groupResourceAlarmsProcessModel"/> 

	<profile:hasInput rdf:resource="&ResourceAlarmHandlingService_Process;#groupResourceAlarmsRequest"/>

	<profile:hasOutput rdf:resource="&ResourceAlarmHandlingService_Process; #groupResourceAlarmsResponse"/>

	<profile:hasEffect rdf:resource="&ResourceAlarmHandlingService_Process;#groupResourceAlarmsException"/>

</profile:Profile>

• If interface operation has “tipOperation” stereotype defined with “isOneWay” property checked, only Input profile is defined for this operation.

Mapping rules for Service OWL file

• Create a service definition for each operation interface.
• In this definition we define:
• The profile that presents this service.
• The process that describes it.
• The grounding that supports it.

• Example: “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

<service:Service rdf:ID="groupResourceAlarmsService">

	<service:presents rdf:resource="&ResourceAlarmHandlingService_Profile;#groupResourceAlarmsProfile"/>

	<service:describedBy rdf:resource="&ResourceAlarmHandlingService_Process; #groupResourceAlarmsProcessModel"/>

	<service:supports rdf:resource="&ResourceAlarmHandlingService_Grounding; #groupResourceAlarms_ServiceGrounding"/>

</service:Service>

Mapping rules for WSDL file

• WSDL definition with slight modifications compared to SOAP Generator.
• Modifications:
• Message definitions reference to messages defined in the process model OWL file.
• Example: “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

<wsdl:message name="groupResourceAlarmsRequest">

	<wsdl:documentation>

		<p>The groupResourceAlarms request message.</p>

	</wsdl:documentation>

	<wsdl:part name="body" owl-s-wsdl:owl-s-parameter="ResourceAlarmHandlingService_Process:#groupResourceAlarmsRequest" />

</wsdl:message>

<wsdl:message name="groupResourceAlarmsResponse">

	<wsdl:documentation>

		<p>The groupResourceAlarms response message.</p>

	</wsdl:documentation>

	<wsdl:part name="body" owl-s-wsdl:owl-s-parameter="ResourceAlarmHandlingService_Process:#groupResourceAlarmsResponse" />

</wsdl:message>

<wsdl:message name="groupResourceAlarmsException">

	<wsdl:documentation>

		<p>The groupResourceAlarms exception message.</p>

	</wsdl:documentation>

	<wsdl:part name="body" owl-s-wsdl:owl-s-parameter="ResourceAlarmHandlingService_Process:#groupResourceAlarmsException" />

</wsdl:message>

• In port type definitions part, operation is referenced from process model OWL file.
• Example: “groupResourceAlarms” operation of ResourceAlarmHandlingService operation (RAM)

<wsdl:portType name="ResourceAlarmHandlingService">

	<wsdl:documentation>

		<p>Service Interface containing all the control operations offered on Resource Alarms. It includes common set and create operations.</p>

	</wsdl:documentation>

	<wsdl:operation name="groupResourceAlarms" owl-s-wsdl:owl-s-parameter="ResourceAlarmHandlingService_Process:#groupResourceAlarms">                                  

		<wsdl:documentation>

			<p>This is a request-response operation.</p>

			<p>Group one or more underlying alarms to a parent alarm. The parent alarm can be marked at the same time as potential root cause indication. This operation is not supported in the Simple Alarm Reporting and Standard 		profiles and optional in Enhanced profile.</p>

		</wsdl:documentation>

		<wsdl:input name="groupResourceAlarmsRequest" message="tns:groupResourceAlarmsRequest" />

		<wsdl:output name="groupResourceAlarmsResponse" message="tns:groupResourceAlarmsResponse"/>

		<wsdl:fault name="groupResourceAlarmsException" message="tns:groupResourceAlarmsException" />

	</wsdl:operation>

</wsdl:portType>

Mapping rules for stereotypes

Stereotype definitions can generate operations, in addition to those already generated from the model interfaces. In this section, we explain what operations are generated from each stereotype. These operations are generated in all of the interface OWL files.

• Common operations

To generate common operations interface managed entities should have the stereotype definition.

Next, we will describe the equivalency between defined stereotypes and generated operations.

• “tipEntityGet” stereotype generates “get + Entity name”.
• “tipEntityGetMultiple” stereotype generates “get + Entity name + s”.
• “tipEntitySet” stereotype generates “set + Entity name”.
• “tipEntitySetMultiple” stereotype with “isAtomic” property not checked generates “set + Entity name + s”.
• “tipEntitySetMultiple” stereotype with “isAtomic” property checked generates “set + Entity name + sAtomic”.
• “tipEntityCreate” stereotype generates “create + Entity name”.
• “tipEntityDelete” stereotype generates “delete + Entity name + s”.
• File transfer operations
  • “tipDataTransfer” stereotype definition in the interface generates “suspend”, “resume” and “listAvailableFiles” operations.
  • Generic operations

To generate generic operations it is necessary to define the stereotypes in the interface.

• “tipGenericQuery” stereotype definition with “getById” attribute value equal to “M” generates “get + Entity name + ById”.
• “tipGenericQuery” stereotype definition with “getByIds” attribute value equal to “M” generates “get + Entity name + ByIds”.
• “tipGenericQuery” stereotype definition with “getByAssociations” attribute value equal to “M” generates “get + Entity name + ByAssociations”.
• “tipGenericQuery” stereotype definition with “getbyCharacteristicFilter” attribute value equal to “M” generates “get + Entity name + ByCharacteristicFilter”.
• “tipGenericQuery” stereotype definition with “getByContainment” attribute value equal to “M” generates “get + Entity name + ByContainment”.
• “tipGenericQuery” stereotype definition with “getByEntityTypeNames” attribute value equal to “M” generates “get + Entity name + ByEntityTypeNames”.
• “tipGenericQuery” stereotype definition with “getByGraphQuery” attribute value equal to “M” generates “get + Entity name + ByGraphQuery”.
• “tipGenericQuery” stereotype definition with “getByQueryFilter” attribute value equal to “M” generates “get + Entity name + ByQueryFilter”.
• “tipGenericQuery” stereotype definition with “getByTemplate” attribute value equal to “M” generates “get + Entity name + ByTemplate”.
• “tipGenericQuery” stereotype definition with “getByTemplates” attribute value equal to “M” generates “get + Entity name + ByTemplates”.
• Update operations

To generate update operations it is necessary to define the stereotypes in the interface.

• “tipGenericUpdate” stereotype definition with “getPolicies” attribute value equal to “M” generates “get + Entity name + Policies”.
• “tipGenericUpdate” stereotype definition with “validateByIds” attribute value equal to “M” generates “validate + Entity name + ByIds”.
• “tipGenericUpdate” stereotype definition with “validateByTemplateFilters” attribute value equal to “M” generates “validate + Entity name + ByTemplateFilters”.
• “tipGenericUpdate” stereotype definition with “createByValue” attribute value equal to “M” generates “create + Entity name + ByValue”.
• “tipGenericUpdate” stereotype definition with “createByValues” attribute value equal to “M” generates “create + Entity name + ByValues”.
• “tipGenericUpdate” stereotype definition with “createMultipleByTemplate” attribute value equal to “M” generates “createMultiple + Entity name + ByTemplate”.
• “tipGenericUpdate” stereotype definition with “deleteByIds” attribute value equal to “M” generates “delete + Entity name + ByIds”.
• “tipGenericUpdate” stereotype definition with “deleteByTemplateFilters” attribute value equal to “M” generates “delete + Entity name + ByTemplateFilters”.
• “tipGenericUpdate” stereotype definition with “modifyByTemplate” attribute value equal to “M” generates “modify + Entity name + ByTemplate”.
• “tipGenericUpdate” stereotype definition with “modifyByValue” attribute value equal to “M” generates “modify + Entity name + ByValue”.
• “tipGenericUpdate” stereotype definition with “modifyByValues” attribute value equal to “M” generates “modify + Entity name + ByValues”.
• “tipGenericUpdate” stereotype definition with “createByTemplate” attribute value equal to “M” generates “create + Entity name + ByTemplate”.
• “tipGenericUpdate” stereotype definition with “modifyByAttributePatterns” attribute value equal to “M” generates “modify + Entity name + ByAttributePatterns”.
• “tipGenericUpdate” stereotype definition with “modifyById” attribute value equal to “M” generates “modify + Entity name + ById”.
• “tipGenericUpdate” stereotype definition with “modifyByIds” attribute value equal to “M” generates “modify + Entity name + ByIds”.
• “tipGenericUpdate” stereotype definition with “modifyByTemplateFilters” attribute value equal to “M” generates “modify + Entity name + ByTemplateFilters”.

How to use the OWL Generator

The way you use the created OWL generator is very similar to that used in the Soap Generator. The steps required before using the generator are:

• Do “Package and deploy this generator” of the generator. This is performed on the “ts-plugin.xml” generator file. This file can be seen in Figure 1.

Figure 8: ts-plugin.xml file.

• Once the generator has been deployed is necessary to access the "Generator Settings" tab in the "tigerstripe.xml" file (generator settings tab can be seen in Figure 2). This is located in the project “name of the project”+_Model (for example, in case of SID, the project will be called SID_Model).
  • In this tab we can enable the generator through the “Enable Generator” checkbox. In this case, we want to enable the OWL Generator. In this tab, we can define some generation properties too:
    • LogLevel: this property defines the level of detail to be provided in the log during the build.
    • artifactId: the string used in this property defines the name of the folder in which the generated files appear.
    • projectName: in this property we define a string to use as a prefix of the generated files name during the OWL Generator execution.
    • injectExceptions: here we can add de default exceptions that will be generated if the evaluated interface method does not have any exceptions.

Figure 9: "Generator Settings" tab.

• After completion the project configuration, now we can launch the build. To do this simply select the project you want to run and press the "Generate" button, located on the toolbar (figure 3).

Figure 10: Toolbar.