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.

Java EE 6 Overview from Reza Rahman

I saw this Java EE 6 Overview over on The Server Side by Reza Rahman.
It's a good quick read on what's coming with Java EE 6. Here is the
link -
http://www.theserverside.com/tt/articles/article.tss?l=JavaEE6Overview

Future of Operating Systems

Where are operating systems heading? I haven't done any in depth evaluations of operating systems in a very long time. I've been working the application development side for a long while now. I still find the need to keep my working knowledge of the systems going from time to time. I recently, with the help of Sun's VirtualBox and Microsoft's Virtual Desktop, installed some of the latest releases of Fedora, OpenSolaris, SUSE and Microsoft's latest Windows 7.

First of all let me say that all of the operating systems installed without any issues at all. It was completely painless. The one interesting note, funny actually, was that Microsoft's Windows 7 beta would not install in their own virtual manager but installed without any issues in Sun's VirtualBox.

Looking at the OS's from a strictly desktop perspective the big thing that jumped out at me was nothing. Yep I saw nothing of real interest. That lead me to the question, have operating systems for the desktop reached a maturity level where changes now are incremental and uninteresting from business use perspective? Yes I can see where the technical operating system enthusiast would like the latest and greatest, but what is there or coming that would drive a corporation to want to upgrade? Upgrades of operating systems, especially desktop, can be pretty expensive and painful. There usually has to be a significant justification.

Microsoft has in the past been pretty successful at pushing folks to upgrade by simply forcing the issue. That strategy as of late hasn't worked as well. So where do operating systems go to make upgrading compelling? What does the typical operating system need to do for the corporate user? It needs security, it needs to run their office productivity apps (Work, Excel or OpenOffice etc) and it needs to be an effective container for their web applications. Is there really more than that? What is going to drive upgrades now?

Oracle Patching

Oracle has plans for a big security set of patches. Can we not just go Jack Bauer on these folks? I mean seriously enough is enough. Can't we just get some people with machine guns to go after these people, the hackers/crackers I mean, not Oracle. :)

The Benefits of Open-Source Software

I was reading this thread on Open-Source ESB's at The Server Side and that got me pondering why more companies don't go after open-source software. While I am a fan of open-source in general I do see several issues for enterprise wide adoption. It also started me thinking why folks who are proponents of open-source in their enterprises really like open-source. Is it truly because it's open or is it because it is generally cheaper to initially acquire?

Let's start with the issues of open-source software. The two main ones are probably support and longevity. I haven't done any studies so this is just based of my experience but typically support is not used heavily for an enterprise class application. There maybe a few "serious" tickets in a given year for an application. Out of these "serious" tickets, how many are actually resolved by the vendor? There is a pretty big premium paid for that availability of support that is not used all that regularly. However it is there if you need it. The perception of open-source software is that in general you are on your own.

That perception is not always based in reality. A lot of the better open-source vendors have similar support offerings as the major proprietary vendors. Of course the cost of those open solutions goes up a lot when the support contracts are added on to the price. If you take a look at SUSE or Redhat on the OS side of things, you will find their support contracts comparable to Microsoft, Sun or HP in terms of cost. The down side to support contracts is that they can also require you to upgrade on the vendors schedule instead of yours.

The other issue with open-source is longevity of the vendor. The perception is that going the open-source route can be a gamble in terms of whether the vendor or users who maintain the code base will continue to exist. This is a legitimate concern but with a caveat. If the vendor or users no longer maintain the code, the source is open and in your possession. The real question is, is that a useful thing? Most enterprises usually negotiate with their proprietary software vendor a clause in their contract that says if the vendor goes out of business the company does get the source code. Is that useful? Would most enterprises be capable of doing anything with the source code?

I have never really bought into the proprietary argument of software. My opinion on this has always been the vast majority of enterprises are not equipped to or even should take advantage of having source code. Enterprise IT shops are there to provide business solutions not spend time on the platforms or packages that deliver those solutions.

There are some quality open-source software out there that many large enterprises and smaller companies should consider. There are cost savings and quality that can be gained by going that route. But you have to evaluate those cost closely with you existing proprietary solutions on an even basis. The upfront cost of software acquisition usually pales in comparison to the cost to maintain it. So while open-source is generally easier and cheaper to initially acquire, the long term maintenance of the software can be just as expensive as its proprietary counterpart.

Sun's xVM VirtualBox

If you are looking for a cheap(free) VM solution for your desktop, take a look at Sun's xVM VirtualBox. I was amazed and just how simple and easy it was to get up and running.  I had Solaris 11 and the latest Fedora up and running in less than 1/2 hour.  And most of that was download time.  Sun really doesn't do a very good job of advertising some very good software products.  Netbeans for example is a better Java IDE than Eclipse.  But you would never know it.

 

SOA versus SOI continued

Five or six years into the discussion (or 20 depending on who you ask), the debate is still going on what SOA is and what SOA is not. Is it any wonder folks are questioning SOA's value? We are still having debates on what it is. Here are a few links in case you are still recovering from New Years. My take on this is below the links.

David Linthicum's take


Anne Thomas Manes take. Love the cartoon by the way.

Zapthink's take


Joe McKendrick's take

Most of the current discussion is around the role of Integration in SOA. The discussion is fairly well covered in the above posts. I would add that agility was a goal of EAI. Agility was achieved by the construction of loosely coupled services within the EAI framework. Yes services existed, do exist, within the EAI space. EAI was not about connecting System A to System B. It was not about data synch or data replication. That stuff is basic integration. EAI was about abstraction, reuse and agility. Don't believe me? Do a search on EAI and see what the vendors and analyst were talking about.

The problem with EAI then is the same problem with SOA now. Only a handful of companies understood it and even fewer could implement it. It was hard and it took more effort. A lot folks went out and bought EAI packages and thought that was going to do it for them. Abstraction, reuse, agility, decoupling the enterprise comes from hard work, solid architecture and standards. There are not any shortcuts that software or packages provide. At the same time it doesn't have to be rip and replace. Start small and get good at it.