The Death of Software?

Paul Brown had commented on a note from Eric Newcomer on the "death of software":

"The most significant inventions are over. Some would call this the "death of software." But only as we know it. Software will continue. But we are not likely to have any new languages, or see any significant new inventions. Twenty years ago no one knew what a database was, or middleware, or Java. But now I think innovation like that has stopped because IT doesn't need it any more."

Oh me, oh my. I've been there before - when you just run out of steam and everything looks grey; progress halts and the future dims. The good news is that history tells us that this is dead wrong.

Where to begin? Software remains in a pre-natal stage (not even infancy). I still think is hysterical that I type on a keyboard, look at a fixed monitor, and have to tell the computer what I want it to do. I'm amazed that I am so much smarter than my computer - this is just silly. I hate the fact that the state of artificial imagination is at ground zero, that we don't have digital metaphors and that a computer can't reverse engineer strategy. I think it is funny that we continue to use silicon at the computing substrate, that our programs are explicitly programmed and that they are not self-improving.

Maybe I'm just a kid at heart. Maybe I'm too stupid to know the obstacles. Either way, I am thankful. May I continue to be cursed with creationary optimism.

And may I offer an ounce of optimism to those of you who wore black pants and white shirts today. When your desk is scattered with employee status reports, when your walls speak of posters of UML and Java libraries from 5 years ago, it is time for a change. Not a little change, but a big change. Web services, orchestration, intermediaries, blah, blah, blah - these are the incremental improvements decades in the work. Refill your mind with childlike optimism. Imagine. Invent. Destroy. Laugh. Repeat.

Stuck in the Middle

This is from a slide deck that was put together in 1997:
The [I] box stands for 'intermediary'.


See: http://www.almaden.ibm.com/cs/wbi/Publications.html

Intermediary-based programming is still an art. Everyone wants to talk about services... service oriented this, service oriented that... but no one want to talk about "intermediary oriented". I guess it isn't very sexy. I've challenged the SO group to discuss the NFR's of an intermediary; should be interesting. I've also had some interesting discussions on the categories of intermediaries, including stateless, stateful, 'context oriented', header-only processing, payload processing and more.

I have a feeling that a significant focus of 2005 will be on the intermediary programming model. We'll see great discussions on IOD (design) and IOA (architecture) and refactoring portions of fat services into bumps on the network.

Charcoal Services

If a black boxed service sits in a grey container, what is it?

The Financial CIO

A great quote from a recent Sterling-Hoffman newsletter:

Angel Mehta: Why do you think the climate is so difficult for enterprise software companies, even with the economy having recovered?

Stu Schuster: For as long as I can remember, the process of growing a company has been the Geoffrey Moore, ‘Crossing the Chasm’ approach. When taking technology to market, find the innovators first who buy the technology, and then you go through the early adopters and late adopters, etc. This process, I think, all good high-tech marketers understood.

Throughout my entire career, there were always people who wanted to do something for their organizations that they believed would be a leap forward and would make a name for themselves. Call these the entrepreneurial Chief Information Officer… they were at companies like FedEx or Wal-Mart. They would try to do something with technology that would give the entire company a competitive edge.

After the technology crash, the focus became so oriented around cost-cutting that the entrepreneurial CIO was replaced with a financial CIO. There are so few entrepreneurial CIO’s out there that today everything has to be easy to implement, available by the drink, with very short time to ROI. The innovative buyer, the entrepreneurial CIO has been terminated out of the industry.

Eventually, it’ll cycle again because people will eventually feel that they’ll need a competitive advantage and will look to technology to do that. But today, it’s brutal. It’s amazing how hard it is to find people who are willing to take a chance on a new company or new technology. Fear dominates every IT department. As a result, growing an early stage software company is just harder than ever.

That’s why I place so much more emphasis on the people-side of the equation these days. It doesn’t matter how great the technology is – if the right people aren’t in place, you’ll never convince customers to take a chance.

The Role of the Application Servers in SOA

I've been using the term "service containers" to refer to the sandbox that services live in. However, in J2EE land, there isn't a 1:1 relationship between the 'software server' and the 'container'. You've got the 'servlet container', 'ejb container', etc. The Application Server is really an all-in-one - super-duper server. It slices, it dices, it does transactions, messages, web pages - you name it - it does it.

