Windows Communication Foundation


, , , ,

Microsoft provides a load of documentation on this, so it’s definitely well documented and maintained, which makes it ideal for a Service Oriented Architecture (SOA) solution with numerous applications. A service provided by a WCF application should be accessible to other applications, regardless of the programming languages they were created with or the platforms they might be running on, which is the whole point of adding APIs to services. WCF is basically another interoperability solution that which can communicate using SOAP and REST, and also make use of commonly used WS components.

When creating a new WCF project, there are four project type templates. For the purpose of this demo I selected ‘WCF Service Application‘.


The project template uses the following libraries:
* System.Runtime.Serialization
* System.ServiceModel
* System.ServiceModel.Web

The project template gives us three source files we’re interested in:
* Web.config: Configuration for the Web server and service bindings (such as HTTPS).
* Service1.svc: Contains the procedures/methods that implement whatever functionality for the services, and the data returned.
* IService1.cs: Defines the interface for the called procedures, and the data types they handle.

This is where the concept of interfaces and implementations becomes important. Typically this is used in ASP.NET MVC as a way to ‘decouple’ methods from the core application, which makes it easier to modify an application’s functionality as a modular system.
Where methods are called directly in a conventional program, here a requesting object calls an interface that contains references to whichever methods implement the requested functionality. This is sometimes referred to as a ‘loosely coupled’ system.
In the WCF project we have a source file (Service1.svc.cs) that contains the methods that implement services by processing and returning variables. In another source file (IService1.cs) we have an interface that contains references to the methods.

The project template can be executed as is in Visual Studio, without any modification. Click on Service1.svc and hit F5. This will launch the WCF Test Client.


In the window to the left, there is an entry for the IService interface, and the references to the GetData() and GetDataUsingDataContract() methods. Return values are displayed in the main window after the methods are invoked.

Adding a New Service/Procedure
This is a simple matter of creating a new method, then adding an interface reference to it. In Service1.svc.cs, add the following method:


And then add an interface reference to it:


When executed, the ‘Invoke’ is simply a trigger for the method to execute and return the defined string.

Interactive Procedures
A WCF application can also process incoming data and return the output. The procedure/method below is no different from a conventional function that takes two variables, performs an arithmetic operation and returns an integer. The same principle will apply to whatever functions you want to make available through WCF.


The interface reference is simply a single line declaring the method/procedure name, the input data types and the return data type.


On executing the application, the XML for the Request and Response looks remarkably like what we get with an XML-RPC transaction.


The request payload has a tag for the function name, and a tag for each value being sent to it. Based on this concept, we should be able to provide almost anything as a WCF service. It also means we are able to call any WCF method and send arbitrary values to it.

WCF Configuration and Service Options
Right-click the Web.config entry in the Solution Explorer, and select ‘Edit WCF Configuration‘. This will open the Microsoft Service Configuration Editor.


The important options here:
Services: Create New Service appears to enable the developer to import a class/service from another object on the local system that has .NET classes. The ‘GAC’ option lists numerous other resources that could provide WCF services.
Client: A client configuration can be created for accessing a service. This configuration defines the message transport method (TCP, HTTP, pipes, P2P, etc.), the contract used and the endpoint address.
Bindings: The Bindings option specifies the transport protocol for requests and responses.
Standard Endpoints: The types of service to be provided, such as service announcement, service discovery, message exchange and workflow control.

A Custom WCF Client
Obviously WCF services are pretty useless without clients to access them. The simplest implementation of WCF is the WCF Service Library project, with which we can create the service as a DLL.


In both IService1.cs and Service1.cs, I changed the data type for GetData() from int to string. e.g.
string GetData(string value);

This is enough to have a service that returns a string when responding to a request. Next, I added a Windows Form project to the solution – this will be used as the UI instead of the WCF Test Client. In the Windows Form, there are text boxes for the input and output, and a Send button.
In order for the client application to make use of the WCF Service, a service reference must be added to the project. Right-click the References part of the client application project, and select ‘Add Service Reference…’‘.


