This posting may very well be banter. You have been forewarned.
Everywhere I look I see services. I can get pizza delivered, my clothes dry-cleaned, and my shopping delivered to my home without ever leaving my computer. These are all services provided by someone, somewhere. A little closer to home I have my TV which delivers a digital service, radio which delivers an analog service, phone line which delivers a communication service, an XBOX which delivers an entertainment service, and even my kitchen counter, which props up the toaster and bowl of fruit, is performing a useful service.
Here’s a site I often use that provides a service that explains the meaning of words. The word I am interested in, surprisingly, is “service”:
an act of helpful activity; help; aid
Ok I ignored the other definitions but they all pretty much relate back to the concept of something, someone or some corporation doing something useful for others. Sometimes we pay for services, sometimes they are free. But really, services are there to help and form the cornerstone of our very society.
Now that you love services as much as I do, you’ll completely appreciate what this means in software engineering: A service is any code component that helps your application achieve completeness. It is not necessarily something that communicates over the wire, via named pipe or some message queuing application. It isn’t always found in the form of XML, JSON, or binary formats. Its just like your kitchen counter, a piece of code that provides a useful function to your application.
I think we often get too wrapped up in someone’s interpretation of various buzz words and lose site of the meaning of the words themselves. I have no problems using the term ‘service’ in a way that relates in no way to objects going over the wire, WCF, ASMX, etc. Instead, our repositories, factories, presenters, controllers, managers, builders, all those code classes that have a single responsibility, they are all services. For example, in an app I am working on now for a client (ASP.Net, WCF, MS SQL) I am using the MVP pattern and am using IOC (Ninject). I wanted my presenters to be responsible for navigation, but didn’t want them to know anything about page urls. So I created a ‘NavigationService’ (with matching interface) with a simple ‘Navigate’ method on it. It takes a view ‘name’ and looks up the sitemap to work out where to navigate to. This works great because now my presenters are controlling page flow without knowing anything about how navigation works. Its highly testable since my NavigationService can be mocked out easily (thus the interface). You obviously don’t have to put the word ‘service’ in the name, its just sometimes helpful if your class can’t easily be classified as a repository, factory, etc. If you had ‘Helper’ somewhere, generally you could probably replace that with ‘Service’ since it means the same thing.
Yes SOA means Service Oriented Architecture, not Service Oriented Application, and certainly not Service Only Architecture, which is what some people seem to think it means even when they say the word ‘oriented’. The term ‘oriented’ means ‘aligned’ or ‘related’ and in my mind, the literal translation of the phrase means “an architecture where the majority of modularisation is achieved through services”.
OASIS is a standards group and has a reference model for SOA which states:
“Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains.”
When we hear the word ‘distributed’ in computing we automatically assume disparity and remoteness. But again if we look to our word salad service (dictionary) we get:
“to divide into classes”
Oh this is almost too easy! Of course it doesn’t mean software classes (example, plant species as classes of plant distribution) but it fits too well to ignore. And those capabilities are of course our helpers, repositories, etc. The last part of that statement says “that may be under the control of different ownership domains”. I guess the point here is that it doesn’t have to.
Lets say I have a smart client application, WPF since that’s my drug of choice. I’ve broken it down into a main EXE and a separate DLL where I store all my repositories, builders, factories, presenters, etc. I go to great lengths to ensure everything acts like a service (as per my explanations above). All my capabilities are distributed into separate classes.
In this scenario, am I implementing a Service Oriented Architecture?
Well I’m overly focused on services, some services call others, each is defined by a contract (since I use IOC to locate and resolve them), the implementation is hidden behind the interface, and the only implementation not in a service is the UI. So as far as I’m concerned, the answer is yes!
The great thing about IOC and services in general in .Net is that you can easily turn one of those interfaces into a WCF service contract with very little effort. You want to ‘distribute’ over the wire? You can! The important thing is that you have control over how the services are surfaced.
So the final takeaway is this: consider SOA for every application you ever design. This doesn’t mean WCF, ASMX, named pipes, etc. It just means designing your application with individual services that take care of all your application needs. If you can do that, you will realise clean abstractions, encourage testability, improve maintainability, and create reusability. And I can assure you, once you adopt this style (and a good IOC container to help), you’ll never go back.
Some of that service stuff above is not overly relevant to what I’m going to talk about next. But SOA in general certainly is. Windows Azure supports division of labour very well: If your services are all located within one application assembly, then just provision one web project. If you feel you need to scale out certain services due to work load, slap some service contracts on them and push them into a new instance of their own. Want to keep some of those services on premise? No problems, use the Service Bus to route requests to your on-premise services, easily skipping through those firewalls. Want your data in the cloud too? No problem, stick it in SQL Azure or just plain old Windows Azure Storage if necessary. Hell you could even put it in Amazon S3 if you wanted, Azure doesn’t care: it supports these service abstractions easily and doesn’t know if the service you are calling is hosted in Azure, on-premise, through the service bus, or some external service (eg. S3, Flickr, etc).
The point I am trying to make is that if you follow the SOA principles above, your application design will “just work” when you want to move to Azure. The applications that are hardest to move to Azure are those with tightly coupled components and leaky abstractions. Its certainly difficult to adopt this style of development at first and is certainly something that your architect should be involved in continuously (code reviews, etc). But even if you don’t plan on moving to the cloud, its a great way to build your applications and helps you benefit in the long term. Once you get used to the style, it certainly improves your development speed, and removes dependencies on the components being built in other teams. And it certainly works well for large and small projects alike.
Foreword: Apologies for the title, I’m still not sure (after completing the entry) what it should be called.
Why would I use the Windows Azure Platform? Its a good question, one that I’ve had a lot of internal discussions on lately (fellow consultants from Readify). For most its quite a paradigm shift and therefore difficult to grok. Many believe that you can only build Azure apps from scratch and that it would be a lot of work to convert an existing product to use the Azure platform. I don’t want to say this is a false statement, but Azure is pretty big, bigger than most people realise.
Most of us are only familiar with the Windows Azure component which allows you to host either services or web pages. Most custom applications require a data store and for Microsoft developers, this tends to be SQL Server. Unfortunately there is no one-for-one mapping to easily port your database over to the data stores in the cloud (Windows Azure Storage, SQL Azure, etc). This means people feel resistance when they do consider the Azure services and write-off the whole platform.
When SQL Azure is presented as an option, people tend to pick on the little features that are missing, expecting a direct cloud equivalent for their data. But some things just don’t make sense for SQL Azure. People lose context: SQL Azure is a service. It should be treated like any other service within your architecture. You don’t need to be implementing the next service related buzzword (SOA, SaaS, S+S, etc) to get the benefits of the abstractions provided by services. If you build your services in an autonomous fashion, SQL Azure will fit right in with your story.
What about off vs on-premise data storage? I hear this one a lot as well. I want to control my data, I have no need for Azure. This is an easy answer for me, and I defer back to my last statement. Its a service driven world, your data should be the same. Where that service is located should be irrelevant. This is where the .Net Services ‘Service Bus’ steps up. It can route your data to your other services/applications extremely easily, with top level security all the way, so not even Microsoft can see what is being transmitted. What about my firewall, it will stop people from seeing my service right? No problem – the service bindings use outbound connections to connect to the Service Bus, meaning that you can host your own services on-premise, behind your firewall, and still get flawless connection to/from the cloud.
Modularity, loose-coupling, single-responsibility.. any of these terms ring familiar for you? As a developer I enjoy building applications that realise these design qualities. I use Inversion of Control and Dependency Injection wherever possible, and have realised that my code classes have somewhat turned into services. Not like ASMX or WCF services; just classes that have very defined purposes, are abstracted by a contract (interface), and provide a service to the rest of the application.
I won’t lie, since being introduced to IoC my programming style has changed, and I think that this happens for most developers who use it as well (regardless of implementation technology or language). You start viewing everything as services, even your Views (since we all love MVP, MVC, and MVVM). Quite often when I’m with a client discussing aspects of an application I might say “.. so we’ll just create a service for blah…” not realising that it might have a different meaning to them (however its not long before they agree with me and start referring to things the same way!).
So I honestly believe that services are the next level of developer evolution (“devolution” anyone?), whether we mean actual web services or just classes that service our application. For me this even brings about new meaning for Service Oriented Architecture – design your systems to be service based whether those services are across the wire or not.
<Disclaimer> I am an advocate of smart clients and believe everything should be services and that web pages are evil and should only exist to help find smart clients</Disclaimer>
Yes. Well no, but you should certainly think about it for all new applications, regardless of whether you are considering Azure or not. I honest believe it is just good design. As for existing apps, consider the key dependencies. These might be file storage, relational database, data mining, 3rd party components, etc. Write a list and detail each one individually. Is their a mechanism you can use to abstract the calls to that dependency? Perhaps IoC will work for you, or perhaps the ASP.Net Provider model will help you. Or perhaps you just need to wrap the calls up in a new class in a separate assembly.
The next step is how those dependencies will work in the cloud. Do you need to replace any? Can they also be moved to the cloud? Do they need to be rewritten as services? Do you need to expose their functionality from within your organisational boundaries? This is where a lot or a little work may need to happen. Those applications that already have looser coupling will find this part easy. For example, you may already have a class that handles your database calls. A customer class might have a create, update, and delete methods, which wraps calls to LINQ to SQL (L2S). Well its very easy to indentify your customer class as the service boundary, and move the L2S code to a new service. All you need now is to think about the security and you’re done!
Once you have a firm plan for dealing with those dependencies, the rest should be a piece of cake. Obviously what happens next will differ for web and smart client apps, but the dependencies are really the most difficult thing. When you have hard wired dependencies to 3rd party solutions (eg. K2) you might find that it is very difficult making the transition to Azure.
Well the same rules apply, only that you might get an added benefit from creating products that can easily by run on Azure. For example, check out SplendidCRM – a CRM product recently refactored to run on Azure. Why? Well what if you want a CRM product but don’t want to host it yourself? Kinda seems smart to me… allow the purchaser of your software to run it anywhere they choose, on or off premise. And then of course there is the multi-tenant applications designed to only run in the cloud, like Saasu and Salesforce. If you want to go viral, you need to be prepared to scale quickly!
Its hard to say exactly when you should consider Azure, but I guess the point of this post is not so much to answer that question, but rather to provide you with some insight into good design techniques, that when followed properly, will provide you with an application that can easily be deployed into Azure, or any other cloud platform for that matter. If we’re doing things right at the bottom level, then we can be flexible with the higher level architectural choices.
So please check out the links for any of the concepts I’ve mentioned above (or listed below) to ensure you and your team are familiar with them. And if you have any questions, please feel free to email me.
Some more links:
I recently received an email asking what the migration story is like for moving apps onto the Azure Services Platform, and I wanted to share my answer (which is only my opinion) with you all.
The thing about Azure is that it is an application platform. This means there’s certain interactions that are required in order to get your apps onto Azure.
In my opinion Azure is best suited for SOA, SaaS and S+S type applications; those that are heavily componentised and can exist within their own right. If your architecture is decoupled in this way then the migration to Azure becomes a lot easier. The service definition file that you package with your Azure Cloud Package is just that: a summary of all your various services and how you want them configured in the cloud.
Certainly ASP.NET and WCF applications are the easiest to move. I would see moving to Azure as an opportunity to decouple your applications and focus on SOA. Determining an amount of work for any app will be difficult, but in nearly all reasonably sized applications it won’t be as easy as copy/paste.
The majority of developers in the modern age are not overly experienced at building scalable, parallelisable applications. Most applications are not designed to handle multi-threaded, multi-instance scenarios. While this isn’t an inhibitor, it does mean it’s difficult to leverage the platform effectively, and it means that a product owner of an existing product is more likely to need to scale by instance (add another server/instance) when in fact they aren’t leveraging their current instances effectively.
I don’t think that moving to the Azure platform by plonking in the files is the best strategy. I’d like to think that it would fall into a ‘sprint goal’ to make any application able to leverage the Azure platform, and I think that would include a strong services aspect. Any large application will require a migration plan for any kind of move. Sometimes if you are even moving an application around in your own data centre, it can require weeks of planning. Azure is certainly the same, except that the migration may also require some development effort.
One final thing to think about is of course domain name pointers. In on-premise scenarios you already have your network sorted out, but in the cloud you need to think about what will be public facing, and what your naming strategy will be.
I don’t think we’ve seen the end of the Azure feature releases and I’m sure there will be something in the final release that will make the whole migration process easier.
If you are new to Azure you might be overwhelmed by what the various services do and don’t do. I don’t think the Azure site has done a good job of explaining how each service is used separate unto others.
Then today when I was searching the Azure Forums for something else, I came across this thread where Yi-Lun Luo explains what each of the four services is used for and some basic information about each.
Quoted:
Windows Azure:
- Write, read, and delete resources (in the form of Blob/Queue/Table) containing from 1 byte to 50 gigabytes of data each. The number of files you can store is unlimited.
- Each resource is stored in a container and retrieved via a URI in the form of <http|https>://<account-name>.<service-name>.core.windows.net/<resource-path>.
- Currently all data is stored in the United States, but can be accessed from anywhere. We’re building more and more data centers around the world.
- A container can either be public (the requests do not need to be authenticated) or private. Currently you can’t specify access control on a specific resource.
- Uses standards-based REST interfaces designed to work with any Internet-development toolkit. We’ve also built a wrapper library on desktop .NET platform (not Silverlight or .NETCF) for easier working with the APIs. In the future, maybe SOAP APIs will also be provided.
- Currently only http/https are supported. Additional protocols will be supported in the future.
- A resource is at least duplicated for three times to prevent data loss.
- Ability to host server side partial trust web applications in the cloud. Currently the only supported technology is .NET. Additional technologies, such as Java and PHP, will be supported in the future. Also less security limitations will be forced in the future. Client side applications can either be embedded in a web page (Silverlight/Flex) in a web role, or deployed on the user’s desktop and work with the storage APIs.
Live Services (AKA Live Mesh):
- Synchronize any kind of file on any device a user owns. The data will be stored in the Mesh as well as on the devices. Up to 5 GB data can be stored in the Mesh. Larger space will be provided in the future. Each file doesn’t have a size limitation.
- The device can be PC running Windows, Macs, Windows Mobile Devices, and Mesh Web Desktop. More devices will be supported in the future.
- All devices, files, applications, and other kinds of data stored in the Mesh are considered to be resources, and can be accessed in any authenticated applications.
- The end user controls which resource to be private, and which to be shared with friends.
- Resources can be accessed and updated through Atom Feeds in the form of REST APIs. A .NET library, a Silverlight library, and a JavaScript library are also provided for easier working with resources.
- Provides mechanisms to run web applications (Silverlight or AJAX) offline, outside of the browser. Modification of the data will be synchronized the next time this device goes online.
- Built upon Windows Azure. Can be taken as a case study of services hosted in Windows Azure.
- Part of the Live Platform which contains a lot of other services, such as Live Search and Virtual Earth. But I don’t know much about them…
.NET Services:
- Provides Service Bus to connect existing services behind firewall and NAT, and integrate applications.
- Provides Workflow Service to automate business process which involves calling a lot of services.
- Provides Access Control to determine which application/service can call a specific service or participate in the workflow.
- A desktop .NET SDK and a Java SDK have already been provided. More technologies will be supported in the future.
- Service Bus supports the http/https/tcp protocols. Services can communicate either one way or two way in any format (xml, binary, etc). It also provides NetEventRelayBinding to support multicasting.
- Access Control supports username/passwrod, CardSpace, and X509 authentication. More will come in the future.
SQL Data Services:
- Provides a cloud database to store data in the relational architecture.
- Supports CRUD operations over entities through standard-based REST and SOAP interfaces designed to work with any Internet-development toolkit.
- Each entity belongs to a container. Each container belongs to an authority. Entities do not have a specific schema. Two entities in the same container can contain different properties. This is called flexible schema. In the future, strict schema (similar to columns in traditional databases) will also be supported.
- Supports cross entity join queries in the same container. Cross container queries will be supported in the future.
- Provides blobs to store large data up to 100MB. Larger data will be supported in the future.
- More features, such as data warehouse and data mining, may come in the future.
Thanks for such a great explanation Yi-Lun!
Welcome to my new blog, ‘Above The Cloud’ where I will be exploring “the cloud” as it relates to the development community, with a particular focus (but not limited to) the new Azure Services offering by Microsoft.
At PDC08 Microsoft announced www.azure.com and in their own words:
The Azure Services platform provides a wide range of internet services that can be consumed from both on-premises environments or the internet.
Currently the Azure Services Platform is available on an invitation basis only, however you can apply for an invitation token via the Microsoft Connect program which is their community connection point and a place where you can register for all sorts of trials, alphas, etc. I suggest you sign up to Connect today, have a browse of any previews you might be interested in and apply.
What happens next is that eventually (could be a day, could be a month) Microsoft would widen their invitation base on a particular product, and you will receive an email with an invitation token. Once you receive your Azure token, you can connect to the Azure Services Platform.
Please note that there are a number of different services you can apply for in the Azure space. The 3 primary ones are:
The first focuses on high availability of web sites and services through load balancing and dynamic allocation of resources. At the click of a button you can take your website from a 3 node cluster to 4. The second is the platform for developing .Net applications in the Azure space. There is an SDK available from here that lets you simulate “the cloud” on your desktop. Finally, Microsoft Sql Services is the cloud-based database offering that will let you store data in the cloud.
All 3 services are available for you to play with now! And this blog will be dedicated to helping you explore all these services, the SDK’s and much more. So go check out www.azure.com now and signup so you can join me as we uncover the mysteries of the cloud.
More Options ...
Categories
Tag Cloud
Blog RSS
Comments RSS
Void 
Life 
Earth 
Wind « Default
Water 
Fire Light Bad Behavior has blocked 310 access attempts in the last 7 days.
Last 50 Posts 
Back