Transient BPEL Process
Transient processes do not incur dehydration during their
process execution. If an executing process experiences an un-handled fault or
the server crashes, instances of a transient process do not leave a trace in
the system. Thus, these instances cannot be saved in-flight regardless if they
complete normally or abnormally. Transient processes are typically short-lived,
request-response style processes. Synchronous processes are examples of
transient processes.
Durable BPEL Process
Durable processes incur one or more dehydration points in the
database during execution. Dehydration is triggered by one of the following
activities:
- Receive activity
- OnMessage branch in a pick activity
- OnAlarm branch in a pick activity
- Wait activity
- Reply activity
- checkPoint() within a <bpelx:exec> activity
Durable processes are typically long-living and initiated through a one-way invocation. Because of out-of-memory and system downtime issues, durable processes cannot be memory-optimized.
XA Transaction
- An XA transaction, in the most general terms, is a "global transaction" that may span multiple resources.
- An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction.
- XA transactions come from the X/Open group specification on distributed, global transactions. JTA includes the X/Open XA spec, in modified form.
Non-XA Transaction
- A non-XA transaction always involves just one resource.
- Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).
- Most stuff in the world is non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database.
targetNamespace
targetNamespace
is the namespace that is going to be assigned to the schema you are creating.
It is the namespace an instance is going to use to access the types it
declares. In the following code, the schema will be assigned to the
namespace http://www.example.com/test/po
<schema
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.example.com/test/po">
...
</schema>
defaultNamespace
xmlns=”” or namespace–
Defines the default namespace within the current document for all non-prefixed
elements. XML Schema is an XML document, it is then possible to define a
default XML namespace for the XML file itself (this is what xmlns attribute
does); the implications are multiple: authoring, and composition. For example,
one does not have to use a prefix for the items defined in the schema, that are
later on referenced elsewhere in the same file (e.g. a global simpleType used
as a type for an attribute or element).
<purchaseOrder
xmlns="http://www.example.com/test/po"
xmlns:addr="http://www.example.com/test/po/addr">
<accountName>abc</accountName>
<accountNumber>12345</accountNumber>
<addr:street>xyz</addr:street>
</purchaseOrder>
In an XML document instance, you declare the
namespaces you are going to be using by means of the xmlns attribute.
The default namespace here is
http://www.example.com/test/po, which
makes reference to the schema previously created. This namespace applies to the
element that declares it, and its child elements, unless they are prefixed. In
the example, all the elements belong to the default namespace, except
addr:street. Since it is prefixed, it belongs to the addr namespace
(xmlns:addr=" http://www.example.com/test/po/addr")
When to go for SOA & When to go for OSB
- For service virtualization and brokering activities use OSB
- For long running and stateful orchestrated tasks, use Oracle BPEL
- For automate business activities based on a process definition use Oracle BPEL
- For incorporating Human Workflow and/or Oracle Business Rules, use Oracle BPEL PM
- For applying policy-centralization and reliable-messaging techniques on web-services, use OSB
- For stateless and short-lived web-service orchestrations use OSB
- For synchronous entity-based services or pass-through operations use OSB
Conclusion: Based on individual business needs decision should be made.
xsd:import:
- It is used to refer to declarations or definitions that are in a different target namespace.
- The import element is used to add multiple schema's with different target namespace to a document.
xsd:include:
- It is used to refer to declarations or definitions that are in the same target namespace.
- Include element is used to add multiple schemas with same target namespace to a document.
Pipeline Components (Nodes)
Start Node - Every pipeline begins with a start node. All messages enter the pipeline through the start node, and all response messages are returned to the client through the start node. There is nothing to configure in a start node.
Pipeline Pair Node - A pipeline pair node combines a single request pipeline and a single response pipeline in one top-level element. A pipeline pair node can have only one direct descendant in the pipeline. During request processing, only the request pipeline is executed when Service Bus processes a pipeline pair node. The execution path is reversed when Service Bus processes the response pipeline.
Stage - Request pipelines, response pipelines, and error handlers can contain stages, where you configure actions to manipulate messages passing through the pipeline.
Error Handler - An error handler can be attached to any node or stage, to handle potential errors at that location.
Operational Branch - Operational branching is supported for WSDL-based services, where the branching is based on operations defined in the WSDL file.
Conditional Branch - Conditional branching is supported for conditions defined in an XPath-based switch table.
Route - A route node performs request/response communication with another service or component. It represents the boundary between request and response processing for the pipeline. When the route node dispatches a request message, the request processing is considered complete. When the route node receives a response message, the response processing begins. The route node supports conditional routing as well as request and response transformations. Because a route node represents the boundary between request and response processing, it cannot have any descendants in the pipeline
Start Node - Every pipeline begins with a start node. All messages enter the pipeline through the start node, and all response messages are returned to the client through the start node. There is nothing to configure in a start node.
Pipeline Pair Node - A pipeline pair node combines a single request pipeline and a single response pipeline in one top-level element. A pipeline pair node can have only one direct descendant in the pipeline. During request processing, only the request pipeline is executed when Service Bus processes a pipeline pair node. The execution path is reversed when Service Bus processes the response pipeline.
Stage - Request pipelines, response pipelines, and error handlers can contain stages, where you configure actions to manipulate messages passing through the pipeline.
Error Handler - An error handler can be attached to any node or stage, to handle potential errors at that location.
Operational Branch - Operational branching is supported for WSDL-based services, where the branching is based on operations defined in the WSDL file.
Conditional Branch - Conditional branching is supported for conditions defined in an XPath-based switch table.
Route - A route node performs request/response communication with another service or component. It represents the boundary between request and response processing for the pipeline. When the route node dispatches a request message, the request processing is considered complete. When the route node receives a response message, the response processing begins. The route node supports conditional routing as well as request and response transformations. Because a route node represents the boundary between request and response processing, it cannot have any descendants in the pipeline
- Last node in request processing. It can be thought of as a bridge between request pipeline processing and the response pipeline processing.
- You can only execute one route in your Proxy Service.
- Can only be created in a route node.
- OSB will wait for the Route call to finish before continuing to process.
- If you are calling a Business service and you specify Best Effort for QoS (Quality of Service), then OSB will release the thread it is holding while the business service executes.
- If you are calling a Business service and you specify Exactly Once or At Least Once for QoS, then OSB will hold onto the thread while the business service executes.
- If you are calling a local Proxy service, then OSB will hold onto the thread until the Proxy service finishes executing.
Rest Branch - Since Un-Typed REST services does not use WADL, we can’t use Operational Branch as above. So in this release, OSB introduced a new node called REST Branch for this purpose.
Route Actions
Dynamic Routing - It is a kind of the Content-based Routing pattern, which is used when the Business Service endpoint is required to be determined at run time. Assign a route for a message based on routing information available in an XQuery resource
Routing - It is used when the Business Service endpoint is established during design time. Identify a target service for the message and configure how the message is routed to that service
Routing Table - A routing table is a set of routes wrapped in a switch-style condition table. It is a short-hand construct that allows different routes to be selected based upon the results of a single XQuery expression.
Communication Actions
Service Callout
Route Actions
Dynamic Routing - It is a kind of the Content-based Routing pattern, which is used when the Business Service endpoint is required to be determined at run time. Assign a route for a message based on routing information available in an XQuery resource
Routing - It is used when the Business Service endpoint is established during design time. Identify a target service for the message and configure how the message is routed to that service
Routing Table - A routing table is a set of routes wrapped in a switch-style condition table. It is a short-hand construct that allows different routes to be selected based upon the results of a single XQuery expression.
Communication Actions
Service Callout
- Can have multiple Service Callout nodes in a Proxy service.
- Pipeline processing will continue after a Service Callout.
- Can be invoked from the request and/or response pipelines.
- Used to enrich the incoming request or outgoing response. For example, a call to get a country code.
- Used for real time request/response calls (Synchronous calls).
- OSB will hold a thread and not continue until the Service Callout completes.
- Can tie up resources and degrade performance under heavy loads.
- Well, Service Callout in OSB is similar to Invoke activity in SOA. We use Invoke activity in SOA to trigger external services like (WS Service, DB Service, JMS Service, FTP Service etc). Similarly we use Service Callout in OSB to trigger external services.
- Similarities & differences b/w Invoke & Service Callout: Both used to trigger external services, but Invoke can be used for both Synchronous& Asynchronous external services (i.e the calling external service may or may not give the response). But Service Callout is used only to trigger Synchronous external services. To trigger one way services there is another component in OSB which is ‘Push’ which also works same as Service Callout, only difference is Push is used for triggering One way external services and Service Callout is used for triggering Synchronous external services. Invoke activity will be having ‘Input Variable’ and ‘Output variable’ and similarly Service Callout will also has ‘Request Variable’ & ‘Response Variable’.
Publish
- Can be synchronous or asynchronous
- If you are calling a business service with a Quality of Service of Best Effort , then it will be an asynchronous call.
- If you call a business service with a Quality of Service of Exactly Once or At Least Once, OSB will wait until the processing completes in the business service completes before proceeding and it is effectively a synchronous call.
- If you are calling a local proxy service, OSB will wait until the processing in the local proxy service completes and it is effectively a synchronous call.
- Can be invoked from the request and/or response pipelines.
- Best to use when you do not need to wait for a response from the process you are calling (Fire and Forget.... Asynchronous Calls).
Dynamic Publish - Publish a message to a service specified by an XQuery expression.
Routing Options - Modify any or all of the following properties in the outbound request: URI, Quality of Service, Mode, Retry parameters, Message Priority.
Transport Headers - Used to set the header values in messages.
Message Processing Actions
Assign - Assign the result of an XQuery or XSLT expression to a context variable.
Delete - Delete a context variable or a set of nodes specified by an XPath expression
Insert - Insert the result of an XQuery or XSLT expression at an identified place relative to nodes selected by an XPath expression.
Java Callout - Invoke a Java method from within the pipeline.
MFL Translate - Convert message content from XML to non-XML, or vice versa, in the message pipeline. An MFL is a specialized XML document used to describe the layout of binary data. It is an Oracle proprietary language used to define rules to transform formatted binary data into XML data, or vice versa.
nXSD Transalte - Convert message content from XML to native format data, or vice versa, in the message pipeline.
Rename - Rename elements selected by an XPath expression without modifying the contents of the element.
Replace - Replace a node or the contents of a node specified by an XPath expression. The node or its contents are replaced with the value returned by an XQuery expression. A replace action can be used to replace simple values, elements and even attributes. An XQuery expression that returns nothing is equivalent to deleting the identified nodes or making them empty, depending upon whether the action is replacing entire nodes or just node contents. The replace action is one of a set of Update actions.
Validate - Validate elements selected by an XPath expression against an XML schema element or a WSDL resource. You can validate global elements only; Service Bus does not support validation against local elements.
Reporting Actions
Alert - Generate alerts based on message context in a pipeline, to send to an alert destination. Unlike SLA alerts, notifications generated by the alert action are primarily intended for business purposes, or to report errors, and not for monitoring system health. Alert destination should be configured and chosen with this in mind. If pipeline alerting is not enabled for the service or enabled at the domain level, the configured alert action is bypassed during message processing
Log - Construct a message to be logged and to define a set of attributes with which the message is logged.
Report - Enable message reporting for a pipeline. An XQuery/XSLT expression is used to create the data that is reported to the Service Bus dashboard.You use key value pairs to extract key identifiers from any message context variable or message payload, and ignore the rest of the message.
Flow Control Actions
For Each - Iterate over a sequence of values and execute a block of actions.
If..Then - Perform an action or set of actions conditionally, based on the Boolean result of an XQuery expression.
Raise Error - Raise an exception with a specified error code (a string) and description.
Reply - Specify that an immediate reply be sent to the invoker. The reply action can be used in the request, response or error pipeline. You can configure it to result in a reply with success or failure. In the case of reply with failure where the inbound transport is HTTP, the reply action specifies that an immediate reply is sent to the invoker
Resume - Resume message flow after an error is handled by an error handler. This action has no parameters and can only be used in error handlers.
Skip - Specify that at runtime, the execution of this stage is skipped and the processing proceeds to the next stage in the pipeline. This action has no parameters and can be used in the request, response or error pipelines.
Message Processing Actions
Assign - Assign the result of an XQuery or XSLT expression to a context variable.
Delete - Delete a context variable or a set of nodes specified by an XPath expression
Insert - Insert the result of an XQuery or XSLT expression at an identified place relative to nodes selected by an XPath expression.
Java Callout - Invoke a Java method from within the pipeline.
MFL Translate - Convert message content from XML to non-XML, or vice versa, in the message pipeline. An MFL is a specialized XML document used to describe the layout of binary data. It is an Oracle proprietary language used to define rules to transform formatted binary data into XML data, or vice versa.
nXSD Transalte - Convert message content from XML to native format data, or vice versa, in the message pipeline.
Rename - Rename elements selected by an XPath expression without modifying the contents of the element.
Replace - Replace a node or the contents of a node specified by an XPath expression. The node or its contents are replaced with the value returned by an XQuery expression. A replace action can be used to replace simple values, elements and even attributes. An XQuery expression that returns nothing is equivalent to deleting the identified nodes or making them empty, depending upon whether the action is replacing entire nodes or just node contents. The replace action is one of a set of Update actions.
Validate - Validate elements selected by an XPath expression against an XML schema element or a WSDL resource. You can validate global elements only; Service Bus does not support validation against local elements.
Reporting Actions
Alert - Generate alerts based on message context in a pipeline, to send to an alert destination. Unlike SLA alerts, notifications generated by the alert action are primarily intended for business purposes, or to report errors, and not for monitoring system health. Alert destination should be configured and chosen with this in mind. If pipeline alerting is not enabled for the service or enabled at the domain level, the configured alert action is bypassed during message processing
Log - Construct a message to be logged and to define a set of attributes with which the message is logged.
Report - Enable message reporting for a pipeline. An XQuery/XSLT expression is used to create the data that is reported to the Service Bus dashboard.You use key value pairs to extract key identifiers from any message context variable or message payload, and ignore the rest of the message.
Flow Control Actions
For Each - Iterate over a sequence of values and execute a block of actions.
If..Then - Perform an action or set of actions conditionally, based on the Boolean result of an XQuery expression.
Raise Error - Raise an exception with a specified error code (a string) and description.
Reply - Specify that an immediate reply be sent to the invoker. The reply action can be used in the request, response or error pipeline. You can configure it to result in a reply with success or failure. In the case of reply with failure where the inbound transport is HTTP, the reply action specifies that an immediate reply is sent to the invoker
Resume - Resume message flow after an error is handled by an error handler. This action has no parameters and can only be used in error handlers.
Skip - Specify that at runtime, the execution of this stage is skipped and the processing proceeds to the next stage in the pipeline. This action has no parameters and can be used in the request, response or error pipelines.
No comments:
Post a Comment