One of our strong practices here at Syndicated Methods is design and implementation of Service Oriented Architectures (SOA).  When people immediately hear SOA, they think SOAP and bloated contracts.  Yes, SOA boasts some grandiose goals with its standards, and with those goals comes a complex implementation. I have seen SOA make sense of many enterprises, and like any loyal developer ready to fight for their technology,  this mantra has always rubbed me the wrong way.   As of the release of .NET 4.0 however, and the rise of REST services, it has become quite clear that SOA isn’t the only way.  It has actually changed how I think of our practice.  So much so that I make sure to tell clients and folks that I talk to that our practice specializes in “Distributed Architectures”.  I have come to realize that we can take all of those lessons learned in SOA and apply them to any number of manners for exposing enterprise data in a distributed fashion applying the most suitable manner for clients.

After reading a recent article on WCF Data Services, it got me thinking about how to spread the word for such technologies.  Oh yeah, did you know Syndicated Methods has a blog!  So, I want to start a series on the Syndicated Blogs titled ”Distributed Architectures”.  The first candidate … you guessed it.  WCF Data Services.

WCF Data Services

There are certain scenarios where the development overhead associated with SOA is just not necessary.  For example, you have an analytics group that needs to have open access to a data store.  Or, you have an application that allows the user to shape and export data how they see fit.  Maybe you do a lot of prototyping and are looking for a turnkey solution for getting to your data. Such business problems have been solved by the Open Data Protocol (i.e. OData).  Those familiar with RESTful services will immediately understand.  The idea is to expose a repository of data over a standard pathing system, such as urls.  WCF Data Services takes these concepts and allows you to define a WCF Service (without the contracts of course) over an Entity Data Model.  You can expose your data in just a couple of easy steps.

Step 1 – Create a new Web Project on your local file system.  Any name for the site should do.

Step 2 – Next we need an Entity Data Model of the standard Sql Server Nothwind database.  You will want to create a new Entity Data Model pointed to a local instance of Northwind.  Go ahead and run all of the default configurations (make sure you place this in the App_Code section of the project).  You should end up with a Entity Data Model that looks similar to the following diagram:

Step 3 –Now it’s time create your service.  Create a new WCF Data Service in the root of the website. Now we are going to have to write a little bit of code here.  We only want to expose the Employees table for this exercise, so we need to tell the WCF Data Service to expose the Employee table.  In a real world implementation this could be done for all of the data tables / data sources required.  The code is rather trivial and is represented below:

Step 4 – Now for the fun stuff.  Let’s get your data!  You can easily pull your Employee data from the service by pointing DataServiceQuery at the endpoint.  Pretty neat!  No messy configurations, no service endpoints to deal with, and better yet you get your data in 4 or less easy steps.  I will let you play around with your services to get an idea of what it’s like to pull this data. Below is sample code for consuming the endpoint.

Before I close out this post, I want to just show you something that you may have missed.  I know that I missed it the first time through, so I want to just call it out.  WCF Data Services are employing the power of .net and WCF to allow you to address your data.  Users of the system only need to know the schema of the database.  We accessed the data by pointing to the following url:

http://localhost/WcfDataService.svc/Employees

This url basically says, use this service repository location, and show me all of the employees.  If we wanted the Customer data (assuming it was exposed in the WCF Data Service) we only need to access the following url:

http://localhost/WcfDataService.svc/Customers

And keeping true to the RESTful theme, if you want to narrow your data down you can pass a query along with this path like so:

http://localhost/WcfDataService.svc/Customers('ALFKI')/Orders?$filter=Freight gt 50

This will capture Customers with the id of ALFKI and will then filter those by getting freight values that are Greater Than 50.  Pretty neat.  Using these powerful data services allows you to get to a repository of data by simply "asking" for data in a standardized format.  If you are wondering how all of this data gets transferred, under the hood .NET will serialize this data in POX or JSON format.  The following screenshot verifies our transport data as depicted in Fiddler

As you can see the output is a standard ATOM Xml format.  Internet Explorer will conveniently display this as a RSS feed.  Anyone that is tasked with exposing data in a distributed fashion should definitely put this one in their toolbox!

{Happy Coding}

