Author Archives: Tim Daniels

About Tim Daniels

Tim Daniels is a professional software architect and developer living in San Antonio, Texas. What he brings to the market place is over 20 years of solving business problems, by leveraging software. For Tim, software development is both a profession and a craft, which requires daily practice and continuous improvement. Tim also has many years of experience on the management side of the software industry. He has managed small to large scale development teams and projects. He has covered a wide range of management responsibility; from team lead to Vice President of Product Development and Chief Architect. Recently, he has lead offshore teams in Russia and Spain. He is currently responsible for the modernization, and migration, of enterprise level applications from the IBM iSeries platform to the Microsoft.Net Framework. Tim has a Bachelor of Applied Arts and Sciences Degree from Texas State University, and an Associate's Degree in Computer Programming from San Antonio College.

Configuration of the WCF Web Service

Depending on the requirements of the application, configuration of a WCF web service can be simple and straightforward, or sophisticated and complex. This first iteration of the World of Art Web Service has very simple requirements, so I’ve attempted to keep the configuration as straightforward as possible. Here is the Web.Configuration file from the web service.

The first thing to notice is the ConnectionStrings tag. Since the World of Art Web Service references the Data Access Layer and the Data Model, from the World of Art Web App, it is necessary to provide the database connection information to the web service.

Now, lets discuss the configuration of the World of Art Web Service. Configuring the service in the Web.config file, gives us the same flexibility in deployment and management of the web service, as configuring a web application in the Web.config file. Instead of hard coding configuration elements in the application code, it is preferable to expose this information in the configuration file. This will allow an administrator to configure the application for final deployment, without having to modify code and rebuild the application.

The World of Art Web Service, is based on the Windows Communication Foundation (WCF) and will be hosted by Internet Information Services (IIS). The web service run time environment is .NET Framework version 4. Therefore, this configuration is specific to a WCF services hosted in IIS. IIS depends on the mark up found in the .svc file to implement the WCF service. My hosting provider, Winhost, supports all of these components.

The WCF configuration scheme includes three major sections;

  • serviceModel
  • bindings
  • services

Here is the serviceModel seciton ;

The entire service configuration is bound by the system.serviceModel elelment. Lets first examine the services element. Within services we find one or more service elements. It has a name attribute to identify the service. Within the service element, the endpoint element is used to configure one or more service endpoints. Notice how the address attribute has a null value. Since this service is hosted in IIS, it’s not necessary to specify an endpoint address. In fact, specifying a fully qualified endpoint address can lead to deployment errors in IIS. With an IIS hosted WCF service, the end point address is always relative to the .svc file that represents the service.

The binding attributes of the endpoint element, specify how the endpoint communicates with the world, in terms of transport and protocol schemes. In this case, I specified the WebHttpBinding Class. A binding used to configure endpoints for WCF Web services that are exposed through HTTP requests instead of SOAP messages. I am also utilizing the bindingConfiguration attribute of the endpoint element. This attribute is used in conjunction with binding to reference a specific binding configuration in the configuration file. In this case it is referencing a binding elelment in the webHttpBinding section named “webHttpBindingWithJsonP”, where I specify a custom binding configuration using the crossDomainScriptAccessEnabled, which is set to true. I will discuss cross domain access to web services in a future post.

The final attribute of the endpoint element is the behavior configuration attribute. I gave the behavior configuration a unique name of “webHttpBehavior”. The configuration of the endpoint itself can be found in the behavior element of endpoint behaviors section. The only required element I utilized is the webHttp element. This element specifies the WebHttpBehavior on an endpoint through configuration. This behavior, when used in conjunction with the webHttpBinding standard binding, enables the Web programming model for a Windows Communication Foundation (WCF) service. I simply took all of the default values for attributes in the webHttp element.

As you can see, it is absolutely necessary to completely understand the operational requirements of the WCF web service, prior to configuration. There is a lot of flexibility in this area of WCF. However, with more flexibility comes more responsibility. In my next post I will cover deployment of the WCF web service.

Data Contract and Data Member Attributes Complete the Service Contract

As I stated several times in recent posts, the purpose of the Art Service is not to expose the business logic of the World of Art web app. Instead, the purpose of the Art Service, is to simply expose specific data elements from the World of Art domain, which can be served upon request, to various software clients. We have already discussed in detail, how the service contract attribute and the operation contract attribute, transform a simple interface and class implementation, into an actual web service. Now lets look at how we can complete the details of the service contract, by specifying exactly which data elements are to be exposed by the web service.

In the early phases of development, I isolated the entities of the world of art domain into a separate class library called ArtWorldObjects. Artist is one of the entities defined in this class library. At this time, I want the WorldOfArtServiceApp to only expose the Artist object, and more specifically, only certain properties of the Artist object. To acomplish this, I will utilize the Data Contract Attribute Class and the Data Member Attribute Class. The data contract attribute specifies that the type defines or implements a data contract. The data member contract, when applied to the member of a type, specifies that the member is part of a data contract, and can be serialized by the DataContractSerializer Class.

Here is the source code for the IArtist interface and the Artist class, with data contract attribute and data member attribute applied;

Click on this link; Artists in JSON Format to send a “GET” request to the World of Art Web Service app. You can also copy the following link into your browser’s address bar to retrieve the JSON data;

Upon examining the JSON text returned by the service, you will see that the only properties of artist returned by the web service, are those enhanced with the Data Member attribute. Here is what the artist data in JSON format looks like;

For the sake of convenience I added three properties, of type string, to the IArtist Interface;

  • ExceptionMessage – messages to communicate any problems to the client
  • DateOfBirthShortString – date in “mm/dd/yyyy” format
  • DateOfBirthLongString – date in fomat “Monday, August 06, 1928″

The short and long data formats where necessary, because I discovered that when type System.DateTime is serialized to JSON, a very nasty date format is produced. Something like this; “DateOfBirth”:”\/Date(-296931600000-0700)\/”. Therefore, I excluded the date of birth property with a type of System.DateTime from being a Data Member. However, you can see in the source code, that the short and long date of birth properties are derived from the System.DateTime date of birth property.

In my next post, I will cover the configuration and deployment of the World Of Art Web Service. After that, I will cover the client, which uses JavaScript to consume artist data from the web service. This link; Artists from the Web Service will launch the client in the World of Art Web App.

Implementation of the Web Service Interface

In my last post, we discussed the interface of the WCF application and how it forms a mutually binding contract, between the client and the service. The client must make their request in a format the service is expecting, and the service must fulfill the request in the format specified in the contract. This is all defined in the operation contract of the IArtService interface.

  • The request must be an XMLHttpRequest using the “GET” verb
  • The “GET” request must specifically request access to the ArtService.svc and the GetArtists method
  • The service must respond to the request with data serialized into the Json format

Here is a simple JavaScript function which would satisfy the contractual requirements for a request;

Once again, here is the IArtService interface where the mutually binding contract between the service and clients is defined;

As you can see, the interface also uses the System.Runtime.Serialization and System.ServiceModel.web name spaces to fulfill the request.

Now, lets examine the implementation of the IArtService interface. Here is the source code of the ArtService class which implements the IArtService interface;

As I stated in an earlier post, the purpose of the Art Service Class is not to expose the business logic of the World of Art web app. Instead, the purpose of the Art Service, is to simply expose specific data elements from the World of Art domain, which can be served upon request, to various software clients. In order to retrieve data from the world of art domain, the ArtService class references two name spaces from the WorldOfArtWebApp;

  • ArtWorldObjects
  • WorldOfArtWebApp.DataAccess

With these references, the GetArtist() method can reuse components of the WorldOfArtWebApp from the Data Access Layer and the Data Model defined in the Entity Framework.

The GetArtist() method is bound by the Operation Contract, defined in the IArtService interface, to return a list of artist objects. This requirement is satisfied by simply creating a new instance of the ArtWorldCollectionArtist Class, and accessing the collection of artist objects in the ArtWorldCollection property. The collection of artist objects is retrieved from the WorldOfArtContext, generated from the Entity Framework. The WCF web service will serialize each of this artist objects into JSON format as specified in the operation contract.

In my next post, I will discuss how to specify which properties of the Artist object are exposed to the web service. Also, here is the source code for the ArtWorldCollectionArtist class, invoked by the GetArtist() method.

Web Service Operational Parameters

Today I will continue the discussion of the service contract, as defined by the interface generated from the WCF application template. Once again, here is the source code of the interface;

The operational parameters of the service contract are defined as a method. In this application, the method is called GetArtists() and it returns a list of artist objects from the world of art domain, as defined in the ArtWorldObjects name space. Therefore, a reference to the ArtWorldObjects class library is necessary, as indicated by the using statement.

The GetArtists() method is enhanced with the Operation Contract Attribute, which indicates that a method defines an operation that is part of a service contract in a application. The operation contract attribute is also defined in the System.ServiceModel name space.

The GetArtists() method is also enhanced with the WebGetAttribute Class, which indicates that a service operation is logically a retrieval operation and that it can be called by the REST programming model. The WebGetAttribute Calss is defined in the System.ServiceModel.Web name space. The constructor method of the WebGetAttribute class will accept a variety of arguments, as named parameters, which populate the properties of the class and configure the operational contract between the service and client software. This first iteration of the web service is very simple and retrieves a very small data set, so I’m only passing the Response Format argument for now.

The Response Format parameter will set the ResponseFormat property of the WebGetAttribute class. This property determines the format of responses sent from a service operation. The two possible values are Xml and Json.

As you can see, the World of Art Service will return a response in the Json format. JSON stands for JavaScript Object Notation. JSON is syntax for storing and exchanging text information. The web service is now contractually obligated, to respond to requests with text. More specifically, text that is formatted in a way that JavaScript, running on the client, can parse and evaluate as objects. In this application the objects are abstract representations of artists. The clients will receive an array of artist objects. Click on this link, Get Artists to send a request to the World of Art Service, and see the JSON text returned by the service. This link, Artist will take you to the actual website that consumes this JSON data.

In my next post, I will discuss the implementation of the IArtService interface.

Web Service based on WCF and REST

Then next phase in the evolution of the World of Art Web App is the development of a web service, based on the Windows Communication Foundation (WCF), and the Representational State Transfer (REST) architectural model. SO lets get started.

Visual Studio 2010 and the .Net Framework 4.0 make development of web services a very straight forward process. As you would expect, Visual Studio has a WCF Service Application template already installed.

Visual Studio provides a WCF application template already installed

Visual Studio provides a WCF application template already installed

I decided to make the World of Art web service a separate project from the World of Art web app. The primary reason for doing this, is that later in the project, I want to demonstrate cross-domain access to web services, and keeping the service in a separate project will make deployment to multiple domains easier. Here is the solution explorer displaying all of components generated from the WCF application template.

WCF Project in Visual Studio 2010

WCF Project in Visual Studio 2010

The WCF application template generates three very important files for defining and developing the functionality of the web service;

  • Interface defining the contract and operations of the service
  • Web Configuration file
  • Service file

Here is the source code in these three files;

The service file, which I named ArtService.svc

The web configuration file

The Interface

The interface, which I named IArtService, defines both the service contract and the operational parameters of the service contract. The implementation of the interface, will facilitate the fulfillment of contractual requirements, between the client and the web service. The interface is enhanced with the service contract attribute, which indicates that an interface or a class defines a service contract in a application. This attribute is defined in the System.ServiceModel name space of the .NET Framework 4. This name space contains the classes, enumerations, and interfaces necessary to build service and client applications that can be used to build widely distributed applications.

In my next post I will cover the operational parameters of the service contract.

Return of the Jedi Blogger with HTML5 and Web Services

It has been a very busy summer and three months have slipped away since my last post. Since then, I’ve been working on other projects and doing some summer time traveling, which included visits to Los Angeles and Las Vegas. I have also been doing some very interesting work with HTML5 and web services. Well, with summer time activities winding down, it’s time to get back to work on the World of Art Web App project. In coming posts, I will be enhancing the server side of the web app, with a new web service, based on Microsoft’s Windows Communication Foundation (WCF). I will also enhance the client, with a new artist page based on the new web standard, HTML5.

My next post will cover the WCF web service. The purpose of the web service, is to listen for requests from various software clients, and respond to the requests with information from the World of Art Web app. The architectural objective in the design of the web service, is not to expose the business logic of the web app to world wide web. Instead, the design objective is to only expose specific data elements and implement a scheme, that enables client applications to access this data, and manipulate it using their own business logic. With these design objectives in mind, I have decided to use the Representational State Transfer (REST) architectural model.

