SharePoint : Sandboxed Solutions vs. Farm Solutions

We are almost close to end of this year and in this year I have only wrote 6 posts in SharePoint. I have not touched any SharePoint projects for like last 10 months and now I feel like I don’t know SharePoint at all. So it’s time to start learning SharePoint again, otherwise in couple of months I will ended up being a total stranger to SharePoint.

Today I am going to write about Sandbox solutions and Farm solutions. When you are creating any SharePoint solution using Visual Studio, you are prompted to select the Trust Level of the solution which is either a Sandboxed solution or a farm solution.

Select the Trust Level

Which is either you can deploy the solution directly into the Server farm or into a sandbox. So what really is this deploying to sandbox or deploying to server farm? We are about to find it out.

Sandboxed Solution

Before learning what is a Sandboxed solution, we should learn what is a Sandbox. A sandbox is a testing environment that enables programs to access only certain resources, and that keeps problems/issues that occur in the sandbox from affecting the rest of the server environment. Basically what it does is sandbox isolates untested code from the working environment.

So when we are deploying a solution as a sandboxed solution, the solution  cannot access content outside the site collection they are deployed in. The sandboxed solution will not be able to use certain computer and network resources. Since the sandboxed solution is scoped to the site collection, we don’t really need a farm administrator to deploy the solution. A site collection administrator can do the deployment.

Sandboxed solutions are hosted in the SharePoint user code solution worker process (SPUCWorkerProcess.exe). Because sandboxed solutions do not run in the IIS worker process, neither the IIS application pool nor the IIS server must restart.

Mainly we can’t create following as a sandboxed solution.

• Application pages.
• Visual web parts.
• Code-based workflows.

The following is a list of the most common things a solution running inside a sandbox cannot do,

• Connect to resources that are not located on the local farm.
• Access a database.
• Call unmanaged code.
• Write to disk.
• Access resources in a different site collection.
• Change the threading model.

Farm Solution

The Features in farm solutions can have scope as wide as the site collection, web application, or the whole SharePoint farm. Since Farm solutions can be scoped to Farm level, we need a Farm Administrator to deploy the solution and the assemblies in the solution always run with full trust.

Unlike sandboxed solutions, Farm solutions are are hosted in the IIS worker process (W3WP.exe) and the code in the farm solutions can affect the whole farm. When you try to retract or deploy a farm solution, the whole application pool will be recycled.

Farm solutions should be used for customizations of SharePoint administrative functions, such as custom timer jobs, custom Windows PowerShell cmdlets, and extensions of Central Administration.

For more information,
     What Can Be Implemented in Sandboxed Solutions in SharePoint 2010
     Sandboxed Solutions

Hope this helps.

Happy Coding.

Regards,

Jaliya

Introduction to Transactions in WCF

Couple of months back I have blogged about SQL Server Transactions. Last few days I have spent some quality time with the book Professional WCF 4: Windows Communication Foundation with .NET 4 and today I am going to write about what I learnt about Transactions in WCF. Since most of the things in this post will be theoretical things, you might feel bored. But I am sure, you will find some pretty interesting things here.

A transaction is a set of operations, in which if single operation fails, the entire set of operations are set to fail, as one atomic operation. Transactions are the best way to maintain consistency in a system. Let’s take a look at the following scenario where the system is transferring from state A to state B, as a result of series of operations.

States of a Transaction

In here State A and B are two consistent states. Before the transaction, the system is on State A and after completing the transaction the systems’ state changes into B.

When considering the above scenario, there can be three transaction types. Committed, Aborted and In-Doubt transaction. If the transaction manages to successfully transfer the system from State A to State B, then it is a Committed Transaction. If the transaction did not manage to transfer the system from State A to State B, and returned to State A, then it is an Aborted Transaction. Finally If the transaction failed to either commit or abort, then it is an In-Doubt transaction.

WCF services can work directly against any transactional resource. WCF also provides a programming model (as on offered by ADO.NET) to manage the transaction explicitly.

Mainly transactions have these four properties which are abbreviated as ACID.

• Atomic
  • Atomic means that all the work in the transaction is treated as a single unit. That is either all statements in the unit must execute, or no statement in the unit must execute.
• Consistent
  • Consistent means that a completed or roll backed transaction leaves the system in a consistent internal state. A transaction will convert the system from a known starting state to a known ending state. If the transaction commits, the database will be at the known ending state. If the transaction fails, the system will be at the known starting state.
• Isolated
  • Isolation means that the transaction sees the system in a consistent state. If two transactions try to update the same resource, one will go first and then the other will follow. Transactions are committed independently from each other and they are transparent to each other.
• Durability
  • Durability means that the results of the transaction are permanently stored in the system and ensures that the result or effect of a committed transaction persists in case of a system failure.

