WCF! (Abstract From WCF Professional)

WCF Architecture [Abstract from Professional WCF Programing]

At the heart of WCF is a layered architecture that supports a lot of the distributed application development styles.Figure 1-3illustrates the layered architecture of Windows Communication Foundation.

Figure 1-3

This layered architecture, which provides developers a new service-oriented programming model, is discussed in detail in the following sections.

Contracts

WCF contracts are much like a contract that you and I would sign in real life. A contract I may sign could contain information such as the type of work I will perform and what information I might make available to the other party. A WCF contract contains very similar information. It contains information that stipulates what a service does and the type of information it will make available.

Given this information, there are three types of contracts: data, message, and service. More detailed information about contracts is given in Chapter 6, so consider this a primer.

Data

A data contract explicitly stipulates the data that will be exchanged by the service. The service and the client do not need to agree on the types, but they do need to agree on the data contract. This includes parameters and return types.

Message

A message contract provides additional control over that of a data contract, in that it controls the SOAP messages sent and received by the service. In other words, a message contract lets you customize the type formatting of parameters in SOAP messages.

Most of the time a data contract is good enough, but there might be occasions when a little extra control is necessary.

Service

A service contract is what informs the clients and the rest of the outside world what the endpoint has to offer and communicate. Think of it as a single declaration that basically states "here are the data types of my messages, here is where I am located, and here are the protocols that I communicate with."

There is a bit more to it than this, and Chapter 6 covers this in greater detail. But for now, suffice it to say that a service contract is one or more related message interactions.

Policy and Binding

Remember the SOA principles discussed earlier? Remember the one that discusses policies? Here is where they come into play. Policy and binding contracts specify important information such as security, protocol, and other information, and these policies are interrogated looking for the things that need to be satisfied before the two services start communicating.

Service Runtime

The Service Runtime layer is the layer that specifies and manages the behaviors of the service that occur during service operation, or service runtime (thus "service runtime behaviors"). Service behaviors control service type behaviors. They have no control over endpoint or message behaviors. Likewise, endpoint and message behaviors have no control over service behaviors.

The following lists the various behaviors managed by the Service Runtime layer:

• q Throttling Behavior: The Throttling behavior determines the number of processed messages.

• q Error Behavior: The Error behavior specifies what action will be taken if an error occurs during service runtime.

• q Metadata Behavior: The Metadata behavior controls whether or not metadata is exposed to the outside world.

• q Instance Behavior: The Instance behavior drives how many instances of the service will be available to process messages.

• q Message Inspection: Message Inspection gives the service the ability to inspect all or parts of a message.

• q Transaction Behavior: The Transaction behavior enables transacted operations. That is, if a process fails during the service runtime it has the ability to rollback the transaction.

• q Dispatch Behavior: When a message is processed by the WCF infrastructure, the Dispatch Behavior service determines how the message is to be handled and processed.

• q Concurrency Behavior: The Concurrency behavior determines how each service, or instance of the service, handles threading. This behavior helps control how many threads can access a given instance of a service.

• q Parameter Filtering: When a message is acted upon by the service, certain actions can be taken based on what is in the message headers. Parameter Filtering filters the message headers and executes preset actions based on the filter of the message headers.

Messaging

The Messaging layer defines what formats and data exchange patterns can be used during service communication. Client applications can be developed to access this layer and control messaging details and work directly with messages and channels.

The following lists the channels and components that the Messaging layer is composed of:

• q WS Security Channel: The WS Security channel implements the WS-Security specification, which enables message security.

• q WS Reliable Messaging Channel: Guaranteed message delivery is provided by the WS Reliable Messaging channel.

• q Encoders: Encoders let you pick from a number of encodings for the message.

• q HTTP Channel: The HTTP channel tells the service that message delivery will take place via the HTTP protocol.

• q TCP Channel: The TCP channel tells the service that message delivery will take place via the TCP protocol.

• q Transaction Flow Channel: The Transaction Flow channel governs transacted message patterns.

• q NamedPipe Channel: The NamedPipe channel enables inter-process communication.

• q MSMQ Channel: If your service needs to interoperate with MSMQ, this is the channel that enables that.

Activation and Hosting

The Activation and Hosting layer provides different options in which a service can be started as well as hosted. Services can be hosted within the context of another application, or they can be self-hosted. This layer provides those options.

The following list details the hosting and activation options provided by this layer:

• q Windows Activation Service: The Windows Activation Service enables WCF applications to be automatically started when running on a computer that is running the Windows Activation Service.

• q .EXE: WCF allows services to be run as executables (.EXE files).

• q Windows Services: WCF allows services to be run as a Windows service.

• q COM+: WCF allows services to be run as a COM+ application.

Experiments with SilverLight 2.0 - Part I

Que: Why?

Ans: The goal of Silverlight is to bring the same fidelity and quality found in the user interfaces(UIs) associated with desktop applications to Web applications, allowing Web developers and designers to build applications for their clients’ specific needs. It is designed to bridge the technology gap between designers and developers by giving them a common format in which to work. This format will be rendered by the browser and will be based on XML, making it easy to template and to generate automatically. The format is XAML—Extensible Application Markup Language.

Que: Installing Silverlight?
Ans: Here

Que: How does it work?
Ans:

Que: How to relate a silverlight app with some web application?
Ans: Its taken care by the .xap file. I can talk more about it, later.
Refer Here.


