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).

Service Oriented Methodology

In 1998, a few of us at Momentum (James Higginbotham, Mark Spitzer, Ed French) wrote a software development method that we called Reality(tm). The method borrowed from best practices of Booch, Rumbaugh, Jacobson, Coad-Yourdan and Schaler-Mellor. Later we incorporated UML and concepts from Extreme Programming. We also threw in platform specific (Java & .Net) best practice guides and reference architectures. The Reality method has served us on over 100 engagements. I'll admit that we haven't always follow it to the letter of the law, but the intent seems to find its way into all of the projects.

However, at the heart of Reality is an "object oriented" development cycle. We were so heavily influenced by the "object people" that many of the mandatory artifacts and diagrams are OO in nature. Anyone that remotely knows me, knows that for the last half-decade I've been exclusively focused on service oriented computing. And for the last half-decade I've been waiting for a "service oriented" method.

Well - we decided to bite the bullet and start knocking one out. We are currently calling the skunk-works project "Awesome!(tm)" (Advanced Web Service Oriented Method) but my marketing team is telling me, "the name has got to go". I'm open.

The Awesome! method revisits a handful of concepts:
- Service centric diagrams & modeling notation
- Service centric artifacts
- Service network artifacts
- "contract first" development lifecycle
- Service level agreements as a first order concept
- Business process 'binds' to service networks

We also have started a repository of best practices - however these seem to have a half-life of about 10 months.

In 2005, we expect a half dozen SO-methods to come out - we know, this isn't exactly a new concept. As others come out, we plan on learning and upgrading our own. We figure it will take about 3 or 4 years before the SO-Methods come together with a set of base features and common notation. We also believe that people will want more than the "Microsoft Method" - and that choice is good.

Unlike our Reality method, Awesome! will be made publicly available. We aren't quite ready to share it with the public yet but are eliciting ideas on what people want in an SO-Method (email me). After the straw-man is together, we'll drop it out for public review and begin the upgrade cycle. Let me know if you have an interest in being an active contributor.

Methods are repeatable processes. They enable companies to reduce risk around projects and to leverage resources by assigning them to well-defined tasks. As service oriented styles move into the enterprise, the use of SO-Methods to complement your existing methods (RUP/UML, etc.) will be common. We need to move SO from an art to a science (or at least a craft) - and soon.

On Grand Venture Fund

Take a look at the application form for receiving venture funding from the On Demand Venture Fund:



Step 1 - get a Grand Central account and build an application :-)

How subtle is that?

The Importance of the Registry

Jeff Tonkel of Infravio recently pointed out the importance of the registry in a service oriented architecture. I'd like to second that thought. While I'm at it, I'll go so far as to state my opinion on who is leading in the space.

For starters, you have to look at BlueTitan. These guys get one real simple fact - you don't implement a registry for the sake of having a registry. Many vendors wrote a registry and encouraged their customers to dump crap in it. Bad idea. BlueTitan took the other approach - they started with the 'ilities' and worked backwards into the metadata that needed to be captured to manage a service network. Their registry is designed to capture only 'usable' metadata (actionable information); don't store anything that can't be used. Also they focused on the needs of enterprise grade service networks, the people with the really hard problems. I'm thrilled to see BlueTitan recognize that services are often just 'bumps on the network', that policies are 'service oriented aspects' and that the metadata and registry are the heart of making it functionally scalable. Most networks grow exponentially for some period of time; BlueTitan makes it possible to manage high growth networks on a linear cost scale.

After BlueTitan, you have to look at Systinet. Although these guys started with a strong UDDI slant, I believe they not only understand the limitations of UDDI, but are well on their way to overcoming the issues. I anticipate that Systinet will also have strong 'developer-side' integration into the registry (think reusable assets).

The registry is quickly turning into the 'metadata warehouse' - it is the point where a 'metadata driven architecture' and the 'service oriented architecture' merge. Architects are slowly figuring out that an important aspect of the SOA is the ability to factor the ilities out of applications. The registry is key to facilitating this movement.