WCF Transactions

Distributed Transactions

A distributed transaction contains two or more independent services or even just a single service with two or more transactional resources. Let’s take the following design. We have an infrastructure where a client communicates with multiple services and these services interact with each other and with multiple resources.

Distributed Transaction

In here, we are facing two questions determining,

1. Who will start the transaction and how others are going to know about the initiator? If everyone started transactions there will be many transactions.
2. Who will instruct the transaction to either to commit or rollback?

In this kind of distributed transaction if you try to write the logic for transaction management, you will not be able to concentrate on your systems' logic. So you will need to rely on something. Now comes the Two-Phase Commit Protocol and the Transaction Manager to the picture. A transaction manager is a third party and will manage the transaction of the clients and services for you. Transaction manager takes the decision either to commit or rollback based on a transaction management protocol which is the two-Phase Commit protocol.

Transaction protocols used in Bindings

WCF chooses transaction management protocol based on the execution scope of the participating parties in the transaction. Please note that since I am using the term protocol here, this has nothing to do with two-Phase Commit protocol. These are used in bindings as the values for transactionProtocol.

1. The Lightweight protocol
   • This protocol is used to manage transactions in a local context only, inside the same application domain.
   • The lightweight protocol is used only inside a service.
   • Never between services.
   • No binding supports the lightweight protocol.
2. The OleTx protocol
   • This protocol is used to propagate transactions across application domain, process, and machine boundaries, and to manage the two-phase commit protocol.
   • Windows-Specific / Only in Windows environment.
   • Cannot be used across firewalls or to interoperate with Non-Windows parties.
   • TCP and IPC (Inter Process Communication) bindings uses OleTx protocol as the default and will switch to the WSAT protocol if required.
3. The WS-Atomic Transaction (WSAT) protocol
   • Same as OleTx protocol.
   • Can be used across firewalls.
   • Non Windows-Specific.
   • The WS bindings are designed for use across the Internet, when multiple transaction managers are involved, using the WSAT protocol. (In an Internet scenario where only a single transaction manager is involved, these bindings will default to the OleTx protocol.)

Transaction Manager

WCF can work with three different transaction managers which are Lightweight Transaction Manager (LTM), the Kernel Transaction Manager (KTM), and the Distributed Transaction Coordinator (DTC). .NET will assign the appropriate transaction manager based on the platform used, what the application does, the services it calls, and the resources it consumes. Since the transaction manager is assigned automatically, the code is decoupled from the transaction management and from the transaction protocol used.

1. Lightweight Transaction Manager (LTM)
   • Can only manage local transaction (inside a single application domain).
   • Can only manage a transaction inside a single service, and only when the service does not flow the transaction to other services.
   • Uses the lightweight transaction protocol to manage the two-phase commit protocol.
   • Most performing transaction manager.
2. Kernel Transaction Manager (KTM)
   • Can be used to manage transactional kernel resource managers (KRMs) on Windows Vista, Windows Server 2008, and Windows 7 or later-specifically, the transactional files system (TxF) and the transactional registry (TxR).
   • Uses the lightweight transaction protocol.
3. Distributed Transaction Coordinator (DTC)
   • Can manage transactions across any execution boundary, from the most local (a transaction within the same application domain) scope to the most remote (a transaction that crosses process, machine, or site boundaries).
   • Use either the OleTx or the WSAT protocol.
   • The DTC is the transaction manager used when transactions flow across the service boundary.
   • The DTC is a system service available by default on every machine running WCF, and WCF (and .NET) is tightly integrated with the DTC.

Two-Phase Commit Protocol

As the name means, this protocol has two phases.

1. Commit Request / Voting
   • In this phase transaction manager requests the votes from all the participants to start a transaction.
   • Every participant replies with either Commit or Abort.
   • Once a vote has been made, it cannot be reversed.
2. Commit / Complete
   • If every participant vote is for commit, then transaction is instructed to commit.
   • If single participant has voted to abort, then the transaction is instructed to abort and rollback.

Transaction Propagation

WCF can propagate transactions across the service boundary. Because of this, a one or more services can participate in a client’s transaction. In here client can be either a WCF or any other application. Both the binding and the operation contract take the decision on whether to or not to propagate on the client’s transaction. Only the TCP, IPC, and WS bindings have the ability to propagate client’s transactions.

Now comes the practical things, so I will stop now. Hope you all got a good understanding about these and will see these in action in a coming post.

Happy Coding.

Regards,

Jaliya

Presentation : Windows Communication Foundation (Part 1)

Conducted a session at iOM World about Windows Communication Foundation (WCF). Thought to introduce web services first, so this session was mainly targeted on Web Services though the heading was on WCF.

Windows communication foundation (part1) from Jaliya Udagedara

Happy Coding.

Regards,
Jaliya