Que: can we dynamically create a silverlight control?
Ans: Yes.

function handleLoad(control, userContext, sender){
var xamlFragment = "[textblock top='60' text='A new TextBlock'][/textblock]"
var textBlock = control.content.createFromXaml(xamlFragment);
sender.children.add(textBlock);

Que: How can i use Asp.net Ajax to fetch data for silverlight control?Ans:
* Using direct webservice call from js.
* Using WebClient and WebResponse.
* Using WCF.

Que: Silverlight and WCF?
Ans: Refer WCF.

Que: How to work with Windows Communication Foundation?
Ans: Refer Msdn

Que: Can i we use silverlight contro on a normal html page?

Ans: Yes. It is just a plugin (

Que: how to debug xaml files? can i use breakpoints?

SOA Part-II

Service-Oriented Architecture Principles [Abstract from Professional WCF Programming]

Streams of information have been flowing from Microsoft in the forms of articles and white papers regarding its commitment to SOA, and in all of this information one of the big areas constantly stressed are the principles behind service orientation:

• q Explicit boundaries

• q Autonomous services

• q Policy-based compatibility

• q Shared schemas and contracts

Explicit Boundaries

As you will learn in the next section, SOA is all about messaging—sending messages from point A to point B. These messages must be able to cross explicit and formal boundaries regardless of what is behind those boundaries. This allows developers to keep the flexibility of how services are implemented and deployed. Explicit boundaries mean that a service can be deployed anywhere and be easily and freely accessed by other services, regardless of the environment or development language of the other service.

The thing to keep in mind is that there is a cost associated with crossing boundaries. These costs come in a number of forms, such as communication, performance, and processing overhead costs. Services should be called quickly and efficiently.

Autonomous Services

Services are built and deployed independently of other services. Systems, especially distributed systems, must evolve over time and should be built to handle change easily. This SOA principle states that each service must be managed and versioned differently so as to not affect other services in the process.

In book publisher example, the Order Process service and Order Fulfillment service are completely independent of each other; each is versioned and managed completely independent of the other. In this way, when one changes it should not affect the other. It has been said that services should be built not to fail. In following this concept, if a service is unavailable for whatever reason or should a service depend on another service that is not available, every precaution should be taken to allow for such services to survive, such as redundancy or failover.

Policy-Based Compatibility

When services call each other, it isn't like two friends meeting in the street, exchanging pleasantries, and then talking. Services need to know a little more about each other. Each service may or may not have certain requirements before it will start communicating and handing out information. Each service has its own compatibility level and knows how it will interact with other services. These two friends in fact aren't friends at all. They are complete and total strangers. When these two strangers meet in the street, an interrogation takes place, with each person providing the other with a policy. This policy is an information sheet containing explicit information about the person. Each stranger scours the policy of the other looking for similar interests. If the two services were to talk again, it would be as if they had never met before in their life. The whole interrogation process would start over.

This is how services interact. Services look at each others' policy, looking for similarities so that they can start communicating. If two services can't satisfy each others' policy requirements, all bets are off. These policies exist in the form of machine-readable expressions.

Policies also allow you to move a service from one environment to another without changing the behavior of the service.

Shared Schemas and Contracts

Think "schemas = data" and "contracts = behavior." The contract contains information regarding the structure of the message. Services do not pass classes and types; they pass schemas and contracts. This allows for a loosely coupled system where the service does not care what type of environment the other service is executing on. The information being passed is 100 percent platform independent. As described previously, a service describes it capabilities.

Some of the benefits of SOA:

• q Services are platform and location independent. A service does not care where the service is located, and it does not care about the environment of another service to be able to communicate with it.

• q Services are isolated. A change in one service does not necessitate a change in other services.

• q Services are protocol, format, and transport neutral. Service communication information is flexible.

• q Services are scalable. Remember the book publisher example?

• q Service behavior is not constrained. If you want to move the location of the service, you only need to change the policy, not the service itself.

  
  

SOA!!!

Some Notes ( An abstract from Wiki ):

SOA depends on data and services that are described using some implementation of metadata that should meet the following two criteria:

1. the metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity
2. the metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort

SOA as an architecture relies on service-orientation as its fundamental design principle^[6]. If a service presents a simple interface that abstracts away its underlying complexity, users can access independent services without knowledge of the service's platform implementation^[7].

SOA relies on services exposing their functionality via interfaces that other applications and services can read to understand how to utilize those services.

Designers can implement SOA using a wide range of technologies, including SOAP, REST, RPC, DCOM, CORBA, Web Services or WCF(Microsoft's implementation of Webservice forms a part of WCF). SOA can be implemented using one or more of these protocols and, for example, might use a file-system mechanism to communicate data conforming to a defined interface-specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.

SOA enables the creation of applications that are built by combining loosely coupled and interoperable services. These services inter-operate based on a formal definition (or contract, e. g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service.

SOA-based systems can therefore function independently of development technologies and platforms (such as Java, .NET etc). Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as Web services that facilitates reuse. Managed environments can also wrap COBOL legacy systems and present them as software services. This has extended the useful life of many core legacy systems indefinitely, no matter what language they originally used.

Benefits:

- This style of architecture promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to – and usage of – existing IT (legacy) assets.

- An indirect benefit of SOA is dramatically simplified testing. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation.