To Cloud or not to Cloud, thats not even a real question

I have read a few posts about Cloud computing on the net. Some of them show great fear of this new thing where a computer is not just a computer and a program is not just a program. How do you back up data and how do you keep it away from others?

To me cloud computing is about abstracting away from hardware instances and thereby allowing easier scalling and distribution of computing. Cloud computing is to instance computing as functional programming is to imperative programming or SOA is to system integration. Instead of defining how you want it you must define what the needs of the application are. This could turn out to be a lot more productive than what we have been used to.

I don't nescesarily think that if you go the Cloud way you have to place all of your data somewhere out of control. It might very well be that parts of your application needs to scale well and you can put that part on a Cloud that supports this. Other parts of you application that has other requirements might have to be put elsewhere, maybe even on the cloud on your own network.

Having few dependencies has been a goal in software development for a long time, and now its moving to the hardware platform. This is a good thing as application requirements will hopefuly be much more transparent in the future.

Wrapping objects with interfaces

Have you ever had to map data to or from 3rd party components? Have you ever had to use reflection to access properties or methods you know the signature for on object you dont' have type for at compile time? This has happened a few times for me, especially when I have to deal with webservices defined by autogenerated classes.

My solution to this is to create an interface that resembles the objects I need to handle. I have made a small helper that will make proxy object for you that implements the provided interface and forwards all property calls and method calls to the object you need access to. This is how you can use it.

IMyInterface wrapped = anyObject.WrapAs<IMyInterface>();

Now you are able to create an interaction that can operate on your object. This might also be a way integrate with components you don't want a direct dependency on.

Statefull SOA

I am attending a course on WCF (Windows Communication Foundation).

State full services are sometimes not considered 'right' when speaking of Service Oriented Architecture (SOA).

My claim is that state has nothing to do with whether a service can be a good entity in a SOA architecture. You might have a strategy that your services should bee RESTfull, but that has nothing to do with whether your architecture is service oriented or not. REST gives you some other properties (quite useful I might add), but doesn’t influence the architecture towards SOA.

The same goes for callbacks. Even though my telephone company allows people to call me on my phone, I still consider my phone connection to be a service provided to me by my phone company.