The web service will reuse all of the Entity Framework and the data access layer components already developed. As previously stated, these components will not be exposed by the web service. However, the web service will use the output of these components to satisfy a basic contract for information, as requested by a client application.

Client Consuming From The Data Access Layer

When I first launched the World Of Art web app, I wrote a post entitled  Improving the Design, where I  expressed concerns over the tight coupling between the user interface and the SQL Server database. In today’s post, I will demonstrate how the user interface can consume data without any regard as to what or where the data source is. This decoupling of the user interface from the data source, is made possible, by separating the entity data model classes, data access classes, and the domain entities classes, into distinct architectural layers of the application.

In the first iteration of the Artist Web Form, I used three ASP.Net user interface server controls;

  • DetailsView
  • GridView
  • SqlDataSource

In the latest iteration of the user interface, I added a new web form called ArtistEntityWebForm, which eliminates the SqlDataSource control for querying the World of Art database. With the first iteration of the artist web form, it wasn’t necessary to write any C# code to retrieve data, or bind data to the user interface controls. The ASP.Net engine on the web server, performed all of these operations automatically, based on the XHTML markup in the web form. By eliminating the SqlDataSource control,  it is now necessary to write some C# code, to retrieve data through the data access layer, and bind it to the views controls. Here is the XHTML markup of the artist entity web form;


Here is the C# code in the code behind file;

At the top of the C# file, you can see that it is referencing the ArtWorldOjects class library. The classes in this library represent the objects found in the world of art domain. The C# file also references the WorldOfArtWebApp.DataAccess name space in the data access layer. There are two methods called in the page load event;

  • LoadArtistView()
  • LoadWorkOfArtView()

Both methods create a new instance of the appropriate class in the Data Access Layer. The constructor of each class calls methods to retrieve data through the data entity model and initialize the appropriate collection of world of art objects. I added a get list method to each class in the data access layer to return a simple array of objects. These get list methods are now the data source for the detail views control and the grid view control. All this client object needs to know, is that it can consume an enumerable list of world of art objects, by instantiating the appropriate class in the data access layer and calling the get list method of that class.

Click Here to render the new artist entity page and see the results of all the code on today’s post.

Data Access Layer – Get Art Collection Method

The following code snippet is the GetArtCollectionDataMethod(), from the ArtWorldCollectionArtPiece class, we discussed in the last post. This method demonstrates a practical application, of the separation of concerns concept, within a layered application architecture.

Within this one small method, we are utilizing all of the architectural layers;

    • This method performs a query against the entity data model, in the The Data Model Layer, which gives the application separation and independence from the data source.
    • The code in this method creates new instances of objects from the World of Art Domain, which are populated, or hydrated, with data obtained through the entity data model.

Do you remember how the entity data model maintains the one-to-many relationship, between the artist and their works of art? Even though the LINQ query is running against the WorksOfArt class in the object model, we not only have access to each work of art object, we also have access to the associated artist object as well.

Finally, this methods generates a generic list of objects from the World of Art domain. This list has a public access modifier, so it can be consumed by many different software clients. Each client can simply create a new instance of the ArtWorldCollectionArtPiece class, and all of the information needed, is in an enumerable generic list, for easy consumption.

Let’s wrap up our discussion of layered architecture and separation of concerns, by taking a look at the World of Art web app in the Visual Studio solution explorer;

Layered Architecture

Solution with layered architecture

The four architectural layers are highlighted in the illustration above;

  • The ArtWorldObjects class library is where the World of Art domain is abstracted into classes
  • The DataAccess folder in the WorldOfArtWebApp project contains the abstract interface for serving data to various clients
  • The DataModels folder contains the object relationship model, based on the Entity Framework
  • The Views folder contains the elements of the user interface

Data Access Layer – Reusing the Abstract Interface

Lets take some time to examine the re-usability of the abstract interface we implemented in the previous post. This time we will implement the IArtWorldCollection interface, to create a collection of works of art, along with artists who created them. Once again here is a code snippet of the interface;

Now, here is the second implementation of this interface, in a class I named ArtWorldCollectionArtPiece. The purpose of this class, is to create a collection of works of art, found in the World of Art domain;

