src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
Microsoft BizTalk Server consists of two main services: BizTalk Messaging Services
(an asynchronous model that appears synchronous—so called "sync on async. )through which you send messages between business processes, and BizTalk Orchestration Services through which you create your business processes.
BizTalk Messaging Services is responsible for
Receiving incoming documents, Parsing the documents to determine their specific format and transforming to xml.
Extracting key identifiers and identifying specific routing rules .
Delivering documents to their respective destinations and tracking .
BizTalk Orchestration Services is responsible for
integration of long-running business processes with the applications that run those business processes as long as weeks or months, not just minutes or hours without any need to write custom code to manage the state of your business process;
Orchestration seems to like an Orchestra where so many different technology (musical instruments ) are integrated (blended ) in such a way they produce long running (very big time period )logical sequence of business processes (melodious music).
http://download.microsoft.com/documents/australia/windowsserversystem/biztalk2006/Understanding_BTS06.pdf
(an asynchronous model that appears synchronous—so called "sync on async. )through which you send messages between business processes, and BizTalk Orchestration Services through which you create your business processes.
BizTalk Messaging Services is responsible for
Receiving incoming documents, Parsing the documents to determine their specific format and transforming to xml.
Extracting key identifiers and identifying specific routing rules .
Delivering documents to their respective destinations and tracking .
BizTalk Orchestration Services is responsible for
integration of long-running business processes with the applications that run those business processes as long as weeks or months, not just minutes or hours without any need to write custom code to manage the state of your business process;
Orchestration seems to like an Orchestra where so many different technology (musical instruments ) are integrated (blended ) in such a way they produce long running (very big time period )logical sequence of business processes (melodious music).
http://download.microsoft.com/documents/australia/windowsserversystem/biztalk2006/Understanding_BTS06.pdf
Persistence points
The orchestration engine saves the state of a running orchestration instance at various points. If the engine must rehydrate the orchestration instance, start from a controlled shutdown, or recover from an unexpected shutdown, the engine runs the orchestration instance from the last persistence point, as if nothing else had occurred. For example, if a message is received and if an unexpected shutdown occurs before the state can be saved, the engine does not record that it has received the message. Instead, the engines receives the message again after it restarts. The engine saves the state of an orchestration in the following circumstances:
•
The end of a transactional scope is reached.
•
The engine saves the state at the end of a transactional scope. Therefore, the point at which the orchestration resumes is defined unambiguously. Compensation can be performed correctly, if it is necessary.
•
The engine saves the state at the end of a transactional scope. Therefore, the point at which the orchestration resumes is defined unambiguously. Compensation can be performed correctly, if it is necessary.
•
The orchestration continues to run from the end of the scope if persistence was successful. Otherwise, the appropriate exception handler is invoked.
•
If the scope is transactional and atomic, the engine saves the state at the end of the atomic scope when the scope commits.
•
If the scope is transactional and long-running, the engine generates a new transaction and persists the complete state of the runtime when the scope is completed.
•
A debugging breakpoint is reached.
•
A message is sent. The only exception to this is when a message is sent from an atomic transaction scope.
•
The orchestration starts another orchestration asynchronously, as it does with the Start Orchestration shape.
•
The orchestration instance is suspended.
•
When the orchestration engine is asked to shut down, the orchestration engine tries to save control information and the current state of all running orchestration instances. This behavior lets the orchestration engine resume running orchestration instances when the engine is started again. If the orchestration engine cannot save the current state, the orchestration engine resumes the orchestration instance from the last persistence point that occurred before the shutdown. This behavior applies to the system shutdown in a controlled condition and after an abnormal termination.
•
The engine determines that the instance should be dehydrated.
•
The orchestration instance is finished
I will discuss about recieve port and adapters in the next issue
The orchestration engine saves the state of a running orchestration instance at various points. If the engine must rehydrate the orchestration instance, start from a controlled shutdown, or recover from an unexpected shutdown, the engine runs the orchestration instance from the last persistence point, as if nothing else had occurred. For example, if a message is received and if an unexpected shutdown occurs before the state can be saved, the engine does not record that it has received the message. Instead, the engines receives the message again after it restarts. The engine saves the state of an orchestration in the following circumstances:
•
The end of a transactional scope is reached.
•
The engine saves the state at the end of a transactional scope. Therefore, the point at which the orchestration resumes is defined unambiguously. Compensation can be performed correctly, if it is necessary.
•
The engine saves the state at the end of a transactional scope. Therefore, the point at which the orchestration resumes is defined unambiguously. Compensation can be performed correctly, if it is necessary.
•
The orchestration continues to run from the end of the scope if persistence was successful. Otherwise, the appropriate exception handler is invoked.
•
If the scope is transactional and atomic, the engine saves the state at the end of the atomic scope when the scope commits.
•
If the scope is transactional and long-running, the engine generates a new transaction and persists the complete state of the runtime when the scope is completed.
•
A debugging breakpoint is reached.
•
A message is sent. The only exception to this is when a message is sent from an atomic transaction scope.
•
The orchestration starts another orchestration asynchronously, as it does with the Start Orchestration shape.
•
The orchestration instance is suspended.
•
When the orchestration engine is asked to shut down, the orchestration engine tries to save control information and the current state of all running orchestration instances. This behavior lets the orchestration engine resume running orchestration instances when the engine is started again. If the orchestration engine cannot save the current state, the orchestration engine resumes the orchestration instance from the last persistence point that occurred before the shutdown. This behavior applies to the system shutdown in a controlled condition and after an abnormal termination.
•
The engine determines that the instance should be dehydrated.
•
The orchestration instance is finished
I will discuss about recieve port and adapters in the next issue
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
