Service Oriented Architecture

Problem :

In todays business environment, where customer requirements and demands are changing frequently and businesses are operating in heterogeneous markets, business process automation requirements are becoming more complex and new changes to business processes are coming so frequently. Business are asking for software systems which are highly integrated, easy to modify , highly scalable and customizable so that the changes to business processes and requirements can be accommodated easily with less cost and efforts.

To achieve all these business need, software systems has to be highly modular, business functionality from different business units should be divided into distributed components and these components should be accessible in location transparent way and should be highly interoperable.  System components should be deployed across process and machine to deal with performance bottleneck, to introduce security boundary and to facilitate enterprise level reuse.

Question is how do we do it?

Here, Service Oriented Architecture Comes as rescue. SOA is an architectural style or I would say a reference architecture which guides architects on, how they should decompose business functionality into components and how does the functionality of these components is available to other components. SOA brings the concepts of public contracts, policies and interoperability. Because of these concepts, system components can communicate with each other without worrying about the technology, other component has been implemented.  SOA also posses some constraints on component design and the design of communication links between components.

What is Service?

The term service has different meaning at different level of abstractions. At system architecture level, service is a business functionality which is distributable and is accessible to consume in some way.  It is a window through which business functionality cab be reached. 

Consider the application architecture in Following figure. The client application represents an Agency Management

System that includes many chunks of business functionality such as Certificate Issuance, General Ledger, CRM, and Reporting. The client application coordinates access to these features by consuming business components directly. In

this case, components are not distributable in such a way that they can be location transparent, thus they are not services.

 

So how do you implement a service in SOA?

You expose your system components as serviced components using different distributed technologies. Some of the technologies you can use are : Enterprise Services, a .NET Remoting component, an ASMX web service , or a WCF service. Any of these technologies can be useful in exposing the business logic in such a way that the client can reach that functionality at remote locations in a distributed environment, without communicating directly with the business

components.

Following is an updated diagram of Agency Management System. Here each business functionality is exposed using one of the distributed technologies. Serviced components are reached using DCOM over TCP,.NET Remoting components via RPC over TCP,ASMX web services via SOAP over HTTP, and WCF services via SOAP over any protocol.

The point is that services are not necessarily web services—they are merely chunks of business functionality exposed in some way such that they respect the tenets of SOA.

Some of the constraints SOA poses on serviced components

1. Service boundaries are explicit : Services are responsible for exposing a specific set of business functionality through a well-defined contract, where the contract describes a set of concrete operations and messages supported by the service. Services completely encapsulate the coordination of calls to business components in response to operations it exposes to clients. Implementation details behind the service are unknown to clients so that any technology platform could be invoked behind the service without impact to the client. In addition, the location of the service isn’t important to the client as long as the client knows where to reach it. All the distributed technologies provide a way to expose your system components by following this constraint.

2. Services are autonomous : Services encapsulate business functionality, but they must also encapsulate other dependencies of the business tier. In this way the entire service should be moveable or even replaceable without impact to other services or system functionality. A service represents a major chunk of business functionality that owns its own business components, data access components and data storage if applicable. It should be able to perform key functions without external dependencies. This is what is meant by atomicity.

3. Clients and services share contracts, not code : As service boundaries are explicit, Contracts are used to define this boundary to client application. The contract must not change once published, or must at a minimum remain backward compatible to existing clients.

4. Compatibility is based upon policy: While contracts describe the business functionality available at a service boundary, policy describes other constraints, such as communication protocols, security requirements, and reliability requirements.

If the above information is useful, Please provide your valuable feedback.

Thanks.

Hosting WCF/Workflow Service in IIS directly from Visual Studio 2010 and start debugging by just hitting F5 on Visual Studio.

Problem :
When you develop a WCF/Workflow service using Visual Studio and try to run it, by default Visual Studio runs it under web development server. Here the problem is that the web development server is a light weight host and does not support reach features which comes with IIS. For example web development server does not allow you to run a WCF/Workflow service, which is configured to use NET TCP binding. There are many more such features which does not come with web development server.
As a developer we all want to, just hit the F5 button and start debugging. But if your WCF/Workflow service is configured in such a way that it can only run under IIS, it becomes really tricky to start debugging it.
The common approach we generally follow is to find out in which w3wp.exe our service is running and than attach the Visual Studio to that process.
In following text, I have shown another approach in which Visual Studio can be configured to run together with IIS. With this configuration your WCF/Workflow Services runs under IIS as soon you hit the F5 and you can start debugging without any hassles.

1. Create WCF/Workflow service. See how to create basic Workflow WCF Service.

2. Configure IIS to host your WCF/Workflow service. 

(Note :- You can skip following steps if you already a some IIS website configured on port 80 and NET

TCP binding is configured. )