This implementation is essentially the same as the ArtWorldCollectionArtist class, except for two very import elements. Notice that in this implementation, I replaced the generic object type of “T” with the art piece object from the World of Art Domain, which is defined in the ArtWorldObjects class library. This object replacement occurred in two places, one is at the beginning of the class, where the implementation of the IArtWorldCollection interface is declared. The second is in the ArtWorldCollection property, which is defined as a type of Generic List Class.

This second implementation demonstrates just how re-usable the IArtWorldCollection interface is. This high level of reuse is achieved by coding the interface based on a generic type “T”. For more information on generic types in C#, see An introduction to C# Generics and Generic Interfaces C# Programming Guide. The IArtWorldCollection interface, can be reused over and over again, to generate many different collections of objects found in the world of art domain. These are enumerable collections of objects, which can be consumed by many different kinds of software clients.

In my next post, we will examine the GetArtCollectionData() method of the ArtWorldCollectionArtPiece class in more detail, and wrap up our discussion on separation of concerns,the entity framework, and the data access layer of our application architecture.

Data Access Layer – Implementing the Abstract Interface

In this post, I will demonstrate how I implemented the abstract interface called IArtWorldCollections. Below are two code snippets illustrating the implementation;

Following is the C# source code of the IArtWorldCollections interface. The interface has the following components;

  • A read only property, called WorksOfArtContext of type object context. The entity data model is an Object Context Class
  • A read only property, called ArtWorldCollection of type generic list. The Generic List Class Represents a strongly typed list of objects that can be accessed by index. It Provides methods to search, sort, and manipulate lists.
  • A read only property, called ExceptionMessage of type string. This property will store the message text, generated by any exceptions, thrown by any operations, performed in the methods of the class implementing the interface.
  • The final component is a method, called GetArtCollectionData, which accepts no parameters and returns no value. The purpose of this method, is to populate objects in the World Of Art Domain, with data from the World of Art entity data model. Then add each object, to the generic list property, called ArtWorldCollection.

Now lets implement this interface in an actual C# class. Following is the C# source code, for a class I added to the data access layer. The class is called ArtWorldCollectionArtist, and as you can see, it implements the IArtWorldCollection interface, replacing the generic type T, with an object of type Artist, from the World of Art Domain. We replaced the generic object type of T, with the object type of Artist, because the purpose of this implementation is to generate a list of Artist objects, populated with data through the entity data model.

The three properties of the IArtWorldCollection interface are implemented with the following protected members of the class;

  • m_context, of type WorldOfArtContext, from the object context class of the WorldOfArt entity data model
  • m_artistList, of type Generic List, object type of Artist replaces the generic T type
  • m_exceptionMessage, of type string

The constructor method of the ArtWorldCollectionArtist class, initializes the protected members based on their object types. The constructor method also calls the GetArtCollectionData() method. In this method I use the Language-Integrated Query(LINQ) syntax available in C#, to perform a query against the World Of Art data model. We will cover LINQ in more detail in a future post. I employ a ForEach loop, to load the results of the query into the Artist List Collection. Notice how the query is not against a SQL Server databse table, instead the query is against the Artist property of the object context, in the World of Art Data Model. Therefore, I can create a new instance of the Artist object from each Artist in the result set of the query. I can populate the properties of the Artist object, with data from the properties of the Artist class in the data model.

Finally, with the implementation of the IArtWorldCollection interface, we have achieved the separation of concerns we’ve been striving for. Notice how the ArtWorldCollectionArtist class has no concern for the source of the artist data. There is no code for opening and closing a connection to the database server. No need for hard coded SQL commands like “SELECT FirstName, LastName, BirthDay, City, Country, TypeOfArtist FROM aspnet_Artist” which can be severely impacted by changes to the database tables. The coding task is simplified by the entity data model, because now I’m coding against classes and properties, instead of hard coding table and column names. The hard tasks, of connecting to the database and accessing the tables of the database, have been abstracted into the entity data model. Even if the source of data changes from a Microsoft SQL Server database, to an ORACLE database, or even a data service, the ArtWorldCollectionArtist class would not be impacted by any of these changes.

One last comment on implementing a generic interface for data access, through the entity data model. The payoff for using this approach will continue to increase, as we further implement the interface, to access data and populate other elements in the World of Art domain; such as the works of art created by the artist. More on this in my next post.