Table 3: Project and Component Migration
Required Actions Migration Output
Input Object
None.
Composites, Shared Resources, and
Deployment Packages migrated to the correct SOA Project
special folder type, but folders are not renamed.
Abstract component
Topic • Change the type of the abstract component
to a valid component and implement as appropriate.
This component type is not supported in 3.x.
.NET
Component • Abstract component
• Change the type of the abstract component to a valid component and implement as appropriate.
• Wires between .NET components are not migrated and the corresponding
component services and references are not
migrated to the abstract component. • Recreate missing component services, references, and wires.
Not supported:
Java
Component • If you want to be able to regenerate the
component implementation, convert the
• @Service annotation generated for a Java
component with Out-* MEP. 2.x class structure to the 3.x class structure following the procedure in the appendix
• @Reference annotation for an Out-*
reference:
@Reference
OutInPT referenceName1 = new
Converting Migrated Java Component Implementations of Java Component Development.
org.example.www.outin.OutInPT(){
public OutInOperationDocument • Update the package names of
SOAPException and SOAPDetail to
com.tibco.amf.platform.runtime.
extension.exception.
outInOperation(
OutInOperationResponseDocument parameters){
//..
}
}; • Update the package names of
EndpointReference, and
ReferenceParameters to
com.tibco.amf.platform.runtime.
extension.exception.
• Update the package names of
WsAddressingConstants to
com.tibco.amf.spline.api.constants.
WsAddressingConstants.
• Extract header properties from
com.tibco.amf.platform.runtime.extension.
context.MutableRequestContext instead of HashMap.
• Extract WS-Addressing properties from
com.tibco.amf.platform.runtime.extension.
context.MutableRequestContext instead of HashMap.
Required Actions Migration Output
Input Object
• If you use the class
org.osoa.sca.ComponentContext, open the Java plug-in manifest in the manifest editor, go to Dependencies tab and add the import package: org.osoa.sca. Mediation
Component • Update these mappings to match their 3.x
environment as it relates to dynamic endpoint references.
• Context Mechanism In 3.x the context parameters are defined on the
component/composite/implementation service & reference.
Context Parameters - Context parameters defined as a simple type in 2.x are
• Add the correct policy.
migrated as context properties with the same direction and of type that is the Java equivalent of the 2.x schema type.
Parameters defined at the output level are copied to the fault level after migration.
Transport and Security context - Transport context properties are migrated as context parameters of type bag. The HTTP headers are migrated as HttpHeader of type bag.
The JMS properties are separated during migration into JmsHeaders and
JmsProperties. Security context is migrated as a mediation parameter of type security.
• Set Context Task Mapping of 2.x context parameters is retained and mapped accurately.
• Set Dynamic Reference Task The Set Dynamic Task Endpoint Reference mechanism was changed from 2.x to 3.x by using Application Name & Service Name (3.x) instead of Service Name &
Service Namespace (2.x). The Set Dynamic Reference task uses a mapper to set these values. The migration attempts to preserve these mappings even though the semantics of the dynamic routing have changed.
• End Task The value of the End Type property has changed from error to Stop Message Delivery and now mandates the configuration of a ’At-least-once’ policy at the mediation operation level.
• Query Database Task Shared resources profile references defined in the Query Database task are migrated as property references.
• Timeout Faults Mediation Flows 3.x contain a timeout fault path for all target operations. Mediation Flows 2.x do not contain this fault path which is
automatically added during migration.
Table 4: Service and Reference Migration
Required Actions Migration Output
Input Object SOAP/HTTP
Service • Create an HTTP Connector and install
instance on node prior to deployment.
• Promoted service with SOAP binding
• If transport type is HTTPS, transport type
is HTTP • If transport type was HTTPS, configure
HTTP Connector for SSL.
• Connector Name property set to resource profile name or to httpConnector. .
• If Enable WS-Addressing and Anonymous checked in binding, the binding is configured with policy set
"WSAddressingPolicyForService_BindingName
• If Enable WS-Reliable Messaging checked in binding, the binding is configured with policy set "WSRMPolicy_BindingName
None.
SOAP/JMS
Service • Promoted service with SOAP binding
• JMS Connection Factory, JMS Connection Factory Configuration, JMS Destination, JNDI Connection Configuration
None.
SOAP/HTTP
Reference • Promoted reference with SOAP binding
• If the binding pointed to an HTTP Client Shared Resource, an HTTP Client.
None.
SOAP/JMS
Reference • Promoted reference with SOAP binding
• JMS Connection Factory, JMS Destination (inbound), JMS Destination (outbound), JNDI Connection Configuration
The project will migrate but will result in a composite that is not supported.
SOAP Reference with
• Convert reference to a supported binding type.
Third-Party Binding
None.
AMX Service • Promoted service with Virtualization binding.
• If a port type was set on the service then the name for the generated Virtualization binding will match the name of the port type. Otherwise, the name of the Virtualization binding will be Virtualization.
AMX
Reference • Promoted reference with Virtualization • binding.
Wire the applications at deploy time using Administrator or create a wrapping composite with components of type composite wired together.
• If a port type was set on the reference then the name for the generated Virtualization binding will match the name of the port type. Otherwise, the name of the Virtualization binding will be Virtualization.
Required Actions Migration Output
Input Object
JMS Service • Promoted service with JMS binding • Configure generated JMS resource templates to point to JNDI Connection Configuration.
• JMS Connection Factory Configuration
• JMS Connection Factory
• JMS Destination Configuration
• JMS Destination
• JNDI Connection Configuration
• JMS target address is mapped to JMS Destination Configuration
• JMS reply address is mapped to JMS Destination
Promoted reference with JMS binding
JMS Reference • Configure generated JMS resource
templates to point to JNDI Connection Configuration.
• Promoted service with JMS binding
• JMS Connection Factory Configuration
• JMS Connection Factory
• JMS Destination Configuration
• JMS Destination
• JNDI Connection Configuration
• JMS target address is mapped to JMS Destination Configuration
• JMS reply address is mapped to JMS Destination
See TIBCO ActiveMatrix Binding Type for Adapters Binding Development.
Adapter Reference
See TIBCO ActiveMatrix Binding Type for EJB Binding Development.
EJB Reference
Table 5: Shared Resource Migration
Required Actions Migration Output
Input Object JMS Shared
Resource • If connection type is direct, create a JNDI
Connection Configuration.
• JMS Connection Factory
• JMS Connection Factory Configuration
• Configure generated JMS resource templates to point to JNDI Connection Configuration.
• If connection type is JNDI, a JNDI Connection Configuration
JNDI Shared
Resource • Rename resource template if shared
resource name contained a space.
• JNDI Connection Configuration
• If the resource contained an identity, an Identity Provider and an empty Keystore Provider.
• Configure the Keystore Provider.
3
Composites
As described in the SCAAssembly specification, a composite is a configuration of services comprising an application that conforms to a service-oriented architecture. A composite contains components, services, references, the wires that interconnect them, and properties that are used to configure the components. Composites can be nested (contained by other composites). A root composite equates to an SCA application.
The constituents of a composite can run in a single process on a single computer or be distributed across multiple processes on multiple computers. A complete application might be constructed from just one composite or it could combine several different composites. The components making up each composite can be implemented using different technologies. Figure 1: Composite on page 43 depicts a composite and illustrates the relationships between composite elements.
Figure 1: Composite
You edit composites in the TIBCO Business Studio Composite Editor depicted in Figure 2: Composite Editor on page 44.
Figure 2: Composite Editor
By default, composite files are stored in the Composites special folder in an SOA project.
Topics
• Creating a Composite
• Setting Composite Diagram Preferences
• Adding An Element to a Composite
• Application Modularization
• Running and Debugging a Composite
• Composite Reference
Related Topics
Packaging a Composite in a DAA on page 240