This post originated from an RSS feed registered with .NET Buzz
by James Avery.
Original Post: Adventures in SOA, Part 2
Feed Title: .Avery Blog
Feed URL: /blog/Install/BlogNotConfiguredError.aspx
Feed Description: .NET and everything nice
I finished my last post on SOA wondering how I was going to build the internals of the services in my application, most literature out there on SOA talks about building services but usually fails to talk about the implementation of the actual services and the internals of those services. One of my readers, Andy, was kind enough to point out that the choices I talked about in the last post basically boiled down to either the Domain Model pattern or Transaction Script pattern, if you refer to Fowler's patterns. When you look at it like this, it is a no brainer that I would go with Domain Model every time just because of my fondness for OO design, but I don't think it is this simple when you start to talk about SOA.
For me the main benefit of SOA is that you are binding components through the use of schemas and contracts which are much for flexible than traditional methods of component bindings (method signatures, etc). Don Box said it best:
"Because the contract and schema for a given service are visible over broad ranges of both space and time, service-orientation requires that contracts and schema remain stable over time. In the general case, it is impossible to propagate changes in schema and/or contract to all parties who have ever encountered a service. For that reason, the contract and schema used in service-oriented designs tend to have more flexibility than traditional object-oriented interfaces. It is common for services to use features such as XML element wildcards (like xsd:any) and optional SOAP header blocks to evolve a service in ways that do not break already deployed code."
So my goal with SOA is to take advantage of this flexibility in the smallest feasible component, meaning that any interface that may need to be independently updated or modified should be implemented as a service. The keyword here is feasible, as we could build every single call from one component to another as a service, and while this may be possible in the future, it would be a nightmare on performance and development time with present technologies. In the future it is possible that ASP.NET would call a service that then calls services on business components which in turn call services on a data mapper which call services on a database. (Web Services on Yukon starts to look less silly in this context) This would be awesome from the standpoint of flexibility, but you would be reading and writing XML 4 times to write a value to the database which is not something I am willing to do.(Sure you could use binary, but you are still serializing and incurring significant performance costs) The question is how to divide the functionality, and here is the basic split that I have come up with for this application.
Authentication Services Authenticating Users Adding/Updateing User Information
Advertising Services (I might split this even further) Serving Ads Purchasing/Reporting of Ads
News Services Administration of news items Retrieval of news items for viewing (web/rss)
Poll Services Administration of polls Retrieval of polls and poll results
There will also be a number of infrastructure (logging, etc) services, but I have not yet decided how to handle those. (And if they even need to be services, or if they should be implemented for each individual functional component)
Each of these functional components will be built using common business objects using the domain model pattern. The main reason I have singled out these functional groups is because they are the smallest functional slices that I can see myself revising or modifying and to get the most out of using common business objects.
Next I am going to try and figure out how best to implement the client(ASP.NET) and what sort of helper or proxy classes should be used.
This is all very new to me, so I would be interested to hear what other people think of this.
Previous Topic
