2. Xlang
• (XML LANGuage) An XML-based language for
defining business processes from Microsoft.
• XLANG is used in Microsoft's BizTalk Server.
• based on the WSDL language with extensions that describe
behavior.
3. Xlang (contd..)
• It provides both the model of an orchestration of services as well
as collaboration contracts between orchestrations.
• Serves as the basis for automated protocol engines that can track
the state of process instances and help enforce protocol correctness
in message flows.
• Aims to specify all the behavior and only the behavior that the
participant explicitly wants partners to understand in designing
their own service processes.
4. WSDL issues
• Ports and Port Types:
WSDL 1.1 does not offer a way to group the ports.
for maximum interoperability, inclusion of the feature in
WSDL would be desirable.
• Outgoing operations:
WSDL provides the outgoing operations of notification and
solicit/response.
the definition of these operations in WSDL 1.1 is incomplete
and the interpretation of some aspects is unclear.
5. Relationship with WSDL
• XLANG has a two-fold relationship with WSDL:
1. XLANG service description is a WSDL service
description with an extension element that describes
the behavior of the service as a part of a business
process.
2. XLANG service behavior may also rely on simple
WSDL services as providers of basic functionality for
the implementation of the business process.
6. Xlang Data Types
• Data types include Boolean, Byte, Char, Decimal,
Double, Int16, Int32, Int64, SByte, Single, String,
UInt16, UInt32, and UInt64.
• XLANG/s supports single-dimensional arrays.
• Does not support array literals.
• XLANG/s also has rich support for message handling.
• Messages can be based on schemas, .NET classes, Web
message types (WSDL), or complex message types.
7. Xlang Data Types (contd..)
• XLANG/s supports complex data types :
1. messagetype – defines multipart message types which are
defined as combinations of data elements and XSD-based
messages and Method- Message types.
2. porttype - defines a collection of port operations.
3. correlationsettype - defines the data that will be used in any
instance of a correlation set variable.
4. Servicelinktype - defines the set of porttype values that form
a logically consistent group of ports used in a business process.
9. Rules to be followed
• All names beginning with __ (double under-score) are
reserved in XLANG/s.
• XLANG/s identifiers may be no more than 511 characters
long.
• Lines of XLANG/s code may be no more than 2040
characters long
10. Xlang Statements
• XLANG/s statements generally fall into one of
two categories :
simple statements that act on their own, such as
receive or send.
complex statements that contain or group either
simple statements or other complex statements,
such as scope, parallel, and listen.
11. Xlang Statements (contd..)
group - Used to group operations into a single collapsible
and expandable unit for visual convenience.
send -Used to send a specified message to a specified port.
receive - Used to wait for the receipt of a specified
message from a specified port.
Port - Defines where and how messages are transmitted.
12. Xlang Statements (contd..)
role link - Used to create a collection of ports that
communicate with the same logical partner, perhaps
through different transports or endpoints.
Transform - Used to map the fields from existing
messages into new messages.
message assignment - Used to send a specified message to
a specified port.
13. Xlang Statements (contd..)
construct message- Defines a block of XLANG/s code
where a message is created and Initialized.
call orchestration-Synchronously calls from one
orchestration to another orchestration.
start orchestration-Used to enable your orchestration to
call another orchestration Asynchronously.
14. Xlang Statements (contd..)
• Compensate - Used to explicitly invoke a compensation
block associated with a given scope.
• Terminate - Forcibly and irrevocably stops all processing
in a schedule.
• call rules - Enables you to configure a Business Rules
policy to be executed in your orchestration.
16. Instance Initiation And Termination
• A service with a behavior represents an interaction spanning
many operations.
• Those interactions are instances of service.
• An instance can be started in two ways :
1. explicitly by some background functionality
2. implicitly by specially marked operations
• An operation that serves to start a new service instance must be
marked with an activation attribute with a value of true.
• It is known as activation operation.
• Default value of the activation attribute is false.
17. Actions
• Actions are the atoms of behavior.
• The four WSDL operations at port types can be used as
XLANG actions.
• Actions in XLANG = operations of WSDL
• XLANG defines some additional actions
Operation
Delay
Raise
18. Operations
• These actions simply reference WSDL operations on the
available ports
• Example :
<action operation="AskLastTradePrice“
port="pRequest" activation="true"/>
19. Delays
• The delayFor action causes the thread of behavior within
which it occurs to pause for the specified time interval.
• The delay duration is meant to represent a non-negative
value of type duration.
• Example :
<delayFor
period="SupplyChain:OrderAcknowledgementTimeout"/>
20. Delays (contd..)
• delayUntil is similar to delayFor except that it causes the
thread of behavior within which it occurs to pause until the
specified absolute time has been reached.
• The delay expiration is meant to represent a value of type
dateTime.
• Example :
<delayUntil
clock="SupplyChain:ShippingDeadline" />
21. Signaling Exceptions
• An exceptional condition is explicitly signaled by the raise
action.
• optionally takes a QName representing the condition as a
parameter.
• Example :
<raise signal="creditCheck:creditDenied">
22. Basic Control Processes
• Processes combine actions together in useful ways.
• Processes are
1. empty
2. sequence
3. switch
4. while
5. all
6. pick
23. empty
• The simplest process is the empty process that contains no
actions.
• completes as soon as it has begun
• Example :
<empty/>
24. Sequence Control
• A sequence contains zero or more actions or processes
which are executed serially.
• The sequence concludes when its final action or process has
finished.
• Example :
<xlang:sequence>
<xlang:action operation="AskLastTradePrice“/>
<xlang:action operation="SendLastTradePrice"/>
</xlang:sequence>
25. Switch Control
• supports conditional behavior
• The branches of the switch are considered in the order in
which they appear.
• The conditions in a switch are opaque
• Conditions are represented by Qnames.
27. While Control
• looping is provided by the while construct.
• A specified process is executed until the given condition no
longer holds true.
• Example :
<while xmlns:protocol="http://protocol.org/retry/">
<case> protocol:retryEnabled </case>
<sequence> ...
<!-- retry some behavior -->
</sequence>
</while>
28. All Control
• executes each of the specified sub-processes concurrently.
• In order to avoid race conditions between sub-processes in
all, the use of common ports for operations across different
subprocesses is disallowed.
• Example :
<all>
<sequence> <!-- perform airline reservation -->
</sequence>
<sequence><!-- perform car reservation --> </sequence>
<sequence> <!-- perform hotel reservation --></sequence>
</all>
29. Pick Control
• The pick process form awaits the arrival of one of a set
of events and then executes a process form associated
with that message.
• set of branches of the form event/process.
• exactly one of the branches will be selected based on the
occurrence of the event associated with it.
• If more than one of the events occurs there is a race and the
choice of branch to be executed is dependent on both
timing and implementation.
30. Pick Control (contd..)
<pick>
<eventHandler>
<action operation="inputLineItem">
<sequence> <!-- add line item to order --> </sequence>
</eventHandler>
<eventHandler>
<action operation="receiveOrderCompletion">
<sequence> <!-- perform order completion routine -->
</sequence>
</eventHandler>
</pick>
31. Message Properties
• Business protocol messages often carry values of special
interest in the protocol.
• A purchase order document may carry a purchaseorder
number.
• XPath in combination with XML Schema definitions is used
to define properties.
• Message definitions in WSDL do not permit an extension
element.
• XML schema does permit annotations.
32. Message Properties (contd..)
<complexType name="purchaseOrder"
xmlns:po="http://myNamespace">
<annotation>
<appInfo>
<xlang:propertyDef name="po:orderNumber"
path="./purchaseOrder/orderNumber"/>
</appInfo>
</annotation>
<element name="orderNumber" type="decimal"/>
<!-- the rest of the PO -->
</complexType>
33. Message Correlation
• XLANG addresses correlation scenarios by specifying correlated
groups of operations within a service instance.
• A set of correlation tokens can be defined as a set of properties
shared by all messages in the correlated group.
• Such a set of properties is called a correlation set.
• The set of operations (in a single service) that is correlated via a
correlation set is called a correlation group.
• Correlation groups are themselves instantiated and terminated .
34. Defining Correlation Sets And
Groups
• Correlation sets declare a named group of properties.
• A given operation may participate in multiple correlation
groups.
• Example :
<correlation name="CustomerKeys">
POProps:CustomerNumber POProps:OrderNumber
</correlation>
35. Contexts
• The context process form provides a framework for local
declarations as well as exception handling and transactional
behavior.
• Contexts includes
1. LOCAL DECLARATIONS
2. EXCEPTION HANDLING
36. Local Declarations
• allows local declaration of correlation sets and port
references.
• If local declarations are provided, the contained process is
executed in a local naming scope.
• The correlation sets and port references declared locally are
only visible within the context process (or in its exception
or compensation blocks).
37. Exception Handling
• The optional exception block attached to a context provides
a way to define a set of custom exception handling
processes.
• A finally block optionally follows the pick, and provides a
convenient way to design exception handling code that is
common to all exceptional cases.
38. Exception handling(contd..)
<context> non-transactional context
<sequence> ... normal context process here </sequence>
<exception>
<pick> <delayFor period="PT100S"/>
<!-- timeout behavior -->
<action operation="receiveCancelMessage"/>
<!-- cancel behavior -->
<catch code="PO:OutOfStock"/>
<!-- out of stock behavior -->
</pick>
<finally>
<!-- send a message to a monitoring app to
notify it that an exception occurred -->
</finally>
</exception>
</context>
39. Business Process Contracts
• contracts do not support any business related semantics.
• mapping between two port types which interact together.
• if your business relationship requires a request followed by
a response, they cannot belong to the same contract.
• A contract can only map ports which are "unidirectional":
an input only port will map to an output only port.
42. Future extensions
• Enabling executable business processes.
• Reuse of parameterized behavior.
• Autonomous sub-behaviors.
• Dynamic partner enlistment.
43. Advantages of Xlang
• Sequential and parallel control flow constructs
• Long running transactions with compensation
• Custom correlation of messages
• Flexible handling of internal and external exceptions
• Modular Behavior Description
• Dynamic service referral
• Multi-role contracts
