Cloud Computing Hype at Fever Pitch

There are some big names jumping into cloud computing in a big way. With announcements, rumors etc from IBM, Cisco, Sun, Microsoft, it's hard to ignore what's going on. The question to me is how much of this is hype designed to sell more hardware and software licenses and how much of it is really good stuff.

I think most of us remember the not to distance '90s. All of the above vendors made a killing selling stuff that turned out to be somewhat useful but not nearly as useful as the hype suggested (I worked for one them so no bias here :)). After the bubble crashed SOA sprang from the ashes like the proverbial phoenix. The promise of business agility and reusable software was the calling cry. And companies bit once again.

Here we are in 2009 and folks are finally starting to figure out that A word in SOA is not about what you can buy. Good news for the business, bad news for the software and hardware vendors. Alas we need something new to sell. What about white puffy things you see in the sky? Everyone likes white puffy things, I bet we can sell a lot. Okay I know I'm being a bit on the cynical side but I can see the vendors lining up to tell me how they can cloud enable my water fountain(It's already SOA enabled).

I do think there is promise in the clouds but I'm also a bit wary whenever vendors start generating buzz like this. When the vendors show up at your door just make sure to raise your right eyebrow. There is a lot of potential with cloud computing, there is not doubt about it. If you want some good coverage of cloud computing, check out Brenda Michelson's live blogging on the Cloud Computing Expo. Brenda has actually worked in the real world and provides pragmatic insight into this topic and others.

See you in the clouds.

Big Blue to become Big Blue Sun?

Early reports coming in on IBM thinking about buying Sun.  http://www.pcworld.com/article/161456/report_ibm_is_in_talks_to_buy_sun_microsystems.html

 

I have to wonder is this a response to Cisco's push into the server market?  Is this the beginning of the end for Solaris or is it a new life for Solaris?  This will be an interesting one to watch.  It maybe good for Sun which seems to be completely inept at getting any kind of marketing going at all.  I'm not entirely sure what IBM is gaining from this.  I hear the server market noise but I'm not sure I totally buy into that.

 

 

 

Reuse and Agility Part II - Service Testing

In my previous post I talked about some practical design considerations for achieving reuse and agility in your services. This post is going to focus on another critical element in achieving reuse and agility. That topic is testing.

Testing is one of those topics we don't spend near enough time talking about. Yet testing is probably the most critical element to successful reuse and agility. Being able to test quickly and thoroughly will determine how agile and how reusable the service will be.

There are many roadblocks to testing. Here are some of them in no particular order: Clients, Developers, Project Managers, Managers, Bystanders, Custodial Staff, Butterflies in Japan. The point here is just about everything seems to get in the way of testing. These roadblocks can be navigated successfully if you approach testing a slightly different way.

One way to bake testing into the design process is to go with the Test Driven Design approach. I'm not going into detail about it but here is an article on it if you are not familiar with it. Another way to bake in testing is the use of commercial test suites(Note-the two ideas are not mutually exclusive). There are many quality products available on the market but I'm going to talk about a free one called soapUI.

You might think this article has now turned into a product evaluation but it's not completely. I am going to show how a tool such as soapUI can help you test quickly and effectively. soapUI does have some powerful testing features baked into it which makes creating test cases somewhat easy to do which is really the point of this discussion.

The WSDL interface definition is pretty simple in construct. It basically says you give me this and I'll give you that in response. Beyond that the variation of use cases is left up to other documentation and/or test cases. What I have found with using a tool like soapUI is that the act of creating the test cases help flush out the use cases in more detail. It also allows for the documentation of the test cases and reporting of the results which will be useful later on when demonstrating pass/fail on the interface.

soapUI will allow you to import your WSDL and generate sample test cases prior to ever coding any of the implementation. It even has the ability to mock responses back so you can run the test cases prior to coding. This can be a very powerful concept. At this point variations in the use cases can become visible allowing you time to go back to the clients before a whole lot of work has been done. I think the benefit is obvious here. Better software more closely aligned with what the client actually wants.

Here is a great feature that soapUI offers when generating test cases. The ability to add assertions for each test step very easily. All testing tools let you do this but with soapUI it's just simply and straightforward. Here is a screenshot using XPATH to determine the correct return result. Pretty simple stuff but very useful.



This test case is now invokable by creating a simple mock service within the soapUI tool.



No code has been written but now your test cases are defined and documented. And the big win is they are easy to repeat once the real coding begins, is complete and is changed later on down the road. Simply change the endpoint and fire away. Very simple yet very powerful.

Service Reuse and Agility

One of the benefits of a SOA style of architecture is reuse of services.  It is also one of the more challenging benefits to realize.  A lot of people found early on that simply slapping a Web Service out there and calling it a service along with opening the flood gates to use it was not such a good idea.  Because of ill defined definitions, wrong service granularity and lack of governance, a big mess was created.  Agility and reuse went out the door.

 

Here are a few thoughts on service design that have helped me achieve a fair amount of effective reuse and agility. 

 

1-Granularity

 

Coarse grain versus fine grain is the basic decision point.  The more coarse grain the service, in other words the more stuff it does, the less likely reuse will occur.  What I have found to be effective is to start with a lot of "medium" grain services.  These services do something beyond the basic add two numbers together but stop short of containing a lot of business rules.  They tend to lend themselves to orchestration by multiple business processes.

 

These services also make up the core of the composite services.  The benefit here is these services can appear both in the higher level composite services as well as be accessed directly.

 

2-Data Binding

 

Data type conversion among the platforms is challenging.  Simple guideline here is keep it simple.  Go here for more detail but I would recommend keeping it even simpler when you can.  Remember string is king.

 

3-Exotic WSDL

 

Along with the thought on data binding comes exotic WSDL.  Same kind of mindset applies here as well.  Just because you can put it into a WSDL doesn't mean you should.  The more stuff that you put into a WSDL the less likely its going to be compatible with everything that needs to consume it.  Agility can take a hit here too.

 

Key point here is WSDL is just a definition of an interface not the implementation or the consuming service.  It's up to physical implementation to actually provide the concrete stuff.  That's were things can go astray.  Chances are you have a lot of stuff in your enterprise.  The chances that each thing you have will support the wide variety of stuff that can be stuffed into an interfaces definition is remote at best.

 

The other issue is that to much stuff in the definition can create a brittle interface instead of a robust one.  Agility suffers and reuse is difficult.  I would in most cases steer clear of putting strict business rules in the WSDL. 

4-Governance

 

Some level of governance is required to managed this entire approach to designing systems.  It doesn't have to be overly complicated but should include things like: code reviews, interface design reviews, testing polices and change policies.  Sometimes when governance is put in place it's at to high of a level.  Governance in the SOA world has to be very active and down in the trenches.

 

Reuse is possible in SOA.  But you have to take care not to over engineer your interfaces.  If you do that then reuse can be achieved and agility will also magically appear.

 

 

 

 

 

Dell Latitude E6400 Review

I'm going to make this short and sweet. I got a new laptop to replace one that fried. It's a Dell Latitude E6400 loaded with Windows Vista Business Edition. The bottom line - it works like a champ. Great performance, short load times and no issues. I don't know what everyone was whining about Windows Vista but I like it and have had no real issues. Performance has been very good, very stable and no connectivity issues to speak of. I'm not saying I would upgrade to Vista but I wouldn't complain if I got a computer with it.