One of the biggest lessons learned over the many years of software development is that if you aren't listening to your customers about what they want, you are completely missing the mark.  This is a rather simple point that so many times gets missed.  That's why I am proud to work on the Fashion Mobile  team at Syndicated Methods (stepping back for readers that are not familiar with Fashion Mobile, it is a specially tailored instance of MobilePipes for the fashion industry).  From inception, this product has incorporated features that have helped our customers solve problems.  We take in feedback, survey our users, and try to pick a couple of the most sought after features.  Doing so ensures that we are adding valuable additions that our customers want.

Recently, one of our sales representatives was visiting a client talking through a recent Fashion Mobile installation.  The topic of conversation was along the lines of how are things going, what would you change, is the product satisfying your needs.  This particular client used Fashion Mobile to fulfill their own sales process.   We designed an application that allowed their sales representatives to demonstrate their clothing lines using their iPhone.  The tool was very well received by the client, with one major exception.  Along with client information the sales representatives found it rather cumbersome to have to switch out of their application while on the road to find directions to the client site.  They wanted some way of staying within Fashion Mobile to find their customers on a map.

This sounded similar to feedback that we had received from other customers.  So, keeping true to the content in this article, we rolled it into Fashion Mobile.  Customers of Fashion Mobile now have a way to work with mass Geo Coded locations within the product.  There are two pieces that we have rolled in.  The first piece is the ability to load Geo Coded locations into the Fashion Mobile Control Panel.  With the latest release of Fashion Mobile, customers can now locate and save Geo Coded addresses for consumption on the iPhone client.  The second piece is a new Module in Fashion Mobile for retrieving those Geo Coded locations.  With this new Module, iPhone developers can retrieve multiple pairs of Latitude / Longitude pairs that allow for any development pattern that the iPhone supports.  Examples of this are dropping a point on the map, providing driving directions, finding distances between points, for example.   As just a little taste, the following screen shot shows you what the Control Panel looks like for this new feature:

As a software consultant I have spent multiple hours learning new languages and API's.  Having experienced this process myself many times one of the things that I appreciate in a product or code library is effective documentation. Reading documentation is a crucial first step in learning any new product.  However, any developer knows that when the rubber meets the road, there is one place that always falls a little bit short. 
Documentation almost always falls down when you actually start to consume the methods and classes.  The reason is because code is constantly evolving.  Documentation is great for high level components and understanding intent.  Where it fails is at the interface level. Wouldn't it be great if developers receive compile warnings if they were using your library incorrectly? 

Microsoft added something call Code Contracts into .NET 4.0 that allows developers to describe the behavior of their methods and classes in a way that consumers receive real time feedback from the compiler if they are using a method or class incorrectly.  The next version of MobilePipes will include Code Contract checking which will provide better documentation.  Customers that are customizing MobilePipes will really appreciate this addition because it will allow you to better understand how to effectively grow the product to fit into your business needs.  We are working to include all of the feedback we receive from customers into our customization interfaces to answer your commonly asked questions in real time when you are writing code. 

For example, take the IModuleOperation interface in MobilePipes.  This interface has the following definition:

Writing a custom module in MobilePipes involves implementing this interface.  The very first thing that MobilePipes does when it receives a request is to validate the Data argument that goes into these methods.  This validation consists of ensuring that the XDocument Data object contains the correct MobilePipes XML Schema.  If this schema does not exist then the method will not execute.  You will receive an "Invalid schema validation" message from the MobilePipes server.

With Code Contracts we can notify the developer early on in their testing code that they are passing a bad value by changing the interface to the following:

Now developers will receive an "Invalid schema validation" in their unit tests letting them know that their XML input string is incorrect.  This saves lots of time deploying and debugging and shows customers how to use our product more effectively.

NOTE: Some of the code here is pseudo code and is intended to demonstrate advances in the MobilePipes product.  It is not intended to be a demonstration of Code Contracts in .NET.  Readers that are intestered in Code Contracts should consult Microsoft documentation.  I recommend also viewing "Contract Checking and Automated Test Generation with Pex" from the PDC2008 < http://channel9.msdn.com/pdc2008/TL51/ >.

{ Happy Coding }

MobilePipes grows up!

The MobilePipes team works hard on our product suite making sure that our customers are buying software that is top notch, bright and shiny, reliable, easy to use, stands the test of time, and, well you get the point!  We could assure all day long that our products meet this criteria but we took the extra steps to prove it. 

MobilePipes was officially certified by Microsoft this month as a certified product.  This means a lot for our marketing and sales material because we get to include the logo all over the place, but more importantly, it assures our customers that they are buying a quality product. 

