This section introduces the basic building blocks of a SwitchYard application starting from an empty application and building up to the complete application you see below:
Each topic includes a representation in the SwitchYard visual editor and the corresponding metadata from the SwitchYard application descriptor (switchyard.xml). The snippet of XML from the descriptor is provided for context only - you do not have to view or edit XML descriptors when creating SwitchYard applications.
A composite is displayed as a light blue rectangle and represents the boundary between what's inside your application and what's outside your application. A SwitchYard application consists of exactly one composite that has a name and a targetNamespace. The targetNamespace value is important as it allows names defined locally in the application (e.g. service names) to be qualified and unique within a SwitchYard runtime.
A component is a modular container for application logic and consists of the following:
- 0 or 1 component service definitions
- 0 to many component reference definitions
- 1 implementation
Services and references allow a component to interact with other components, while the implementation provides the actual logic for providing and/or consuming services.
An implementation acts as the 'brain' of a service component and it is how implement your application logic. The following implementation options are available:
- Bean : allows a CDI Bean to consume or provide services using annotations.
- Camel : EIP-style routing and service composition using the XML or Java DSL in Apache Camel.
- BPMN 2 : service orchestration and human task integration expressed as BPMN 2 and executed using jBPM
- BPEL Process : web service orchestration using the OASIS Business Process Execution Language
- Rules : decision services based on Drools
Implementations are private to a component, which means external consumers and providers are not aware of the details of a component's implementation (implementation-hiding). All interactions with other components within an application and with external services are handled through component services and references.
A component service is used to expose the functionality of an implementation as a service. All component services have a contract, which can be a Java interface, WSDL portType definition, or a set of named data types (interface.esb). Component services are private to an application, which means a component service can only be invoked by other components in the same application. In order to expose a component service to consumers external to the application, a component service can be 'promoted' to a composite service. A component service can be promoted multiple times to create different composite services.
A composite service represents an application service which is visible to other applications. A composite service can only be realized by promoting a component service within the application. The name and the interface of the composite service can be different from the component service. If the interface, or contract, of the composite service is different from the component service, be aware that a transformation may be required to map between the types defined in each interface. In our example application, the component service has a Java interface while the composite service has a WSDL interface. This means we would need to declare a transformer which maps between XML and Java to resolve the data type mismatch. For more information on transformation, see the Transformers section of the Developer Guide.
A service binding is used to define an access method for a composite service. Composite services can have multiple bindings, which allows a single service to be accessed in different ways. In most cases, a service binding represents a protocol/transport adapter (e.g. SOAP, JMS, REST). An important exception to this rule is the SCA binding, which allows services across applications in the same runtime to be wired together in memory. Regardless of the underlying binding details, a binding must always be used to facilitate inter-application communication in SwitchYard.
A component reference allows a component to consume other services. A component reference can be wired to a service offered by another component in the same application or it can be wired to services outside the application via a composite reference. Similar to component services, all component references have a contract with allows a component to invoke services without knowing implementation or binding details. The picture below shows an example of wiring a reference on the Routing component to a service offered by the Bean component.
A composite reference allows a component reference to be wired to a service outside the application. Similar to composite services, bindings are used with composite references to specify the communication method for invoking the external service.
A reference binding is used to define an access method for an external service via a composite reference. Unlike service bindings, there can only be one binding for each composite reference. The set of bindings available for references is identical to the set of bindings available for services, although the configuration values for a given binding may be different depending on whether it's used as a service binding or a reference binding.