This post originated from an RSS feed registered with .NET Buzz
by James Avery.
Original Post: Adventures in SOA, Part 1
Feed Title: .Avery Blog
Feed URL: /blog/Install/BlogNotConfiguredError.aspx
Feed Description: .NET and everything nice
I have started work on a new side project and have decided that I am going to try and implement this project using a service-oriented architecture. I usually try and use side projects as a way to learn new things, and explore new technologies, and this is a perfect opportunity to better explore SOA. I also decided I would go ahead and blog about it here, so people can correct me where I am wrong, and perhaps learn from me when I am right.
The Application
The side project I am working on is a .NET news site, something in the same vein as Slashdot, Neowin, or TablePcTalk. I am calling the site devFrequency or devFreq for short. My goal is to try and create an online community surrounding .NET development similar to what exists at Slashdot. (ambitious eh?) Some people might question if sites like this are still needed, considering the increasing popularity of blogs, but I would argue that sites like this still offer value in a number of different ways. They offer a more frequent and consistent source of news, as well as a place for everyone to discuss the news in a common place.
Step 1: Understanding SOA
I am not completely ignorant on the subject of SOA, the current application we are building at work is somewhat service oriented. How can it be somewhat service-oriented? Well, it has a service interface and uses .NET remoting to communicate between the windows form application and server... But since we are sharing types between the windows app and the server, as well as using binary transport, it does not have the flexibility that true SOA might have. (That flexibility being that everything is tied by a schema, not a type.)
So I started this with a small bit of knowledge, but I needed to know more. First I checked out Don Box's SOA focused MSDN TV Episodes (Part 1, Part 2) which are focused on the "big picture" of SOA, then I read a bunch of small articles on the net that were all focused on the big picture of SOA, without getting into the details of implementation. The most promising development in SOA is the Shadowfax architecture, a best practices architecture demonstrating how to implement SOA in .NET.
Step 2: General Architecture Decisions
I have figured out just enough to be dangerous, but first I have a couple decisions to make. The 1st is what type of transport to use, I could use remoting, MSMQ, or XML Web Services... I have chosen XML web services because I feel future compatibility is very important and that XML lends itself to future compatibility more than the other transports, and I also think there is much more flexibility in using schemas. I also want to make some of the services available to other applications and developers, and XML WS are the easiest to integrate.
The second decision I made was that I wanted authentication and advertising functionality to be multiple site aware, meaning that I am going to build a single set of services for authentication and advertising that I can then use on this site as well as any other site. These functions will be implemented as XML web services and will be called from either the other services, or the front end ASP.NET. (I have not decided this yet) In the beginning they will be on the same physical server, but eventually they will probably have there own server.
The rest of the functionality for the site, including working with news items, admin functions, etc, will also be implemented as web services and will be called from the ASP.NET front end. (Probably through some sort of proxy class).
Performance Concerns
All these web services have me concerned as to what the performance of this application will be, considering that instead of directly calling the middle tier through a .dll ASP.NET will be calling any number of web services. This means that for each page hit I will hit my server 2 or 3 times.... but at least I know it will be easy to scale to multiple servers. (Don't know how economical that will be though)
Confusion
The one major thing I am not sure about is how to build the internals of the services, should I still use business components and a data access layer? Should they still be object oriented? Or should they be more focused on each service?
Look for Part 2 in the next week or so as I work more on the architecture of this side project.
Previous Topic