For those familiar with the process we ensured that our code meets the Microsoft standard for .NET based Web Services, Managed Code, and Windows Server 2008 Hyper-V. 

SyndicatedBlogs is a fairly new blog.  The staff here at Syndicated Methods are feeling our way through things to see what format works best for our company and customers.  We started the blog with lots of development tips and tricks that we found useful, but  hey, isn't that what  Google is for? Maybe people will stumble across those types of posts and find them useful but acting as a third party "tid bit" aggregation service will not serve our customers well.  It takes time to write those posts and make sure the content is relevant, and that is time taken away from product development and implementation work.

After some looking back we realized that we want a blog to distribute information about our organization and products that users would never see outside of the organization.  Tips and tricks about how to use MobilePipes is much more suitable for this channel.  And upcoming news such as MobilePipes becoming a Microsoft Certified Product (well, let's not get ahead of ourselves, this is pending approval of Microsoft but we are confident :)).

So, the future of this Blog will be dedicated to development news in the industry that relates to our services and products.  Additionally, news and tutorials about our products and client components for using those products.  I will conclude with an article from Joel Spolsky, to be exact, his last Inc. article where he posted hindsight on the blogging phenomena and gave tips for corporate blogs that are in line with this new strategy for SyndicatedBlogs.

Joel Spolsky's Last Word

{ Happy Blogging }

Anyone that has ever consumed Interop assemblies from managed code has experienced some of the headaches with the old ways of coding Microsoft solutions.  Some of those bigger issues are dealing with DLL hell and having to deploy and rely on those exact assembly versions availability on the target system.  Add into the  equation many different target environments and you have a real mess on your hands.  The CLR team has added lots of great new features into .NET 4.0, one of those features is embedding Interop Types in your .net projects.  And ... it's really easy to do!

First lets paint a bit of a scenario.  You are working with a solution that must work with the Excel Interop classes.  You must first start by adding the assemblies as a reference into your project.  Now you code away and finish your solution.  Once you deploy you realize that two of your systems don't have the assemblies installed at all, a third has different versions of the assemblies, and the final system is happy.  1 out of 4 is pretty bad and I am sure your users will have the same reaction!  You could deploy those Interop assemblies along with your application but that is a bit messy as well given different deployment models and potential DCOM issues.

With Embedded Interop Types you can include your interfaces and functionality required for those Interop assemblies by simply checking off the embed on that assembly reference.  The following screen shot demonstrates.

Now, if you load up that application, and look at the loaded assemblies, you will find that no Interop assemblies are loaded and you are working completely within your managed code.  No need to rely on those target assemblies on the system.  You can read more at: Type Equivalence and Embedded Interop Types

{ Happy Coding }

If you read this blog, one recurring theme is clear for the reader, we love our development tools here at Syndicated Methods!  Javascript has come a long way in recent years, but I would argue that one place it falls short is in the Integrated Development Environment arena.   Yes, I know that Firefox has the Firebug extension, but for me that is more of a debugging environment.  I would much rather that that my IDE incorporates debugging and code quality tools at design time. 

Thanks to Douglas Crockford, we now have a Code Quality tool that targets all that bad Javascript that is out there.  Please read more on his website at www.jslint.com.  But, that only gets us about half way there.  I really want to know when something is wrong while I am writing code.  There is a solution for all of you .net developers.  CodePlex has a project available under the name of JSLint.VS.  Using this Visual Studio add in developers will get code quality feedback on their Javascript at compile time (sorry, no background compiler). 

{ Happy Coding }

** UPDATE [3/6/2009] - Note to self. use a product before you blog about it :).  JSLint itself is a useful tool.  After using it for about a day though I am finding that it is quite brutal on particular syntax.  Specifically around some of the requirements around global variables.  Furthermore, JSlint has major issues with the JQuery framework including the custom code that you write using JQuery.  This makes JSLint a bit of a useless feature for me as most of the Javascript code that I intend to write will be in a framework such as JQuery.  JSLint.vs is also a bit buggy and I started to experience major slow downs with my build.  This will kill my Continuous Integration process, always strive for fast builds, always!  I also didn't like some of the features whrere it adds reminders to fix things into your task list.  I would much rather these be treated as a warning or error much like the legacy compiler in VS.NET.  If anyone has better luck or thinks I am crazy feel free to comment.

