Interpretation of UML elements by UML-to-SOA transformations

The UML-to-SOA transformation generates Service Component Definition Language (SCDL), Web Services Description Language (WSDL), XML Schema Definition (XSD), and Business Process Engineering Language (BPEL) elements and artifacts based on the contents of the source UML model and the options that you specify in the transformation configuration.

Transformation of UML elements into SCDL domain artifacts

Depending on the characteristics of the source model elements and the settings in UML-to-SOA transformation configuration file, the transformation generates the following SCDL domain artifacts.

The stereotypes mentioned in the table below belong to the Services Modeling (SoaML) profile.

UML element	Transformation output
Project in a workspace that contains referenced XSD or WSDL resources	WebSphere® Integration Developer Library project
Model that contains a referenced UML interface or data type	WebSphere Integration Developer Library project
Component that represents a service provider	WebSphere Integration Developer Module project This Module project might reference a Library project that contains required Java™, XSD, or WSDL resources. The transformation copies existing XSD and WSDL resources that the source UML model references into the corresponding Library projects that are created in the target project. If a source UML model contains references to Java interfaces or Java classes, the transformation copies the Java project that contains the references into the target project.
Component that is a type for a UML part in a service provider component	SCDL component
Port in a service provider component with one or more provided interfaces, or port with the «Service» stereotype applied	SCDL export element
Port with the «Service» stereotype applied in a service provider component with one or more provided interfaces	SCDL export element
Port with the «Service» stereotype applied in a service provider component with one or more provided and required interfaces	SCDL export element for the provided interfaces, SCDL import element for the required interfaces
Port in a service provider component with one or more required interfaces	SCDL import element
Port with the «Request» stereotype applied in a service provider component with one or more required interfaces	SCDL import element
Port with the «Request» stereotype applied in a service provider component with one or more required and provided interfaces	SCDL import element for the required interfaces, SCDL export element for the provided interfaces
Provided interface that is referenced by internal ports	SCDL interface of type WSDL portType
Required interface that is referenced by internal ports	SCDL reference of type WSDL portType
Methods in a referenced interface	SCDL methods
Data type that is referenced by a UML interface or WSDL port type	XSD data types
Connector	SCDL wire

Transformation of UML components that contain one or more UML activities

When you configure the UML-to-SOA transformation to generate artifacts for the SCDL domain, if a component in the source model contains a UML activity, BPEL artifacts are generated from the source model.

The following table lists the UML elements that the transformation supports, and the corresponding BPEL construct or activity that the transformation creates.

UML element	Transformation output
Component that contains one or more UML activities	The transformation creates a BPEL process with the same name as the component. If the component contains an empty UML activity, the transformation creates an empty BPEL `scope` activity for each operation in the provided interfaces.
Component::ownedAttribute, where the component contains one or more UML activities	If the type that is specified in the type property of the owned attribute is not a component with ports, the transformation creates a BPEL variable in the corresponding BPEL process.
Provided interfaces in a component that contains one or more UML activities	The transformation generates WSDL files for each interface, and also generates partner links that have a myRole specification.
Required interfaces in a component that contains one or more UML activities	The transformation generates WSDL files for each interface, and also generates partner links that have a partnerRole specification.
Accept call action	A BPEL receive activity is generated. The transformation examines the list of triggers that are associated with the action to determine which operation is associated with the CallEvent type, and to determine which operation maps to the BPEL operation. The transformation generates the partner by using the name of the output pin that is associated with the ReturnInformation property of the action when the name of the pin is not empty and the name must match a port name. Otherwise, the transformation uses the ActivityPartition::represents property where the value of the ActivityPartition::represents property must be either a port or a type of port. The operation container must be a provided interface in one of the ports through which it receives the call. The number of output pins in the action must match the number of [out] parameters of the operation. The action must also contain an extra output pin that represents the Return Information property of the action.
Accept event action with no incoming edges Accept event action with one or more incoming edges Accept event action with a trigger whose event is a SignalEvent	A BPEL flow is generated when there are one or more SignalEvents in the AcceptEventAction::triggers. The transformation does not support multiple incoming ControlFlows and multiple incoming object flows to the same InputPin on the action. A BPEL receive is generated. The operation is derived from the reception that signifies that the signal that can be received. Note: An AcceptEventAction must be in an ActivityPartition that represents a port or type of a port through which it receives the event. The provided interface for the port must contain a reception for each signal. An AcceptEventAction must have an OutputPin for each signal that is associated to the SignalEvents in the AcceptEventAction::triggers. The pin type must match the signal type.
Accept event action with a trigger whose event must be a TimeEvent Time expression associated with the TimeEvent::when property	A BPEL wait activity is generated. The `for` and `until` expressions of the BPEL wait activity are set based on the TimeExpression property that is associated with the TimeEvent::when property in the source model. The `for` expression, which is a duration expression, must be in the following format: year, month, date, hour, minute, and second, as in the following example: `yyyy,mm,dd,hh,mm,ss` The `until` expression, which is a deadline expression, must be in following format: number of years, months, days, hours, minutes, and seconds, as in the following example: `yyyy,mm,dd,hh,mm,ss` Note: If the UML model contains multiple time events, the transformation transforms only the first event in the list of events.
Activity that is an owned behavior of a component and a method of an operation provided by that component	The transformation creates a BPEL scope activity in the top-level flow of the BPEL process for the component.
Activity::Specification	If the component contains only one activity, the transformation creates a top-level BPEL receive activity for the operation that is associated with the specification. If the component contains multiple activities, the transformation creates a BPEL pick activity and onMessage Event type for each operation that is associated with each Activity::Specification. If the specification operation contains an Out or Return parameter, the transformation creates a BPEL reply activity.
Activity::ownedParameter:Parameter	The transformation creates a BPEL process variable in the BPEL process that corresponds to the component. The variable names must be qualified with the activity name to ensure that there is no collision with parameters of other activities in the component. Parameter names and operation types that are associated with the activity specification must have activity parameters that match in both name and type.
Activity::ownedAttribute:Property	The transformation creates a BPEL variable in the top-level scope element for the activity in the process.
Activity::variable:Variable	The transformation creates a BPEL variable in the top-level scope for the activity in the process.
Activity final node	The transformation creates a BPEL terminate activity.
ActivityPartition::represents	The value of the `represents` property must be a port or type of a port. The transformation generates a BPEL PartnerLink for each provided or required interface in the port. By doing so, transformation can identify the correct BPEL partner link for the operation that is associated with actions in the partition.
Initial node	The transformation uses this element to indicate the start of a BPEL activity; it does not create any BPEL artifacts for this node.
Decision node	The transformation creates a BPEL switch activity and a BPEL case branch for each outgoing flow from this node. A BPEL sequence is created in each BPEL case branch to accommodate the BPEL activity that is generated from the target of each outgoing flow. Each guard of each outgoing flow sets the BPEL condition for the BPEL case branch. The transformation creates a BPEL otherwise branch for the outgoing flow when the guard value equals `else` and the language property is empty.
Fork node	The transformation generates code that specifies the start of a BPEL flow activity: `<flow name="ForkNode.name">` In a `<flow>` activity, the transformation creates a nested BPEL sequence activity for each flow that exits the fork node.
Join node	The transformation generates code that specifies the end of a BPEL flow activity: `</flow>`
Merge node	The transformation creates BPEL links between the source nodes of each incoming flow to the merge node and the target node of the outgoing flow of the merge node.
Activity parameter node	The transformation does not create corresponding BPEL artifacts. The transformation examines ActivityParameterNode object nodes to determine the sequence order only if object flows are connected to the ActivityParameterNode object node. The ActivityParameterNode object node must have corresponding activity parameters.
Loop node	The transformation creates a BPEL `while` activity for each loop node in the UML activity that is an owned behavior of a UML component.
LoopNode::decider	The transformation creates a BPEL condition for the BPEL `while` activity by using the BPEL variable that is associated with the output pin. The associated output pin must be of type UMLPrimitiveTypes::Boolean.
UML elements inside a loop node	In the BPEL `while` activity, the transformation creates appropriate BPEL activities for UML elements that are supported by the UML-to-BPEL transformation.
Call operation action	A BPEL invoke activity is generated. The transformation generates the partner by using the name of the target input pin when the name of the pin is not empty and the name of the pin must match a port name. Otherwise, the transformation uses the ActivityPartition::represents property and the value of this property must be either a port or the type of a port. The operation container must be a required interface in one of the ports through which it invokes the operation. The number of input pins in the action must match the number of [in] parameters in the operation. The action must also contain an extra input pin that represents the target input pin of the action. The number of output pins in the action must match number of [out] parameters in the operation.
Call operation action with the dynamicAssembler keyword applied	The transformation generates the following items: In the BPEL process, a BPEL invoke activity An SCDL component of implementation type dynamic assembler A wire between the BPEL process SCDL component and the dynamic assembler SCDL component
Call operation action with the humanTask keyword applied	The transformation generates the following items: In the BPEL process, a BPEL inline human task activity A human task configuration file (.itel)
Opaque action	The transformation creates a BPEL assign activity when the name of the operation uses an expression such as lvalue:= rvalue, where the lvalue sets a BPEL `to` variant and the rvalue sets a BPEL `from` variant. For multiple assignments, you can use a semicolon (;) as a separator: `aVar:=bVar ; cVar:=dVar` The transformation creates a BPEL Java snippet when the language property of the action is set to Java, and the value of the body property that is associated with the action is placed in the snippet. The transformation creates an empty BPEL human task when the language property of the action is set to HTML or JSP.
In a UML component, an opaque behavior with the dynamicAssembler keyword applied	The transformation generates the following items: An SCDL component of implementation type dynamic assembler A dynamic assembler configuration file (.dac)
In a UML component, an opaque behavior with the humanTask keyword applied	The transformation generates the following items: An SCDL component of implementation type human task A human task configuration file (.itel)
Send signal action	The transformation generates a BPEL invoke activity. The operation of the BPEL invoke activity corresponds to the reception of the SignalAction::signal property. The partner is generated by using the name of the target input pin when the name of the pin is not empty. Otherwise, the transformation uses the ActivityPartition::represents property. The operation container must be a required interface in one of the ports through which it sends the events. The target pin name must match the port name when the pin name is not empty. Or the value of the ActivityPartition::represents property must be either a port or the type of a port.
Input pin	The transformation examines input pin elements when the owner of the input pin is an instance of an AcceptCallAction, CallOperationAction, or OpaqueAction action. The number of input pins must be the same as the [in] parameters of the operation that is associated with the action that owns the input pin. An additional input pin must represent the «target» input pin only when the action is an instance of CallOperationAction. If an input pin is not connected to an activity by an object flow edge, the name of the pin must correspond to an activity parameter, variable, or attribute in the activity or the component that owns the activity.
Output pin	The transformation examines OutputPin elements when the owner of the output pin is an instance of an AcceptCallAction, CallOperationAction, or OpaqueAction action. When the action is an instance of CallOperationAction or AcceptCallAction, the number of pins must match the [out] parameters of the operation that is associated with the action that owns the output pin. When the action is an instance of AcceptCallAction, an additional output pin must represent the Return Information property for the action that owns the pin. If the output pin is not connected to an activity by an object flow edge, the pin must have a valid name that corresponds to an activity parameter, variable, or attribute in the activity or the component that owns the activity. If the output pin does not have any incoming or outgoing object flow edges, the transformation uses the corresponding BPEL variable to create a BPEL output parameter for the corresponding operation that is associated with the action that owns the pin.
Control flow	The transformation creates a BPEL sequence and creates links for concurrency control.
Object flow	The transformation creates a BPEL sequence and creates links for concurrency control. If necessary, the transformation generates variables based on the object flow name. The generated name is applied if the name of the object flow is empty.