App servers can host web services. They can also host platform specific services (RMI, EJB). The services provided can be governed via the container and can leverage additional functionality via components and class libraries (most of the J2EE API's).

Just to restate - build services on top of components that are a combination of classes which sit inside of a governed container while making calls to libraries, some of which are runtime generators, perhaps being fed metadata from model-driven tooling. Agreed?

Ok. Now we need to move into "specialized servers", like identity servers, orchestration servers, etc. Many of these servers were built from the ground up as stand-alone servers, while other implementations were built to sit on top of application servers (e.g., a bpel implementation that runs in JBoss). In the J2EE world, specialized servers are really just new API's governed by the JSR process to encourage yet another container or library to be added to the J2EE server. In some ways, J2EE has become a dumping ground for 'bright ideas'. Hence the movement to 'lightweight containers'.

Now, let's ponder...
Question #1: Would you describe the application server as a "Rapid Service Development" (RSD) environment?

Question #2: To what extent should specialized services reside in generic containers?

Question #3: Should the server be 'pre-glued' together (mandate the download all 55MB of libraries) or should it be more loosely coupled and segmented?

Question #4: What are the necessary cross-cutting concerns that should be considered part of the server or container?

Question #5: What functionality is not a cross-cutting concern, but rather a specialized function?

Question #6: Would you consider the app server to be a "Contract First Container"?

The application server has evolved to meet the needs of the masses. It was designed to be an all-purpose server. Can a developer build SOA based applications in it? Sure. It is more work than it needs to be? Absolutely. And the big question... Do I believe that Rapid Service Development to Contract-First Containers is the way of the future? Yes I do.

Application servers will continue to be used when the architect chooses to use a platform specific component-based development model. Here, the focus is on 'building the application' (hence, "application server") versus building the services.

There are some real challenges that app servers will face in the SOA environment. We can be sure that BEA and IBM will be morphing their offerings to make them more acceptable to the SOA crowd. However, I fear that they will leave all of the garbage behind as well.

It's real simple - if your platform fails the loosely coupled test then so will your business applications that sit on top of them.

Remember: "Rapid Service Development to Contract-First Containers".

MS Patterns & Practices are Shallow

The Microsoft Patterns & Practices group released a set of SOA principles. I was eager to see what the brains came up with but found myself beyond disappointed; I found myself actually in awe of their incompetence. Perhaps these are tough words but I'm so extremely disappointed in the group-think that is currently going on in the SOA world that I feel compelled to point it out.

First, the show can be found here:
http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032262538&CountryCode=US

MS stated four primary tenets to SOA. My first thought was "holy smokes, they got it down to four?!!!" Well, here they are:
1. Boundaries are explicit
2. Services are autonomous
3. Services share schema and contract, not class
4. Service compatibility is based on policy

Boundaries are explicit - yep, hard to argue. But what does this actually say? How about this instead: "All exchanges of data, metadata, logic or other binary asset MUST BE exchanged through a contract. Runtime changes to code dependencies are NOT allowed."

Services are autonomous - Most people know that I firmly believe that "services are not autonomous", they are synergistic. Services work together in a 'service ecosystem'. Services will influence each others metadata. In no way are services autonomous.

Services share schema and contract, not class - I believe the point is that you want to share data using self describing, self validating, extensible schema systems that are ubiquitously deployed. That's cool - use an abstract typing system.

Service compatibility is based on policy - Yes. Agreed.

The patterns group then identified some "anti-patterns" or things not to do:
1. Avoid CRUDy interfaces. Don't use the CRUD pattern.
Guys - this is so wrong I felt sorry for them. After listening to them babble on this for a while all credibility was lost. I think what they meant to say is "Use CRUD, but don't violate the age-old wisdom around fully encapsulating and abstracting the persistence mechanisms. "

The second anti-pattern was avoid "loosely goosey" interfaces. The example they used was something like "runQuery(qry)". This one is tougher. If you really don't know what query combination needs to be run at design time then... you pretty much need something like "runQuery(qry)". This gets into a real interesting space that I wish MS would have talked about. Is it ok to pass XPath statement? Is it ok to pass an XQuery command? What is the right way to solve the runtime predicate problem? Surely the answer isn't "don't solve it". What about the surrogate key problem - where the only primary key is vendor specific key?

The list goes on and on... MS has the brains to do this stuff right. I wish they would ask some of their smart people to help the patterns & practice group get this stuff right.

Languages are Less Important

"Languages are Less Important" is one of the simple philosophies in Awesome(tm):

Traditionally, the choice of programming languages in an I.T. department was a near-religous decision. One reason was that the language tended to slither its way from one application to the next. Knowing this, managers would be very careful about allowing a new language into a development shop. In addition, reuse was considered a language specific mining activity (no one tried to pull Java code out of one application and put it in a Perl application). On top of this was the obvious fact that all of the enterprise API's were language specific, including J2EE and .Net.

Enterprises that implement Contract First Design and believe that Platforms are Contract Driven are much less dependent on specific languages or language specific libraries. Now, with this said - languages are still important for some real good reasons including: Developers skilled in one language shouldn't have to learn a new language for every different service they run into. Most I.T. shops already have large investments in platform specific code bases that they will want to leverage.

Although languages are less important in a service oriented world, they are still important. As services become more popular it will be common to find languages which are more friendly towards service development. This may be based on their ability to work with the Web Service standards, to expose themselves as a service or to invoke a service.

Well, it seems as though Peter Yared understood this some time back. Unlike the scores of startups that re-create the same damn product using all the same damn technologies... ActiveGrid made a hard left turn. The company appears to have come to the obvious realizations that no one else seems to have the guts to admit:
1. J2EE is a bloated set of deprecated patches.
2. Static Java objects and dynamic XML collide
3. Contract first programming make "languages less important"
4. If you're in an SO world, you might as well pick an SO friendly language
5. J2EE was designed to scale across a VM that sits on a multi-CPU box
6. Oh, Sun owns Java and J2EE, and what do you know... they sell multi-CPU boxes
7. Rip & replace Intel/AMD/Linux boxes are fast, cheap and reliable
8. LAMP is here to stay.
9. The growth rate of transactions inside an enterprise is significant.
10. The last-gen computing method will hit an 'economic breaking point'.

ActiveGrid is a "market starter"; the door has just been opened to commoditize the OS, the language and the vm while kicking big boxes in the groin and enabling service developers to be more productive while offering a lower cost of computing. Interesting? Uh, yes.

"Design by Contract" or "Contract First"?

I'm trying to clean up some terminology that I've been using in the Awesome(tm) method. The latest is the term "design by contract(tm)". This is a term that Bertrand Meyer coined (and trademarked). He used it in the context of object oriented programming where the focus was on "pre- and post-conditions and class invariants".

Don Box, Christian Weyer and others have favored the term "contract first" to describe a similar concept more suitable to web services. Here the focus has been on giving a service the ability to advertise:
- Type definitions
- Message definitions
- Operations (inbound and outbound)
- Message Exchange Patterns (e.g., request/response)
- Interfaces (groups of operations)
- Bindings

However, it is apparent that the contract goes beyond the basic wsdl stuff. It must also include:
- Pre-conditions / post-condition assertions
- Non-functional policies (security, reliability, transactional integrity)
- Hosted service level agreements (availability, latency)
- Synchronicity capabilities (asynch, synch or bi-synch)

Eventually the contracts will include stuff like:
- Semantic ontology (or other semantic broker)
- Costing /recharge functions
- Estimates to run service (think big-O)
- Preferred translator service (don't understand SOAP 1.5, but do understand SOAP 1.3)
- Code mobility agreements
- Service-to-service automated recompilation agreements (HotSpot for SO)
- Service dependencies (other services and resources)
(many of these will show up as standardized interfaces implemented by a service container)

I guess what I'm saying is that "design by contract" doesn't mean the same thing that we are talking about in the service oriented world. Hence, "Contract First" it is!


-----
Here's one to ponder... what pieces of the contract should be in a document format (like WSDL) versus in an interface format (like ws-mex). Or should they be in both? Why doesn't WSDL have a WSDL interface: getOperations()?? Is the ws-mex, getMetadata() the right way to go? Or should you look at it as an enterprise vocabulary problem? "GET" + "OPERATION" (think ws-transfer). Or is it a semantic ontology problem where you have "GET" and a pre-condition stating you can only get things that 'are a kind of' "METADATA"... Well, doesn't really matter - looks like we will have every combination possible. :-)

One of my favorites...

One of my favorite posts:
http://schneider.blogspot.com/2002_12_01_schneider_archive.html#90283350

(still waiting).