Schemas and Content – Because you are working with messages and the data that is within them (i.e. contracts) you have this by default.  The topic is messages that are passed through the infrastructure. Boundaries – Messages being the topic sent through the infrascture allow you to maintain policy and routing based on those messages.  This allows you to maintain boundaries and can keep your services fenced.

Had to take a double take on this one.  Microsoft opening something up under the Apache 2.0 License -> http://www.infoq.com/news/2010/11/FSharp-Open-Source

We have been poking at different hosting models here at Syndicated Methods for our MobilePipes platform for some time now.  As we roll the product out to more and more customers we want to provide the most convenient way possible to consume MobilePipes instances.  Provided that MobilePipes is a .NET platform Azure has been on our mind for some time.  While doing some research I stumbled along the following article that I wanted to re-post for our audience.  

Understanding Windows Azure Storage Billing – Bandwidth, Transactions, and Capacity

As a multi platform device consultancy, we constantly get asked from our customers the difference between the development environments they use verses other mobile and device platforms.  Probably the most common, as you would imagine, is the difference between iPhone and the Android.  InfoQ just posted a recent article summarizing posts from David Green and John Blanco.  It seems like each of the posts come from different preferences, so it's great to hear the difference of opinion.  They do a great job though of summarizing the key differences.  I think they covered the topics well, but they missed one major mark that I would give Apple a fail on.  For some reason Apple has decided that it's a good idea to bundle the SDK with a new version of xCode.  It just seems wrong to me that when I want to target the latest IOS bits I must also download their xCode IDE (~ 2.5 GB each time)!  The  consensus is that, although each have their own drawbacks, Apple wins the vote for simplicity, and Android wins the vote for being the most feature rich.  Kind of funny that their development platform matches their devices!

Enjoy!

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 }