I was recently listening to a TWIT podcast that was discussing changes in technology over the past 10 years or so.  One area of innovation struck especially close to home for me ... Virtualization.  Virtualized environments have completely changed how I think about hosting development environments. Virtualization allows you to host multiple different environments on the same physical machines.  Depending on your hosting hardware you are going to use either VMWARE or Microsoft's Virtual PC / Virtual Server.

My role in Syndicated Methods requires lots of time researching new technologies.  Additionally, we have many developers that need to work on our solutions.  Virtualization has answered two major problems that have proved challenging to support these needs:

1) Minimizing hardware to support iPhone, ASP.NET, WAMP, and LAMP environments.  We can now have one or two machines that host all of these different development machines.

2) More importantly we don't waste time setting new developers up.  With a local running configuration of VMWARE, developers only need to copy a file over and they have everything they need to start coding. 

We run windows based servers in our local network.  With virtualization one of the things that has always troubled me is that CPU and RAM have gobbled up by a baseline Windows Server install.  The Windows Shell takes up a lot of resources to run services.  These are precious resources that essentially sit idle for a machine that is intended entirely for hosting virtualized environments.  Obviously other customers felt this way because Microsoft released Windows Server 2008 Core.  This special operating system is a Windows 2008 Server without the Windows Shell.  With the lightest foot print possible to host Windows, you can now install your Virtualization engine on top of 2008 Core and have more access to raw resources.  The Tech Republic Blogs have an excellent tutorial that walks you through the installed with Windows Virtual Server 2008.

Like most software developers, I prefer to keep my nose buried in lines of code.  Writing algorithms, patterns, and coming up with creative solutions to domain issues is where I prefer to spend my time.  The reality though is that at some point in time, we all need to hoist some manual labor in parts of the code that we really prefer not to.  One area that I can firmly admit to having a love hate relationship with is html and the overall design process. 

Not because I think that it's beneath me, it couldn't be more the opposite.   It has more to do with browser compatibility.  The mentality of an html / css developer must be a forgiving one, a trait that I can't say that I share ... especially when it comes to technology.  I cannot fathom why browsers handle HTML and CSS differently.  The equivalent for software developers is like telling them that they must embed conditional statements to handle varying compilers in Windows XP, Server 2003, Server 2008, etc.  Imagine what that code would look like ...  After all, HTML is a standard, and I feel strongly that there is a solution in which browsers can process that HTML with equal respect.

I digress, because this post is not a complaint, but rather a solution for this pesky problem!  Allow me to introduce Adobe Browserlabs (thanks Coach).  Adobe has published a service that allows developers to pass a URL for inspection into the Browserlab engine.  The engine will take that URL and process a GET request for the URL to each of the browsers you specify.  From there you may examine how your application looks in a bouquet of browsers.  Browserlabs can be found at the following URL: https://browserlab.adobe.com.  The following image should explain everything

This is by no means a solution to the problem, but more a tool that allows you to do your job faster.  As any good developer knows, you are only as good as your tools!

{  Happy Coding  }

After writing my recent post for Consuming Cross Domain Services using jQuery, I started investigating how we could leverage the power of ajax with our flagship product for mobile solutions, MobilePipes.

The service layer for MobilePipes is written in the .NET platform using WCF. Right away I realized that we are missing support for JSON serialization. MobilePipes currently supports SOAP and POX formatting through WCF service configurations. Microsoft did a fantastic job with WCF with separating configuration from implementation so I knew that getting JSON formats in place should be a snap. One of the ways to achieve this is to define a different interface for the different services that we want to expose. SOAP formatting is a the standard Service Contract that by default is configured when you use the tools in Visual Studio.

Other formats get a bit tricky because you need to define certain attributes that instruct WCF how to behave at runtime. For instance, POX services are configured with the following configuration:

That's it! Simple as that.  This configuration tells WCF to return a string from this method in the HTTP GET request. In other words, it skips SOAP formatting and just returns the string ... in the case of POX it's simply XML.  Which gets me back to JSON. In order to get MobilePipes up to speed, we have created a new Service Interface with the JSON format.  All we need to to is add the format that we want returned like so:

Now any clients that choose to use JSON rather than a traditional XML format can just point to the correct Service Endpoint. All of these endpoints are encapsulated in their own assembly and call out into the domain library. All of this allows us to keep our domain library for MobilePipes completely separate while providing SOAP, XML, and JSON return formats.  With the recent serivce endpoint for JSON, any ajax libraries can now seamlessy call MobilePipes services.