Transformation of UML components that contain an opaque behavior without owned UML activities

If a SOA transformation encounters a UML component that does not have any owned activities and has an opaque behavior that contains a link to a BPMN process that implements the provided services, the transformation transforms the BPMN elements into corresponding elements in a BPEL file.

In a BPMN event that contains multiple triggers, the transformation processes only the first supported trigger that it encounters.

The following table shows how UML elements and BPMN elements in a referenced BPMN process map to output in a generated BPEL file.

UML elements	Transformation output in the generated BPEL file
Component that contains an owned behavior that contains a link to a BPMN process	The transformation creates a BPEL process with the same name as the component. The namespace for the BPEL process and associated WSDL artifacts file includes an element for the component and the packages that the component contains.
Provided interfaces in a component that contains an owned behavior that contains a link to a BPMN process	The transformation generates WSDL files for each interface, and also generates partner links that have a myRole specification.
Required interfaces in a component that contains an owned behavior that contains a link to a BPMN process	The transformation generates WSDL files for each interface, and also generates partner links that have a partnerRole specification.

The following table shows how the transformation transforms BPMN elements in the referenced BPMN process.

BPMN elements in the BPMN process referenced by an opaque behavior in a component	Transformation output in the generated BPEL file
Start event that does not contain triggers	A BPEL receive activity that does not contain any details is generated.
Start event that contains a message event definition trigger whose MessageEventDefinition::Operation property references a BPMN operation	A BPEL receive activity is generated. The port type, WSDL operation, and output variables are derived from the WSDL file that corresponds to the BPMN interface that contains the referenced operation. The Receive::createInstance property is set to `true`.
Start event that contains a message event definition trigger whose MessageEventDefinition::Operation property references a UML operation	A BPEL receive activity is generated. The port type, WSDL operation, and output variables are derived from the WSDL file that corresponds to the UML interface that contains the referenced operation. The Receive::createInstance property is set to `true`.
Start event with timer event trigger	A BPEL event handler is created at the BPEL process level. An on alarm activity is added to the event handler. The `for` and `until` expressions contain the values of the TimerEventDefinition::timeDate and TimerEventDefinition::timeCycle properties in the source model. TimerEventDefinition::timeDate property must be in the format of year, month, day, as in the following example: `yyyy,mm,dd` TimerEventDefinition::timeCycle property must be in the format of hour, minute, and second, as in the following example: `hh,mm,ss` Note: If the BPMN model contains multiple timer events, the transformation transforms only the first one in the list of triggers.
Intermediate catch event that does not have any triggers	A BPEL empty activity is generated.
Intermediate catch event with a message event definition trigger whose MessageEventDefinition::Operation property references a BPMN operation	A BPEL receive activity is generated. The port type, WSDL operation, and output variables are derived from the WSDL file that corresponds to the BPMN interface that contains the referenced operation. The Receive::createInstance property is set to `false`.
Intermediate catch event with a message event definition trigger whose MessageEventDefinition::Operation property references a UML operation	A BPEL receive activity is generated. The port type, WSDL operation, and output variables are derived from the WSDL file that corresponds to the UML interface that contains the referenced operation. The Receive::createInstance property is set to `false`.
Intermediate catch event with a timer event trigger	A BPEL wait activity is generated at the BPEL scope level. The `for` and `until` expressions contain the values of the following triggers in the source model: TimerEventDefinition::timeDate property, which must be in the format of Year, Month, Day, as in the following example: `yyyy,mm,dd` TimerEventDefinition:: timeCycle property, which must in the format of Hour, Minute and Second, as in the following example: `hh,mm,ss` Note: If the BPMN model contains multiple timer events, the transformation transforms only the first one in the list of triggers.
Intermediate throw event that does not have any triggers	A BPEL empty activity is generated.
Intermediate throw event with a message event definition trigger whose MessageEventDefinition::Operation property references a BPMN operation	A BPEL invoke activity is generated. The port type, WSDL operation, and output variables are derived from the operation in the WSDL file that corresponds to the BPMN interface that contains the referenced operation.
Intermediate throw event with a message event definition trigger whose MessageEventDefinition::Operation property references a UML operation	A BPEL invoke activity is generated. The port type, WSDL operation, and output variables are derived from the operation in the WSDL file that corresponds to the UML interface that contains the referenced operation.
End event that does not contain a message event definition trigger	When the end event is part of the flow that begins with a start event with a message event definition trigger, a BPEL reply activity is generated. The port type, WSDL operation, and input variables are derived from the WSDL file that corresponds to the BPMN interface. This BPMN interface contains the StartEvent::MessageEventDefinition::operation property. If the end event is not part of this flow, the transformation generates a BPEL empty action.
End event that contains a message event definition trigger whose MessageEventDefinition::Operation property references a BPMN operation	A BPEL reply activity is generated at the end of the scope that corresponds to the BPEL receive activity. The port type, WSDL operation, and input variables are derived from the WSDL file that corresponds to the BPMN interface that contains the referenced operation.
End event that contains a message event definition trigger whose MessageEventDefinition::Operation property references a UML operation	A BPEL reply activity is generated at the end of the scope that corresponds to the BPEL receive activity. The port type, WSDL operation, and input variables are derived from the WSDL file that corresponds to the UML interface that contains the referenced operation.
Service task whose ServiceTask::Operation property references a BPMN operation	A BPEL invoke activity is generated. The port type, WSDL operation, and output variables are derived from the operation in the WSDL file that corresponds to the BPMN interface that contains the referenced operation. The Receive::createInstance property is set to `false`. If the associated WSDL operation contains a fault message, a BPEL fault handler that contains a BPEL empty activity is created in the invoke activity.
Service task whose ServiceTask::Operation property references a UML operation	A BPEL invoke activity is generated. The port type, WSDL operation, and output variables are derived from the operation in the WSDL file that corresponds to the UML interface that contains the referenced operation. The Receive::createInstance property is set to `false`. If the associated WSDL operation contains a fault message, a BPEL fault handler that contains a BPEL empty activity is created in the invoke activity.
Exclusive gateway	The transformation creates the following items: BPEL switch statement BPEL cases for each outgoing flow. The BPEL condition element is set for each BPEL case if the outgoing flow contains a condition expression. The default outgoing flow is translated into a BPEL otherwise activity.
Inclusive gateway	If the gateway has a default outgoing flow, the transformation creates the following items: BPEL switch statement BPEL cases for each outgoing flow. The BPEL condition element is set for each BPEL case if the outgoing flow contains a condition expression. The default outgoing flow is translated into a BPEL otherwise activity. If the outgoing flow does not contain a default flow, the transformation generates BPEL links for each outgoing flow. If the sequence flow contains condition expressions, the transformation generates a BPEL condition in the BPEL link.
Exclusive gateway	The transformation creates the following items: BPEL switch statement BPEL cases for each outgoing flow. The BPEL condition element is set for each BPEL case if the outgoing flow contains a condition expression. The default outgoing flow is translated into a BPEL otherwise activity.
Parallel gateway	A BPEL flow is generated. For each outgoing flow, a BPEL sequence is generated.
Data object	A BPEL variable is generated at the BPEL process level.

Feedback