...SwitchYard concepts and terms

Hi,

For a some time right now, I'm up to learn Red Hat's new SOA platform, that is called Fuse Service Works. There is not much information about this product and it's internals, so I have decided to start publishing information about it as I learn myself my way.

In this post, I'm talking about SwitchYard concepts and terms.

SwitchYard is the execution engine of the SOA platform. It is based on SCA, and you can find documentation about it, although on a basic stage, at SwitchYard official documentation

There are some basic concepts that need to be understood from the internals of SwitchYard. These are the main classes that are in there.

org.switchyard.Exchange: An Exchange represents an instance of a service invocation with a specific message exchange pattern (e.g. InOnly, InOut).  Exchange provides a conduit for the messages that flow into and out of a service  as part of a service invocation.  Unlike messages, an exchange cannot be copied and reused across service invocations.  State associated with  an invocation (i.e. context) is maintained at the exchange level.

org.switchyard.Message: A Message represents an individual input or output of a service, the content of which is interpreted by service implementation logic.  A Message does not carry context specific to a service invocation, which means that it can be copied and reused across service invocations. There are two distinct parts to a message:

• Content: the main body, or payload, of the message. There is only one body per message instance. The message body is mutable, so message processing logic can access the content, change it (transform, enrich, etc.), and then set it back on the message.
• Attachments: provide the ability to associate content with a message separate from  the main body, allowing it to be parsed independently. One example  would be a binary image that is referenced by the main body of the message.  The attachment may be too large to be processed in certain services or the service implementation may not be able to  parse/interpret it.

org.switchyard.Context: Holds contextual information around the exchange of messages between a service consumer and provider.

org.switchyard.Service: A service registered with the SwitchYard runtime.

org.switchyard.ServiceReference: A service registered with the SwitchYard runtime.

org.switchyard.ServiceDomain: A ServiceDomain represents a collection of services with a shared set of resources, configuration, and policy definitions.  The ServiceDomain interface is used by software components to provide and/or consume services.  These software components include protocol gateways, service containers, translation engines, adapters, orchestration and routing engines.

org.switchyard.ExchangeState: Represents the state of an Exchange (OK, FAULT)

org.switchyard.ExchangePhase: Represents the phase of an exchange. (INPUT or OUTPUT)

org.switchyard.ExchangeHandler: The role of a Handler is to handle messages and fault events during the course of a service invocation.  When consuming a service, a handler can be registered during Exchange creation to handle consumer events (e.g. fault or reply message).  When providing a service, a handler is specified while registering the service to process invocations of that service.

org.switchyard.ExchangePattern: The list of supported exchange patterns within SwitchYard. (IN_ONLY, IN_OUT)

org.switchyard.metadata.ExchangeContract: Two-way Exchange contract, detailing the requirements of both the consumer and provider ServiceOperation being invoked.

org.switchyard.metadata.ServiceOperation: Representation of an operation on a ServiceInterface. Each operation has:

•  an exchange pattern (IN_OUT, IN_ONLY)
•  a name
•  an input message referenced type
•  an (optional) output message type
•  an (optional) fault message type

The mapping of operation and message names is defined by the concrete implementation of ServiceInterface.  For example, the expected mapping of a Java interface would be Java method name to ServiceInterface operation name.

org.switchyard.metadata.ServiceInterface: The canonical representation of a service interface in SwitchYard.  Every service in SwitchYard is registered with exactly one ServiceInterface, providing information on the type, operations, and input/output messages for the service. The SwitchYard runtime provides concrete implementations of ServiceInterface for Java and WSDL interface types. There is also a default type of *ServiceInterface.DEFAULT_TYPE* which is used to represent services which do not publish a formal contract.

org.switchyard.ServiceMetadata:  Contains runtime details on services and service references registered in SwitchYard.  Instances of ServiceMetadata can be created and updated using the ServiceMetadataBuilder class

There are some more, and I'll try to update this post, as a reference as I get more info.

Graphically, these classes and their relations can be seen here (click to see a larger picture):

SwitchYard core classes