I’m currently working my way through the subject of Service Oriented Architecture, or SOA.  I have a book on the way, but I’m getting a jump on the subject.  In previous blog posts I’ve talked about the necessity to do research.  This is one of those instances where I have applications to do some task and I need to learn the technology to make it happen.  Sometimes it can take a couple weeks to learn a new technology, type in a few test programs and then obtain that “aha” moment.  Once that occurs, then it’s time to design and implement.  In the case of SOA, I haven’t quite reached the implementation “aha” moment yet.  I understand the overall purpose and what I will be using SOA for is to transfer data between iPhone apps, iPad apps and our database.

So I’ve done a bit of digging and I’ve stumbled across a few technologies that I’ve seen in the past but paid no attention to (due to the fact that I had no purpose for them before).  One technology I’m focusing my attention on today is WCF.  WCF is the Windows Communication Foundation and allows two apps to communicate.  Primarily an app (any application) with a service running on a different server.  I plan to run a service on a server in the computer room and make a secured connection (probably SSL) between a mobile device and the server.  The service will be able to read and write data to the database.  This will enable our field personnel to record information with their iPhone or iPad.


Before I get to the whole design and implementation, I have to test a few technologies to see how I can apply them.  I’ve already tested JSON and I’m satisfied with my knowledge of JSON for now.  At this point, I can design a software specification that indicates how JSON will be used and I can either code this myself or pass on the information to a programmer that will be implementing the actual coding.

I found this very simple example of a client and server test setup for WCF:

A truely simple example to get started with WCF

So I copied the code into a console application and I had to mess around with it a bit to get it to work right.  One thing I changed that was not indicated in the article is that I put the server and contract into a separate project of the same solution.  I had to do that in order to keep the complier from complaining about two entry points.  Technically, I have a solution with two console applications in it.  One is used as a module for the other.  It works, and it’s just a R&D test case.  My next step is to separate these sections and run them on separate PC’s to see if they’ll communicate correctly.  After that, I’ll put the server inside a service component and test it under that condition. 


Representational State Transfer (REST) is not a subject that I am currently familiar with.  That’s my next subject to study.  I will be focusing on this subject next.  Rest is supposed to be lightweight and simpler than RPC.  I will be judging for myself.  Not that I’m skeptical, I just want to see how this works.


As I mentioned before, I’ve already done some R&D on JSON and I’m impressed.  My plans are to use JSON instead of XML for structured data transfers. 


My point in this posting is to show that nobody is an expert in every subject.  They best way to become an expert in a subject is to keep your eyes open to what technologies are available.  Sometimes I see an acronym that I’ve never seen before.  It starts to get a lot of hype in magazines and news articles.  So I lookup the definition or wiki on the acronym and see what the actual purpose is.  If it’s something that could revolutionize my projects, then I start to investigate it more (or I’ll relegate a software developer to R&D it and report back to me with a small demo).  Once a demo has been created, then I can evaluate the usage of the new technology and incorporate it into our business plans. 

Other times, I have a problem to solve and I know that other companies are doing this very task (i.e. talking between iPhone apps and their databases).  So I start searching for information on the Internet.  It usually doesn’t take me long to come up with one or more technologies that are candidates to becoming my solution.  After that, I just work my way through each innovation until I’m satisfied with the solution I want to work with.

In this business you can never stop learning new things.