SOAP vs REST

Okay it's a bait and switch tactic. I'm not going to attempt to answer the SOAP vs REST question. It just degenerates into a religious war and ultimately serves no point. IBM's recent announcement about more REST in its Websphere product line prompted some conversation about it.

It probably doesn't really matter which way you go but I do think there are a few points that need clearing up and some further explanation. First there is this comment I got off of Joe McKendrick's post about it (Believe the comment is from Lorain Lawson) -

"However, IBM’s growing support of REST is “too promising to ignore.” That’s because the REST architectural approach opens up the door to potentially stronger SOA deployments – “with easier integration and more reuse of services (read: more agile) than you’ll get from an SOA built on an ESBs or the SOAP-based WS-*.”"

That really hasn't been my experience. I think when a comment like that is made more explanation as to why that might be true should be given. SOAP style Web Services are actually pretty easy to work with in most cases. REST has easier integration? More reuse? Why would that be? How many folks when using SOAP style Web Services have to worry about or get into the details of SOAP? How about REST style? Little more involved isn't it?

Easier integration? REST lends itself to more tightly coupled integration especially in the wrong hands. That's not the intent of the REST style architecture but I think it lends itself to that. I think developers will read about REST and end up just embedding URL's every where and call it REST. The end result is a mess. That's kind of what a lot of folks did when SOAP based Web Services came out. It turned out to be just a bunch of tightly coupled RPC calls.

The REST style of architecture is not bad but there is little tooling for it which means working with raw less than structured data. Most toolsets/platforms present SOAP style Web Services as just another class to the developer. REST proponents might say this is bad and they probably would not be to fond of ORM frameworks as well. That's not an incorrect view just different which is okay.

Another quote from Joe's post (Again from Lorian) -

"“it’s unlikely IBM’s shift to REST will settle the whole REST versus SOAP debate, since SOAP has a heavyweight of its own: Microsoft and its popular SharePoint.”"

Microsoft has REST embedded pretty well with their WCF framework which is part of .Net Framework 3.5. Not a big deal but Microsoft has obviously not ignored REST.

I'm personally not against the REST style of architecture. My issues have always been the way it's presented. Simple, easy to do, it's just the web right? No it's not and the web by the way is not an example of REST architecture contrary to popular belief. Go forth and get some REST or use some SOAP, it really doesn't matter just know what you are getting into.

Bashing EAI

A bit of EAI bashing going on these days. I suspect a lot of people, myself included, who have successfully implemented an EAI style of architecture are probably scratching their heads going hmm what did I do so wrong? Answer: nothing.

SOA is the latest new kid on the block (actually Cloud Computing is but we are not going there) so the natural tendency is to bash everything that came before it. The practice of EAI had and does contain a ton of good architectural principles. Those are being thrown out and replaced with the notion that EAI and it's evolution the ESB style of architecture are all about products and not architecture. It's simply not true.

Don't get me wrong, SOA is a very good thing. My issue is the stark contrast being drawn between it and EAI. Yes there are differences but they share more in common that is being explained by the bashers. Abstraction, loose coupling, common data types, composibility, discovery and yes even standards all existed in the EAI world.

EAI, ESB's, SOA and even Cloud Computing all have their place in the modern enterprise. Understand your architecture which means what works and what doesn't, evolve where needed but don't throw your successful practices out with the bath water because of the latest buzz.

S0A-Manifesto

A group of very smart and respected folks have put together a SOA-Manifesto.  You can find the Manifesto - http://www.soa-manifesto.com/ .  Overall it's pretty high-level stuff but good stuff.  I have one big issue however with one of the principles.  "Intrinsic interoperability over custom integration".  If just glanced at it sounds like something that makes sense but the devil is in the details.

 

Intrinsic means in this context that services using some sort of standards should do the talking between your existing applications versus doing "custom integration".  This concept is going to be confusing to an average IT shop.  The question will arise what's the difference between putting in a service and putting in a custom integration solution?  How do I get to the last mile of the interface with a third party application?  Or do you mean my services should contain all the business logic?  But isn't that custom because you had to write it?  Standards based stuff is fine but it's still custom if you have to write the service.  Sounds like a lot of academic semantics I know but I think its important to understand some important principles.

 