Click the ‘Discover‘ button to find the available services.


Notice that entries to the WCF service appear under the DataSources and Service References in the Solution Explorer. The DataSources entry contains what looks like a connection string. The Service References entry will open itself in the Object Explorer, and we can view the available functions provided by the WCF Service.
Now add the following code as the client application’s button handler:


With the client application set as the startup project, hit F5 to run:


An Intro to APIs


, , , , , , ,

In a typical enterprise network we’d rarely see everyone using the same applications on exactly the same platform and with a uniform configuration. Instead, we’d expect a range of applications for different things, running on a variety of platforms, and using different data sources. This is one reason why, in my workplace, at least 50% of the applications we develop are used within Web browsers, and most interact with each other using some form of Application Programming Interface (API). This is also why major Web 2.0 services, such as Twitter and FaceBook, publish APIs for developers to integrate features into third-party software.

Strictly speaking, an API is an entry point into an application, platform or service that enables an external entity to use its resources. For example, the Windows API enabled third-party software to use the native services of the Windows NT operating system.
Scaling up this concept, multiple applications can use each others’ APIs to exchange information efficiently without going through another mediating layer, or one service can use another as a data source. This is likely something I’d be doing a lot more of in the near future.

To demonstrate how a very basic API works with Twitter, I created a standard Windows Forms application around the search query example on the Twitter API page. When the button is clicked, the application takes the content of the text box and appends it to the search query URI, with the GET command in the HTTP header, thereby sending a REST request:


A REST request has two defining features: 1) The command/requests are sent as URIs, 2) It makes use of the GET, POST, DELETE and PUT commands within the HTTP header.
Here the Twitter server will extract the ‘search?q=%40[search term]‘ part of the URI, and perform whatever operation was mapped to that string. It will then return the HTML for the result, and this will be rendered by the local application’s Web Browser element:


An ASP.NET Web API Example
The next example is something I borrowed from a Web API tutorial, to show what happens on the server end when an ASP.NET service responds to a REST request. An MVC Web application roughly works by routing requests to whichever ‘controller’ according to the URI. In this example, the requesting URI takes the form:


The standard ApiController class has a set of empty controller methods for handling whatever valid requests the application might receive.
In the tutorial project, the application has a catalogue of products that can be searched by their IDs. When a user requests an item, the request is routed by the server to the ‘products’ controller, and the ‘Id‘ value is passed to the relevant controller class.


Basically the ‘Id‘ value relates to whatever the user submitted in the Web page form, which is sent as a query value to the server:


What is an Enterprise Service Bus?


, , , , , ,

One of the problems I often face when encountering some new enterprise product, ‘solution’ or technology is having to dig through a word salad of marketing speak to get a vague idea of what a vendor’s product actually does. This is especially true when it comes to learning how I’d be developing APIs and getting applications to work with an ‘Enterprise Service Bus’ in my new job.
The best literature on the Enterprise Service Bus relates to Apache Synapse. Almost all the other material on this is provided by vendors – the three main ‘solutions’ I’ve been looking at were JCAPS, Fiorano and InterSystems Ensemble, which are all heavily used for integrating clinical/medical applications here in the UK.

It’s easy to get a logical representation of what an ESB is roughly supposed to be. This example is from Fiorano’s documentation:

(Fiorano, 2015)

(Fiorano, 2015)

Obviously this is a logical representation of multiple services using a common channel to communicate, and the channel isn’t limited to any single message type. The applications themselves are coded in different programming languages.
But what exactly is being sent and received on the bus, and how are those messages formatted accordingly without heavily modifying API code? Is the ‘bus’ a cable, a server box, or what? What the hell is an ‘integration pattern’? What we do know is that an ESB is a) software-based, b) provides a common interface for independent services to communicate, and c) has something to do with APIs.

Let’s look at Apache Synapse as an example:

(Apache Synapse, 2012)

(Apache Synapse, 2012)

