Applications created with LightSwitch support exporting data to Microsoft Office Excel for fast and easy sharing and reporting. You can also attach your application to existing data sources, which makes it easy to collect, analyze, and reuse information from a variety of data sources including Microsoft SQL Server, Microsoft SQL Azure, SharePoint, Microsoft Office Access (post-Beta), and other third-party data sources.

With LightSwitch you can create custom applications for the way you do business. Keep your technology and business options open, while building a practical yet scalable application that matches your current needs now and in the future. The pre-built templates and components in LightSwitch are fully extensible, so you can get the specific functionality your application demands. In addition, your application can grow to meet the increasing demands of popular applications using the Microsoft Windows Azure Cloud Hosting option.

Lets discuss each of the section in detail

SOAP Envelope is outer most section of WCF message. It acts as a container for WCF header and body. A SOAP envelope contains several pieces of key information in the form of elements. They include the following:

• The name of envelope
• Namespace name : The namespace name must be “http://www.w3.org/2003/05/soap-envelope”.
• An optional <header> element: SOAP header is a collection of one or more than one header block. A SOAP message can contain zero or more than one header block. If a header is included, it must be the first child element of the envelope element. Header is  good place to put optional information related to message. Any child element of header element is called “Header Blocks”.  The following code sample illustrates the basic format for including a message header:
  <env:Envelope xmlns:s=”http://www.w3.org/2003/05/soap-envelope” xmlns:a=”http://schemas.xmlsoap.org/ws/2004/08/addressing”>
  <env:Header>
  </env:Header>
  </env:Envelope>
• A required body element. : The SOAP body is a collection of data items to be used at a specific target (SOAP receiver). Like the SOAP header, a message can contain zero or more bodies.

WCF Messaging Programs

In WCF ,following type of applications can send and receive messages

• Client: Client is a program that initiates a communication via sending a message
• Service: Service is program that respond to a message. Service perform predefined activities once it receives a message. A service never initiates a communication. While processing request , if the service call some other services than this concept is called “Service chain”. Here the service is acting as client and service has initiated the communication in response to incoming message.

Messaging Patterns

Messaging patterns, basically describe how programs should exchange messages. There are three basic messaging patterns that programs can use to exchange messages. Those patterns include the following:

• Simplex : The Simplex message pattern is simply a one-way communication from Program A to Program B. No response is generated by Program B, thus causing the one-way communication. Simplex messaging suffers from short term memory loss. When the client sends the message, it has no idea it sent a message because it is not expecting a response.
• Duplex: In duplex pattern client and service programs communicate openly and exchange information in both directions.
• Request-Reply: Request-Reply messaging pattern doesn’t allow bi-directional communication to happen freely. In this pattern, the client sends a response and then waits for reply. The service doesn’t communicate anything until it receives a message.

About this Video

Windows Azure in an open platform. This means you can run applictions written in .NET, PHP, or Java. In this video Scott Golightly will show how to create and run an application written in Java in Windows Azure. We will create a simple Java application that runs under Apache Tomcat and then show how that can be packaged up and deployed to the Windows Azure development fabric.

To protect ASP.NET applications, you can restrict access to resources and the operations that they can perform. You do this by setting the <trust> element to a predefined trust level in either the machine-level Web.config file or the application’s Web.config file.

The following list describes the predefined trust levels:

Full 

Applications that run at Full trust level can execute arbitrary native code in the process context in which they run. Because of the inherent risks that come with running in Full trust mode, this mode is not recommended in a shared environment except when every Web site uses its own application pool and application pool identity.

Important   The default trust level is Full trust. You should evaluate the security requirements for your environment and set the trust level appropriately.

High 

Code in High trust applications can use most .NET Framework permissions that support partial trust. This mode is often appropriate for trusted applications that you want to run with fewer user rights in order to mitigate risks. For example, this level provides the same access as Full trust, but restricts access to unmanaged code and COM interop.

Medium

Code in Medium trust applications can read and write in its own application directories and can interact with Microsoft SQL Server™ databases. However, by default, the user rights that are needed to access OLE DB and ODBC are not granted to Medium trust applications. Medium trust is the recommended setting for a shared server, because it allows connections to SQL Server databases and restricts most other user rights to the application root structure.

Low 

Code in Low trust applications can read its own application resources but cannot make any out-of-process calls, such as calls to a database, to the network, and so on. By using Low trust, you effectively lock applications down to their application directory and remove all access to system resources.

Minimal

Code in Minimal trust applications can execute but cannot interact with any protected resources. Minimal trust may be appropriate for mass hosting sites that want to support dynamic generation of Hypertext Markup Language (HTML) and isolated business logic.

The definition of the trust levels is essentially the same from ASP.NET version 1.1 through version 4. However, some of the user rights or operations that can be granted at each trust level vary slightly. For example, in ASP.NET 2.0 and later, Medium trust code can enable access to OLE DB APIs.

For information about how to run ASP.NET applications in a hosted environment, including trust levels and code access security, download the Microsoft Solution for Windows-based Hosting version 3.5 tool kit from the Microsoft download center. For information about hosting environments and architecture, see the Hosting Guidance for the Microsoft Web Platform on the IIS.net Web site.

Backup Script

BACKUP DATABASE  database_name  TO DISK = ‘C:\example.bak’ WITH FORMAT;

Restore Script

RESTORE DATABASE ‘DATABASE_NAME’ FROM DISK =’C:\EXAMPLE.BAK’