Unless your entire business portfolio is going to be made up of custom services that you write then you are going to have to do some integration.  It's just the nature of most businesses.  My problem with "Intrinsic interoperability" is that I believe it will lead to a spaghetti set of custom integrations.  The very thing it was trying to avoid.  Custom is custom.  In other words if you didn't buy it then it's custom.  Whether it's "standards based" or not has no bearing on whether it's custom or not or whether it becomes spaghetti or not.  I think well defined distributed services that have "Intrinsic interoperability" are going to be beyond the grasp of a lot of IT shops both to develop and certainly to maintain/govern.  If you are going that route be sure to go over to Todd Biske's site - http://www.biske.com/blog/  and study up on governance (Going to need governance regardless, but for distributed "Intrinsic interoperability" you really going to need it).

 

Ultimately I believe the "Intrinsic interoperability" piece was put in to kind steer folks away from ESB's and the older EAI model of integration.  While I understand this from a pure academic view, I think in the actual wild it has issues.  It has the same issues that ESB's and EAI had because of lack of understanding of the methodology that went along with successful implementations. 

 

Overall the SOA-Manifesto is a good set of guiding principles.  Having a set of principles like this that everyone in the organization understands and embraces can go a long way to developing and maintaining a successful SOA style of architecture.

Windows 7

I upgraded to Windows 7 on my laptop yesterday.  Overall the upgrade went smooth but it was time consuming (About 3 hours, of course I have a lot of stuff on my laptop).  I think the average home user will probably not upgrade to Windows 7 but rather acquire it through a new PC purchase.  That's probably a good thing for the end user.

 

Here are few things I noticed during the upgrade.  The first thing that jumped out is that the upgrade process is still not geared towards the average end user.  The upgrade process is going to do a compatibility check before allowing the upgrade to proceed.  If it finds things that are not compatible it's going to ask you to uninstall them.  While not an issue for an IT person like myself, I suspect an average home user is now confused.  Especially when it asks you to uninstall your wireless network card.  I did like the fact that it tells you iTunes is probably not going to work correctly anymore.  Nice marketing play there Microsoft.  Of course it works fine after the upgrade.

 

On the positive side, Windows 7 takes up less memory and runs a bit faster.  On the downside they got rid of their little built in mail client which is a bummer.  I liked that client, really don't like web mail interfaces, sorry Google but I like to work disconnected sometimes.  Plus I don't like a million things on my screen other than the email when I working on email.  I know there are a million email clients out there to be had but I liked that one, it was simple and efficient.

 

It did detect all my hardware and configure it correctly which is a step up from the past.  The interface is clean and seems to be pretty logical.  Overall I'd give Windows 7 a thumbs up.  I'll post back any observations as I get more accustomed to it in the coming weeks.

The Value of Enterprise Architecture

It's always kind of interesting when you have to explain and justify what seems like common sense. But like SOA, Enterprise Architecture seems to need constant justification and explanation. Why is that? Is it because we make what should be fairly straightforward concepts overly complicated? I tend to think so. Take a look at many of the EA frameworks available and your eyes will probably roll back in your head and you will lose consciousness.

I think keeping things simple tend to lead to more success. A major medical institution that will go unnamed spent millions of dollars on an automated medical scrubs dispensing system. It was going to save lots of money, folks wouldn't be allowed to take home and keep extra scrubs. After installing and testing the system, all things were go. Unfortunately there was one major flaw, a human being still had to load the machines each day with the clean scrubs.

As you might imagine, scrub machine loader is not the top end of the job spectrum. Scrubs are not one size fits all and each machine was responsible for dispensing the correct sizes. You can see this train wreck coming yes? After only a few months and tired of not ever being able to get the right size of scrubs, the employees figured out how to defeat the machines and keep out more scrubs than was suppose to be allocated. Millions spent and nothing gained.

When I was a young Army officer many years ago, I learned a very valuable lesson. Everyone needs to understand the mission. And by understanding it I mean be able to execute it. It seems like common sense doesn't it? If the leader becomes unable to perform his or her duties it falls to the next in line to carry out the mission.