1. Open IIS Manager.
2. Add new application pool.
1. Select 'Application Pools' node from the left hand side tree view.
2. Click on 'Add Application Pool' link from 'Actions' panel at right hand side.
3. Give Some name to your application pool. I have given name as 'WorkflowService'. In below steps I will refer your application pool as 'WorkflowService'.
4. Change .Net Framework Version to 4.0
5. Click 'Ok'

3. Add new 'Web Site Application' for your services.
1. Select 'Sites' node from the left hand side tree view.
2. Right click on 'Sites' node and click 'Add Web Site'
3. Give Some name to your Web Site. I have given name as 'WorkflowService'. I have given name as 'WorkflowService'. In below steps I will refer your website as 'WorkflowService'.
4. Change Application Pool name to 'WorkflowService'
5. Provide some directory path to create IIS virtual directory for this new web site.
6. Provide host name as 'localhost'
7. Click 'Ok'

 (Note : While clicking on Ok button you might get a message saying that some other website is already configured to run on port number 80. You just need to close the already running website and start your newly created website.)

4. Configure NET TCP Binding
1. Right click on 'WorkflowService ' web site and click on 'Edit Bindings' to open 'Site Bindings' dialog.
2. Click on 'Add' button to open  'Add Site Binding' dialog.
3. From 'Type' dropdown select 'net.tcp'.
4. Type 808:* in Binding Information text box.
5. Click Ok.

5. Enable NET TCP Binding on Web Site.
1. Select 'WorkflowService' website node from left hand side tree view.
2. Click on 'Advanced Settings' from 'Actions' panel at right hand side.
3. Update 'Enabled Protocols' field by adding comma delimited value as 'net.tcp' at the end of the existing value.
4. Click 'Ok'

3. Configure Visual Studio Project settings to use IIS as service host instead of default web development server.
1. Select your service project in Solution Explorer and press ALT+ENTER to open project properties dialog.
2. Click on 'Web' tab on project properties dialog.
3. On 'Web' tab page, select 'Use local IIS Web Server' radio button.
4. Click on 'Create Virtual Directory' button to link your website project with IIS.

(Note: This step will fail if Visual Studio is not running in Administrator privileges.)

At this stage you have successfully configured IIS and Visual Studio to work together and help you debugging your WCF/Workflow services by just hitting on F5 button on Visual Studio.

If the above information is useful, Please provide your valuable feedback.

Thanks.

Create Workflow WCF Service using Visual Studio 2010.

Create Workflow WCF Service.

1. Open Visual Studio 2010.
2. Setup the Workflow WCF Service project using 'WCF Workflow Service Application' template.

3. Rename ‘Service1.xamlx’ to ‘WorkflowService.xamlx’.

4. Update 'ReceiveRequest' Activity properties.
   1. Open the Property Window for ‘ReceiveRequest’ activity.
   2. Change ‘OperationName field value to ‘PingService’.
   3. Change ‘ServiceContractName’ to ‘WorkflowService.IWorkflowService’.

5. Update Workflow Variables in 'Variables' pane.
1. Click on 'Variables' tab just below the Workflow Designer Area to open it.
2. Change the 'Variable Type' column of 'data' variable to 'String' type.

          

6. Add new activity to implement some logic for Workflow Service.
1. Open ToolBox Window.
2. Open 'Primitives' Category.
3. Drag ‘InvokeMethod’ activity between 'ReceiveRequest' and 'SendResponse' Activities on Workflow Designer.

7. Write some code which will be invoked by workflow.
1. Add new class to project with name ‘WorkflowServicePingImp’.
2. Add a static method to the ‘WorkflowServicePingImp’ class with the name ‘PingResponse’. This method will take a string argument and return a string value as response.
3. Compile the solutions.

8. Update 'InvokeMethod' Activity properties to invoke our implementation from 'WorkflowServicePingImp' class.
   1. Open the Property Window for ‘InvokeMethod’ activity.
   2. Change the 'TargetType' field value to ‘WorkflowServicePingImp’.
   3. Change the 'MethodName' field value to ‘PingResponse’.
   4. Change the 'Parameters' collection by adding new parameter with 'Value' field as 'data' , 'Direction' as 'In' and 'Type' as 'String'.
   5. Change the 'Result' field value to 'data'.

Run and Test the Workflow Service Directly from Visual Studio 2010.

1. Right click on 'WorkflowService.xamlx' file and click on 'Set As Start Page' to set it as start up page for the project.

2. Press F5 to run the solution.  ( Visual Studio will run the workflow service in development server in some arbitrary port.)

3. WCF test client will comp up.

4. Double Click on 'PingService' node on left hand side tree view.

1. Put some string in the 'Value' column in 'Request' panel.

6. Click on 'invoke' button.
7. Output will be shown in 'Response' panel. 

If the above information is useful, Please provide your valuable feedback.

Thanks.