To the left of the diagram there is a ‘Transport’ component, which appears to have interfaces listening for the various message types, and might have something that determines what to extract from each message prior to it reaching the Message Builder or Message Formatter. The Builder and Formatter, I’m guessing, reformats the data extracted from the original messages. The QoS component handles the routing and prioritisation, based on the TCP headers of the message.
Finally, in the Mediation Engine, which appears to perform the bulk of the message processing. Within the Mediation Engine, there are ‘Mediators’, each of which is described in the Synapse user guide as a ‘processing unit’ that performs a specific action on a message. Examples of what a Mediator could do include:
* Drop message
* Log message
* Send message to endpoint
* Rule-based filtering
* Modify URLs within message

Mediators can be chained to perform a sequence of these operations.

The important point about Synapse, and perhaps all the other ESB ‘solutions’ is that it runs on a physical machine, as a server on the network that listens for incoming messages, relays the messages to another process and sends the result back out to whichever service. Logically we have a message bus, but physically it’s pretty much a proxy server.

Thing is, I’m not sure why an enterprise network would require an ESB in the first place, or why it would be appropriate to have one. If we have several applications that need to communicate, why not simply do that through API or stored procedure calls? Adding yet another layer to this seems pretty redundant.

The Secular Franciscans and the Year of Mercy


, , , ,

The Pope has designated 2016 as the ‘Year of Mercy‘ – you’ve probably seen the banners outside the Catholic churches with the slogan ‘Nobody is excluded from God’s mercy‘ – but what does that actually mean? Why does the Pope feel so strongly about it that a friar travels all the way from Rome to visit us in South Wales this weekend?

Mercy isn’t solely about mercy from judgements. It has another meaning for Franciscans, and the central theme of what the Friar and the rest of us discussed was mercy in the context of providing assistance to those in need. For us it was a reflection (with many tangents) on why St. Francis chose to live and work amongst the poor, and why religious societies generally feel a duty to provide care.
Often we’re often called upon to reach those who, society being the way it is, are treated like outcasts. Some Catholics also make a vow never to ignore a person who asks for help – a tough vow to keep for anyone working in the city. Mercy is largely about showing kindness to those who need it, regardless of their life choices, and doing away with the distinction between the ‘deserving’ and the ‘undeserving’ poor. We do it because dignity, compassion and the alleviation of their suffering is their right – addressing that is also a central definition of ‘justice’ in the Catechism.

The Seven Corporal Works of Mercy:
* Feed the hungry
* Give drink to the thirsty
* Clothe the naked
* Shelter the homeless
* Visit the sick
* Visit the imprisoned
* Bury the dead

Edited to add: Saw this sculpture in the chapel – it was massive:

Converting a Test Manager Recording to a Coded UI Test


, , , , , ,

For this you’ll need:
• Microsoft Test Manager
• Visual Studio Enterprise
• Team Services

When using the following method, I strongly recommend putting the manual test scripts and application source code in two separate projects, or there’s a risk of overwriting the latter. I started off by creating a new project in Team Foundation Server for the automation scripts, then connected the Test Manager project, and created a test plan.


Creating and Recording a Manual Test
A test case needs to be added to the test plan in Test Manager. At this point only the manual instructions and expected outcomes need to be entered. When done, make a note of the test case number.


Now the test script is ready to be run, and an action recording can be made. When completed, the test case should be updated with two XML attachments and an action log file.


Test Playback
Now you should be able to run the test case from Test Manager, by opening the test panel as before, and clicking the Play All button, just to confirm it works.


Import recording into Coded UI Test
Test Manager action recordings can be imported into a Coded UI Test as C# code. In Visual Studio, connect Team Explorer to the TFS project. Next, create a new Coded UI Test Project, but instead of creating a recording, select the option to ‘Use an existing action recording‘.


This will display the Work Items Picker. The quickest way to find the action recording is to enter its test case number.


The test recording is now converted to a C# Coded UI Test.


Get every new post delivered to your Inbox.

Join 31 other followers