In my simple world EA is also very simple. Define the destination, show everyone how to get there and then help them along the way to make sure they stay on course. Of course the downside to simplicity is that things don't tend to fail in such a grandiose way like when they are over engineered and over architected. Still it is important to realize that simplicity is not easy to achieve. Complex systems tend to form naturally.

Ultimately I think one of the keys to achieving simplicity is constant vigilance. How you get this working state of vigilance is the topic of another post. The hint is, there is not one answer for all.

Life as a Corporate Software Developer and Architect

I really haven't had time to blog lately just to busy to be completely honest. Being responsible for numerous development projects, by responsible I mean design, develop and deploy, has really placed an interesting challenge out there for my other assignment which is architecture. One of the benefits with working in a small software shop is the requirement for lots of hands on, one of the disadvantages is the requirement for lots of hands on.

Small software shops don't have the luxury of dedicated architects. Multiple roles have to be assumed in order to meet all the demands. Of course the big benefit I think is more usable and realistic architecture which tends to come from this type of environment. At any rate I hope to have some more technical post out here sometime in the near future as time permits.

Random Musings on Software Architecture

Many many years ago I was a young Army executive officer(XO) in a tank company doing some training at Ft. Bragg, North Carolina.  My CO and I were conducting some tactical training exercises for our tank crews.  We were using parachute signal flares to signal the tanks to do certain things during the exercise.  As luck would have it one of the flares came down on what appeared to be a small patch of grass several hundred yards away from our position.  We saw some smoke rising from the patch of grass but we chose to ignore it and continue with the exercises.  To make a long story short, the small patch of grass was actually much bigger than we thought.  We spent the next several hours in 95 degree heat putting out the rather large fire (We had no water, only shovels).

 

Software architecture in the corporate IT landscape is very much like the small grass fire that turns into a very real wildfire.  We tend to either ignore it completely or over indulge it.  Neither of which is very good for the primary business and usually gets out of control pretty fast.  There is a delicate balancing act that has to occur on a daily basis in a corporate IT shop.  The needs of business have to be met.  There really isn't any arguing with that.  It's how you meet those needs that is the question.

 

There really isn't a one size fits all answer to that question.  Despite opinions coming from analyst, bloggers(including myself) and others, there isn't one correct way.  What works for each individual organization is going to vary.  Finding the middle path which balances good enough architecture with the dynamic needs of the business is really the key. These are the two two questions you should be asking in my opinion; Am I delivering the value to the business that the business wants?  Is my architecture or lack there of negatively impacting the business?  If you are delivering the value, by the businesses measurement not yours, and your architecture is not causing issues for the business then you probably have found the middle path.

 

The last piece of advice is do not ignore the small smoking grass fires.

 

 

 

 

Bernard Madoff

Ah my claim to fame. I'm originally from Butner, a small town in central North Carolina. Welcome Bernie!

Oracle 11g

Oracle just recently announced it's 11g monster. Here is Joe McKendrick's take on it. My take is that it's great for consultants, there will be lots of money to be made trying to implement this beast. It's bad news for companies trying to implement it.

The corporate IT mantra is keep it simple, keep it quick and deliver a lot of value to the business. There is nothing simple about 11g and with the Sun acquisition things will only get more complex.

SOI and A Very Dead Horse

ZapThink put this out on SOI(Service Oriented Integration). We kind of have been beating this horse to death for a while but after reading the article I see we are still not completely there yet. This question in particular got me -

is SOA's purpose to solve integration problems, or is it more of a business transformation approach centered on implementing agile business processes?

I go back to this post - http://www.thegreylines.net/2009/01/soa-versus-soi-continued.html . Agile business processes? How exactly would you do that without bringing systems together (integration)? You would pretty much just have to have the one system. Anybody work in enterprises like that? We are not talking about moving data from point a to point b, again see previous post.

Designing Services in the SOA World

The Grumpy Architect has appeared and apparently it's Brenda Michelson. What's making Brenda so grumpy? The state of software design especially as it relates to services. I'm not going to rehash the great points Brenda makes, please go read her post it's loaded with goodness.

I don't think there is any one reason why the state of service design is where it's at. Here are a few of the causes in my opinion:

*It's not taught or emphasized in CS programs. That's a generalization of course because some programs do but if you do a quick survey of undergraduate CS programs you will find very little emphasis on it. It does show up more in the grad level programs.

*We are to tool centric. We judge someone's competence in software design by how well they know the platform or tool. Give me someone who understands abstraction and loose coupling over someone who knows ever class in the .Net framework any day but produces 8000 line methods.

*The business, the business, the business. Don't underestimate the extreme demands placed on corporate software developers to churn stuff out. Developers and their managers take what they perceive to be the easy way out in order to meet the demands. That environment is very difficult to work in sometimes and the software design is usually what suffers.

*Time and motivation. Well if you didn't get it in school, you now have to learn it on the job. Some folks are self starters and some are not. Mentors and architects can help but they can only do so much.

*Short-sighted. Designing brittle, difficult to maintain and ultimately unsustainable software is actually really easy. We do tend to take the easy path.

I think one of the issues with the current state of SOA is that a lot of folks made the assumption that developers understood all of this and the software side of SOA was going to be the easy part. If you worked in a corporate IT environment you know nothing could be further from the truth. I have noticed especially in the past year that the amount of available information on the technical side of SOA is finally starting to catch up with the hype.

Larry at JavaOne

And so the long arduous process of Oracle messing up another acquisition begins - http://www.theserverside.com/news/thread.tss?thread_id=54827

 

Seriously, he's really focused on JavaFX?

 

 

 

MVC

In addition to my webMethods stuff, I've being doing a fair amount of .Net stuff lately. I decided to run through the new MVC framework tutorial from Microsoft just to see their new take on this old pattern. The tutorial is located here.

I must give props to folks over at the ASP.NET web site. They have done a very nice job with the content on MVC. This particular tutorial was very straightforward and explained MVC very well. If you are inclined to check it out pay particular attention to section 4 on abstraction and loose coupling. That is really good stuff. This section is written in terms of OO concepts but they apply as well to the services world. Thomas Erl explains some of the differences between OO and services here and here if you want more detail.

MVC has long been a highly regarded pattern in the user interface world. The interesting thing is this same pattern with some modification can be used in the SOA world even when GUIs are not involved. The Service Facade pattern as explained here by Thomas Erl is closely related in concept to MVC. There are differences but I think you will see the overlap and the potential of MVC in the services world.

I think one of the biggest mistakes some developers and architects make when jumping into the SOA world is to wrap existing stuff in a standards based interface and then go at it directly. While there is really nothing wrong with wrapping existing stuff in a standard based interface, invoking it directly is another issue. Spending some time with the Facade pattern and MVC can pay off in a more agile and resilient set of services. I have personally found that the associated overhead of these extra layers of abstraction are minimal and well worth the small cost.

Rob Eamon has also gone through some MVC content and has posted his thoughts on the Nerd Dinner walk through on his blog. Check that out when you get the chance.

Oracle to buy Sun

Not nearly as a good idea as the IBM purchase.  Here is the link - http://www.wral.com/business/story/4985700/

 

 

Cloud Computing and Trust

For me one of the biggest hurdles for cloud computing is trust. I read this post recently from Jonathan Schwartz's blog over at Sun on cloud computing. One thing that jumped out at me was the little graphic Jonathan posted from OpenOffice. The graphic showed file manager from an OpenOffice beta and its ability to "save to the cloud". Looked pretty cool right? But then I thought, what would I save there?

Jonathan's graphic of OpenOffice is nothing new. Google has been doing this a while with Google Docs and so have many others albeit not on the scale of Google. I have used Google Docs to store documents and spreadsheets but I have never put anything out there that I would consider sensitive. It's a trust issue and a privacy issue. In fact a lot of companies even block that kind of thing through firewalls and proxies for just that reason.

Cloud computing is obviously a lot more than just a big document repository I used for an example. However, the trust issue which is mainly a perception issue in my mind will have to be overcome to allow cloud computing to reach the potential others are touting. I also believe smaller sized business will be more likely to take the perceived risk than the bigger ones. What do you think? Are you ready to start using the public clouds for business critical sensitive information?

Sun and IBM Continue to Court

Sun and IBM are continuing to dance according to the latest news.

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.

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.