Fun Facts

Today was a slow day in India.

Only 163 new jobs requiring Java development experience were created on MonsterIndia.com - today (of the well over 5000 current openings).

Most of the positions were paying around $12,000 USD annually.

Today was a slow day in India. Perhaps things will pick up tomorrow.

How many languages do you use?

I love asking Java developers the following question, "How many languages do you use when developing a J2EE application?" They almost always look at me with this pitiful look. It's the, "Jeff is so old that he doesn't even know that J2EE uses Java" look. I'll usually string them along while they try to describe what J2EE is. The answers are great.

After they finish 'educating' me on Java, I follow up with the following set of questions:
1. Is HTML a language and do you ever use it on your J2EE applications?
2. Do you use a 'batch' or 'make' language on your apps?
3. Do you ever use the 'structured query language' (SQL)?
4. Do you ever use JavaScript?
5. Do you ever use JSP?

Usually I stop there - by this time they understand my point.

J2EE is a combination of languages and libraries. We use Domain Specific Languages (DSL) all the time. In the Java world we tend to wrap them with 3-letter acronyms that start with the letter 'J'. We often glue the our languages and libraries together in the form of an application by using an object oriented 3GL (Java).

In many cases, our libraries (JMS, JDBC, JNDI, etc.) merely act as a standardized API to a server (or set of services). These services often need to be customized. We have several ways to customize services: upload metadata, pass in parameters, etc.

J2EE is our container of DSL's and libraries. It acts as the vehicle to pass information from one DSL to another DSL, from one library to another library, from a DSL to a library or from a library to a DSL. The Java language is used to type the data, transform it, perform Boolean logic and pass the data on.

The questions that I've been asking myself are:
What should a library/DSL integration language look like?
Is Java (or any OO-3GL) the best fit for a library/DSL integration language?
What common functionality of the DSL should refactored into a generic 'DSL engine'?
How does a platform architecture provide more consistent extensibility mechanisms across the suite?
To what extent should the components of the platform be mandated to have a symbiotic relationship with the other members?

Back to the original question, "How many languages do you use?" The answer is usually 5-10, and the number is growing. Writing J2EE applications is becoming less about programming in Java and more about mastering domain specific languages, libraries and integrating them across contextually bound Use-Cases.

J2EE has grown organically over the last 7 years. It has not had the opportunity to be massively overhauled. In my humble opinion, the enterprise software community is ready for a massive refactoring of J2EE; one that isn't dragged down by backward compatibility issues. I believe that we are ready to incorporate our lessons learned to design the next-gen software development platform.

Beyond Services

I've been actively writing about services (and mostly web services) for three years now. We've moved from the base specs, to the WS-* functionality, to BPEL, Service Network design, Service Oriented Integration and Service Oriented Development of Applications.
However, the one thing that has been clear to me for the last year is that services will play an important role in enterprise architecture, but will only be successful when combined with other architectural concepts.

In the past, I've thrown out terms like, "Model Driven Services" or "Model Driven Metadata" and "Metadata Driven Services". The fact is, most "web service" companies have been so busy trying to knock out the ws-* spec implementations that they have not had time to think about the converging programming model. But they must!

After the WS-dust settles, we will have solved our LCD problem and hopefully even our GCF problem. What is less clear is how service based development will interact with many of the popular programming concepts (eventing, aspects, code generators, process engines, policy systems, rules engines, etc.) It is relatively easy to create a new specialized brand of computing (like services). It is much harder to weave it with the concepts that are already in place. Failure to do so results in a massively disjointed architecture. The symbiotic relationship between our architectural components must grow.

Dynamic Coupling

Loose coupling has more up front costs than tight coupling. The assumption is, over the life of a component (or service) that the loose-coupling device will pay for itself.

A common belief is that software engineers should design services to be 'loosely coupled'. That is, they should verify that the service can speak the 'least common denominator' and do it in a manner that mitigates the impact of location: attempt to minimize the impacts associated with distributed computing (location transparency).

In the physical world, we use devices to decouple entities. Instead of soldering two components together, we connect each component to a plug and then use the plugs to connect the items together. This is necessary in the physical world.

In the logical world, we have the opportunity to attach a 'plug' to the end of a component or a service. And just like in the physical world, it costs more money to buy and attach the plug. But, the plug should make the component more reusable. That is the investment.

Imagine an electrical component that is attached to a printed circuit board. The component has nice plastic plug coming off of it enabling other components to easily connect to it. In addition, the wire lead on the component is exposed and it is mounted in such a way that additional wires can be soldered directly to it. In essence, the component was designed with loose coupling in mind (the plug) but the instantiation (or the use) of the component allowed the engineer to bypass the plug by directly connecting to the wire lead.

Here, the component has both 'component design-time' and 'assembly design-time' properties. The 'component design-time' properties describe the features that the component has; in our case, we are interested in the plug at the end. The 'assembly design-time' deals with the decisions that the engineer makes at design time when they assemble multiple components together (e.g., does the engineer use the plug or solder directly to the wire?)

When we discuss loose coupling or tight coupling, we must remember that there are different issues to consider:
1. The level of investment that was placed on enabling a component to be loosely coupled (e.g., it comes with a plug attached). [POTENTIAL COUPLING]
2. The decisions that the component assembler made when combining the piece components (e.g., they used the plugs everywhere vs. soldered them together everywhere vs. some combination) [ASSEMBLY COUPLING]
3. The option of delaying the assembly interface mechanism decisions to runtime. [DYNAMIC COUPLING]

A significant amount of literature is available on making components/services reusable (creating high potential decoupled devices); thus I won't revisit. Less is written on Assembly Coupling, but I'm still happy with my, "Service Coupling Index" as a foundation. However, very little information is available on the concept of Dynamic Coupling.

In many ways, Dynamic Coupling contradicts the 'loosely coupled' manifest. Rather than stating that something must be implemented in a certain way (asynchronous, document centric, XML based, etc.), it states that the component need only have Decoupling Potential AND that the component be aware of any Dynamic Decoupling Device.

I like to think of the Dynamic Decoupling Device as a "magic printed circuit board". Here, the assembler inserts components into the board. But rather than soldering the components together or using plugs to connect them, the assembler will never execute the actual assembly mechanism. Instead, the assembler tells the printed circuit board which components need to be connected to each other. The "magic printed circuit board" is now responsible for querying the components and determining the best mechanism to connect the piece parts together. We have moved from explicitly stating the connection mechanism to only stating the intent.

In the physical world, creating the "magical printed circuit board" is... well, challenging. In the logical world it is quite easy. At the core, it means:
- We use policies to describe capabilities and interfaces.
- We publish the policies in a consistent manner.
- We perform protocol negotiation at runtime.
- We build components with high decoupling potential.
- We build components that were designed to connect to Dynamic Decoupling Devices.
- We quit hardcoding our assembly mechanisms.
- We mandate the use of Dynamic Decoupling in assembly.

If an architecture is indeed defined by the constraints rather than the features, than the aforementioned may serve as an architectural style that facilitates reuse without giving up performance.

The Suckline

The other day I bumped into an old friend (Tim) that specializes in Java and database development. He asked what me about my interests and I told him that I have been working with web services. He said, "Oh, aren't those slow?"

Sure, I had 101 smart-ass answers loaded in my arsenal, but this individual was asking a serious question that deserved a real answer.

I answer him, "Well, I guess it depends. Generally speaking, anytime you use distributed computing techniques you will incur extra overhead - and that overhead could lead to poorer performance or response times." This answer clearly annoyed him. He responded, "Yea, I know that you use 'distibuted computing' to distribute computing and the effects that this has... my concern is that web services leverage a bunch of abstract protocols that just weren't designed with performance in mind."

"Ah... I get your point. The protocols suck?"
"Yes - the protocols suck - if you have any concern for performance."

Ok - now we were getting somewhere.
"Tim, the reason they suck is because the big-boys (IBM/MS) chose to roll out 'Least Common Denominator' (LCD) solutions to distributed computing first. When you need to create an ad-hoc computing platform and you don't know the capabilities of all of the participants you must choose only those capabilities that are guaranteed to be available across all nodes. You have to create an LCD baseline (which I call the suckline). The suckline is the decision to use the lowest common denominator capabilities across participating nodes in order to guaranteed communications."

Tim nodded in agreement and commented, "But what you implying is that there is something else out there that doesn't suck - - like a Greatest Common Factor (GCF) solution?"

"EXACTLY - - but there isn't! And that my friend, is the beauty of it...(laugh)..." He looked at me like I was insane - which is a look that I thrive on. "Web services are about protocol negotiation. Currently, we only have one solution for just about any facet of web service computing - encoding, encryption, reliability, transactions, discovery - you name it - we have a version of it that more or less sucks! And you know what - that's ok! IBM and Microsoft have had the patience to work on an LCD platform for as long as they have - and in the face of 'performance critics' - I tip my hat to them. If the protocol negotiation is done correctly you should be able to use a metadata described invocation and interface description mechanism that is linked to a protocol policy for runtime resolution."

Tim asked, "So you believe that it really is just an issue of 'premature optimization'"?

"Absolutely - two communicating java applications will be more efficient at sending serialized java objects then they will be at sending and receiving XML documents. If the applications are on the executing on the same vm, it would be more efficient if they used some kind of shared memory. The GCF capabilities of the participants MUST be determined dynamically (or cached). Should the two applications be prepared to go down to the suckline? Sure - the suckline represents the ubiquity baseline of modern computing."

"Jeff, you just crossed from distributed document oriented to distributed object-oriented computing. I thought that web services was all about document oriented, XML based, loosely coupled, asynchronous..."

"No! - and yes..." - I injected. "This is where I disagree with most of the world. If you ask most people that live and breathe web services... they would agree with your comments. However, I'm not one of them. To me, web services describe a programming model that is evolve-able. The SINGLE most important feature for me is the ability to use protocol negotiation to determine the instance of the programming features and functions that you deem necessary to create a dynamic virtual computing platform. The document oriented problem is really a fatty-chatty problem - and there are solutions to this as well."

Tim commented, "That's cool. But we still have the problem that today web services are slow and we are stuck with the suckline."

"Yep - you are correct. Microsoft has already moved Indigo towards a GCF programming model. IBM is doing the same. What is unclear is if a generic J2EE type solution will become available (in time) to compete against the MS solution. Otherwise, you will see a splintering in the next-gen Java SOA marketplace with only 1 or 2 vendors agreeing to agree on the GCF solution. And yes, it is very possible that the GCF solutions will have patents hung all over them."

"Tim, I can't predict the future, however - I bet on smart people and funded projects. Right now MS, IBM and others are putting their best people on web services and throwing lots of cash at it. Trust me - we will move way beyond the suckline - there is too much money on the table."

The Dallas Duo

I just realized that the Dallas Duo are blogging:

Glenn Vanderberg and Greg Vaughn

It seems as though Greg is hanging out in the ladies restroom, while Glenn is off discussing complicated topics :-)

No blogging from Billy, Patrick or Tom? Bummer.

The J2EE Verbs

Here are the verbs of the J2EE API:

acknowledge, activate, add, after, are, cancel, clear, clone, close, commit, compare, connect, contains, convert, create, delete, destroy, do, does, encode, execute, exists, find, flush, forward, get, handle, include, init, initialize, insert, invalidate, is, load, log, next, on, passivate, pop, prepare, previous, print, publish, push, put, read, read, receive, recover, refresh, register, release, remove, request, reset, rollback, run, send, service, set, start, store, truncate, unset, unsubscribe, update, validate, was, write

Here are my 'kernel verbs':
Level 1: do
Level 2: get, set, insert, delete, allocate, deallocate, validate, resource.peform, run, locate and receive
[warning - this is first pass]

I'm still working on level 3. It will probably look like a cleaned up version of the J2EE verbs. I'll remove the synonyms and change some of the state oriented verbs into nouns. All level 3 verbs are just combinations of level 2 verbs. Creating level 3 will likely shake out my level 2.

I'll take a look at the .Net verbs as well. I already did the assembly language verbs - I thought it would be interesting but I failed to gain much insight; odd eh?

Process Visibility as a Service

Should 'Process Visibility' be a service?

It has been my experience that most people who look at BPEL solutions want a combination of the following:
1. A way to combine multiple web services into a single service (composition).
2. A method to explicitly define the flow of control between activities (or steps) in a business process.
3. The ability for management to know what step or state a process is in.

Number 3 is the Use Case for 'Process Visibility'. So, how do you do this as a service? Well, you still have to identify all of the activities to the degree in which you are interested in visibility. You also have to identify combinations of 'interesting state'. For example, if an order for a part comes in and no inventory is available for that part, well - that is interesting. This becomes a declarative rule applied towards a handful of variable to define a single state of interest. Also, anyone that is participating in providing visibility must be able to identify which instance of a process they are talking about, thus the equivalent of a correlation token must be used.

I'm thinking something like this:
Key=(ProcessID, InstanceID, CorrelationTokens)
updateProcessData( Key, SomeData)

It would be easy enough to turn this into an aspect (AOP) in a BPEL engine - but I'm not so sure that you want to bottleneck these calls. I do think it should be an aspect but invoked at the event source.

Now that you have a service that is collecting data across a distributed environment, it must tell others about the 'interesting states' that it has encountered. That sounds like a pub/sub problem to me.

I don't know... maybe something like this:
subscribeProcess(ProcessId, StateID, StateOfInterest)
(This implies that it is interested in all process instances that achieve a certain state.) Obviously, the BAM system would end up being a subscriber to this.

Hmmm... interesting. Now we have a state machine firing when certain states of interest are achieved.

Next up: 'Flow Control as Metadata', followed by 'Service Oriented Metadata'

The Systinet Gateway

Just some quick highlights on the Systinet Gateway product:

Systinet Gateway is able to extend and bridge the following products: IBM WebSphereMQ (formerly MQSeries), TIBCO Rendezvous, and any JMS-based middleware solution. Gateway can extend these MOMs and bridge between combinations of these products.

Systinet Gateway provides full support for the latest standards, including SOAP 1.1, SOAP 1.2,WSDL 1.1, WS-I Basic Profile, WS-Security, WS-ReliableMessaging, WS-Addressing and WS-Eventing.

-------------
In essence, the Systinet Gateway modernizes some of the last-gen Queue/Bus products by bridging the gap between proprietary and open WS-* standards. This is nice if you already have an existing product (Tibco/IBM-MQ/JMS-*) in house and want to move down the ServiceNet path.

Systinet chose not roll yet another Queue/Bus but instead has placed a wrapper around the best-of-breed that exist today. One thing I'm not sure about is the support for WS-Policy (is that implied?) Also, I'm not sure but it sounds like they do some sort of translation between a WS Endpoint and a Topic (I'm guessing).

Is the Gateway a big deal? Yep. The Queue/Bus is commoditized, but the WS-Bus is still emerging. The Gateway must still prove to be performant (minimal overhead) and consistent with the architecture of the products that it front-ends (e.g., how well does it work with clustered versions, does it gracefully start-up/shut-down with the Bus, does it have similar versioning mechanisms, etc.)

What does this mean for Systinet? First, it is one of their higher end products ($$$) and will require a more sophisticated sale then what they are used to with Wasp. Second, they will have to convince Tibco/IBM/Sonic/Spirit that they aren't competition, but complementary. Lastly, they will have to fight off the other 'legacy-enablers' like Iona and the adapter players. This product (along with UDDI and their service enablement line) now give companies the tools to turn 'last-gen' into 'next-gen'.

So what can we expect next from Systinet?

Iona to Reduce Number of Press Releases!

A representative from Iona has stated that they intend to reduce their number of press releases... or something like that. Actually, I believe what he said was:

"Gateways are simplistic -- anyone can write one" - (meaning that even Iona can write one)

and...

"I'd personally be embarrassed to issue a press release touting a mere gateway."

Interesting.

Let's take a look at the Iona press releases which are so damn important:
May17 IONA Makes Standards Compliance Easier for Telecommunications Equipment Manufacturers
May12 Chinese Premier Visits IONA Technologies
May10 IONA Joins Telemanagement Forum
May04 IONA Puts Developers on the SOA Fast Track

Hmmm... they joined an industry group, had a diplomat visit and wrote a white paper. Iona - you kick ass!! Don't bother with those silly press releases about new products - those... well, those are just embarrassing.

BEA opens up some slots, too

From Monster.com:
======================================
Major Duties and Responsibilities:
You will join the development team for state-of-the-art BPM application development framework aimed at enabling corporate-level developers to build and deploy scalable, highly-available, web-based enterprise applications involving web services and other B2X e-business applications.
Specifically we are seeking a person in our runtime team to help build the Business Process Engineer.

Qualifications/Necessary Skills:

A related degree and 5-7+ years relevant experience in java programming at the systems level. Must have in-depth expertise with J2EE technologies, enterprise level server development.
A solid understanding with BPEL required.
===========================================

What no BPELJ required???

Job Openings - Momentum

Momentum Software has recently opened several new positions:

(2) Java / J2EE Architects
(4) Senior Java Developers
(1) Junior Java Developer
(1) Web Services / SOA Consultant
(3) Senior .Net Developers (C#)
(1) Junior .Net Developer

All of the aforementioned positions are based out of Texas and require some travel. Both full time and contract positions are available.

Interested parties should contact the recruiting department: careers@momentumsoftware.com

Legos and Jigsaw Puzzles

Toys.

An infant can pick up building blocks and with no training build something - just put one block on top of the other.

A toddler can use legos. Line up the "in's" and the "out's" and push the pieces together.

Jigsaw puzzles are trickier. Puzzles are packaged by the number of pieces they contain. Why? Because in a puzzle each piece has only 1 potential place in the puzzle (1 'in' matches 1 'out') and as the number of pieces increases so does the complexity.

Imagine a set of legos where the notches (or interfaces) were different on every block. Each lego only worked with one other lego in the set.

In software we see a similar problem. As the number of pieces (and interfaces) increase, so does the complexity of assembling the components. Some items plug in nicely while others require significant transformations. Scanning for the right component takes time -like scanning for a single puzzle piece in a 1000 piece puzzle.

Personally, I love the interface for the database. I believe whole-heartedly that the interface is what made it so damn popular. do(DDL) and do(DML) are absolutely beautiful. Something to create, destroy, administer and manipulate - and all done on a solid mathematical foundation.

Call me silly for not liking an operation called, "getLastStockPrice". Call me dumb for not being able to figure out the REST equivalent of the operation. For some reason the magic of the WWW feels like it comes more from HTML than HTTP. Is the real magic in the browser: do(HTML)? Is chasing the HTTP verbs a red herring? or just an obvious fact that when realizing a domain specific language you shouldn't screw it up with a complex API.

The web... simple addressing, simple verbs acting as manilla envelope; and a domain specific language that can describe everything from pornography to the weather, all working together to create the worlds largest distributed computing platform. Simple addressing, simple envelopes and DSL's.

WS-REST

Mark Nottingham entered the Matrix in search of the spoon.

First, I tip my hat to Mark for tackling a complex issue.

Mark points a handful of things out:
1. A single http request is indeed synchronous
2. The http request doesn't have to block for the end result, instead it can block for an ACK or a fault code
3. Two http requests can be combined to create an asynchronous message exchange pattern
4. Pub/sub can be simulate via polling.
So far, so good.

He continues, to say:
5. One can hold open a TCP connection and use event looping to minimize the resource consumption issue.
Ok, this is an interesting one. In my opinion, there are some problems here:
1. It assumes that not only the end server utilizes a specific mechanism (event looping), but also every intermediary between the client and the server.
2. Connection oriented protocols don't work well when the server crashes (all connections must be reestablished; kiss your performance gain bye-bye).
3. Clustering connection oriented protocols (IMHO) is more cumbersome than connection-less protocols.

Then he introduces the peer-to-peer model, where the client has a well-known address and continues on to acknowledge the firewall/NAT issue. Very good.

Ultimately Mark points out that many people hear 'http' and think synchronous - which is right and wrong. Yes under the covers the application blocks, but not necessarily for the 'answer'. He also states that people should consider the level of abstractions that they need (describe the message exchange versus describe the implementation). I agree. He ends his post with noting that modern distributed computing practices require the ability to describe the interface and the message exchange pattern, then he goes on to mock one up.

In my opinion, Mark has blasted past the issue of 'WS-I' style versus 'RESTifarian' style and is well on his way to finding the best-of-breed. This will be one to watch.

Emerging Technologists

Every solution creates a new problem. As soon as a solution is introduced emerging technologists begin thinking about the new problems and the means to solve it. They jump right over the 'current' problem and begin attacking the issues that haven't occurred to the majority.

Over the years, I've created a few broad categories that I use to describe the 'emerging' people:

Spotters - a spotter is someone that scans the available technical literature looking for the next big thing (a spot).

Weavers - a weaver is a person that combine multiple 'spots' into a candidate solution (a weave).

Appliers - an applier is a person that takes a well known problem and applies a new candidate solution towards the problem (an application).

Inventors - an inventor is a person that illuminates a new alternative solution to a well known problem (an invention).

Evangelist - an evangelist is a person that makes persuasive arguments in support of a new spot, weave, application or invention.

Referee - a referee is a person that attempts to mediate the 'emerging' people and their solutions.


What are you?

RESTifarian Evaluation

Per my earlier note, I have evaluated my feelings on the units of REST:

1. An architecture is defined by its constraints - Strongly Support

2. Separate client from server - Strongly Support

3. The client / server relationship must remain stateless - Support

4. The client must be able to cache data - Support

5. Uniform Interface - Support

5.1 Identification of Resources - Strongly Support

5.2 Manipulation of Resources through Representations - Strongly Support

5.3 Self Descriptive Messages - Strongly Support

5.4 Hypermedia as the engine of application state - Support

6. Layered System - Support

7. Code on Demand - Don't Support

REST is a single candidate architecture. And an architecture must be evaluated on the whole, rather than the individual parts. Fielding does a great job of stating that every decision in the candidate architecture has trade-offs. He further identifies the applicability of the architecture (distributed systems, system 'feels' stateless, desire to scale, desire to evolve, etc.) Like all candidate architectures, one can only evaluate the architecture against a problem that you are trying to solve. REST by itself can not be evaluated, only evaluated as a candidate solution to a pre-identified problem.

What was interesting to me was the lack of association between REST and HTTP, or more precisely the 'verbs' of HTTP. Instead, Fielding places significant attention on the need to use Resources (think URI), Self Descriptive Messages (think XML), but does imply that a generic interface is required. Somehow... I find myself agreeing with Fielding but disagreeing with many RESTifarians (I'm not sure how this is possible). Fielding suggests a "a uniform interface between components ", however he never mandates what that interface should be - only stating the characteristics. However, I find significant 'folklore' stating that the interface is, "...defined completely and solely by the specified semantics of HTTP, i.e. GET / PUT / POST, etc." (Jeff Bone) He continues to argue, "*there are no applications you can think of which cannot be made to fit into the GET / PUT / POST / resources / representations model of the world!*" The only issue I have is his term "made to fit" - meaning, what was the price of 'making something fit'?

So, with all of this said, where am I landing?
1. REST is a great example of a candidate architecture and should be evaluated based on the problem at hand.
2. REST doesn't dictate HTTP or the HTTP verbs and this is a good thing.
3. REST does state that the interface should be uniform, and this too is a good thing.
4. The base HTTP application semantics can be 'forced' to solve any problem, they just aren't always a good fit.
5. Additional exercises should be performed to document how many RPC style verbs would be translated into a more REST-stlye. Verbs that don't translate shouldn't be forced to fit, rather new verbs should be introduces as part of the first-order vocabulary.

Tim Bray on things

Tim is now at Sun :-) and has new things to say.

1. He doesn't like composable message architectures. He doesn't like describing the resolution to non-functional requirements of distributed computing via specifications because it is hard. In my opinion, you either specify your separation of concerns with specifications or make them proprietary. I lean towards specifications. Also, the solution will utilize a building block approach or a big-bang approach. Your call. I prefer building block.

2. He doesn't like automated service discovery (UDDI). I think he misunderstood what UDDI was all about. That's ok, many people do - it is a design time service, not a run time. Throw away the "automated" part and you're a lot closer.

3. He doesn't like declarative application building. He mentions BPEL and ws-chor as examples of this - unfortunately neither of them are valid examples. Actually, I kind of wish they were! Declarative approaches for state based decision making and distributed invocation has a real place in software development.

4. He doesn't like leaky abstractions. Me either, but unfortunately he doesn't give an example.

5. He's concerned about the standards process. Perhaps the new Sun employee should take a look at the JSR process :-)

6. He's concerned that we aren't making it simple enough. Here he has a decent point - it is complicated. Could it be simplified? Sure, throw away functionality and we can simplify it. Keep in things like reliable messaging, self-contained enveloping, trust, authentication, multiple levels of transactions, etc... yea, you can make it as simple as you'd like!

Welcome to web services :-)

RESTifarian?

Mark Baker declared that I was on the way to enlightenment (AKA, seeing things his way).

You know, I'm not sure if I am a RESTifarian.

When I first saw this:
http://www.extremeprogramming.org/rules.html I used it as a tool to determine what components of XP I believed in. It is tough to say, "Yea, I am an XP guy or Yea, I'm a RESTifarian". I've looked at some of the REST wiki's out there and I haven't found the simple list of rules and guidelines.
What I'd like to be able to do is say, "I support RESTifarian rules/practices 3, 5, 9, 11 and 14."

Perhaps if one of the REST supporters would give me the discrete rules for REST, I could more clearly state my opinion.

-------
Side note:
The XP guys did a great job. For the record, I'm not an XP'er. I've worked too many huge projects. Here is my stance:

Planning
User stories are written. - Support
Release planning creates the schedule.- Unsure
Make frequent small releases. - Strongly Support
The Project Velocity is measured. - Unsure
The project is divided into iterations. - Strongly Support
Iteration planning starts each iteration. - Strongly Support
Move people around. - Support
A stand-up meeting starts each day. - Partially Support
Fix XP when it breaks. - Strongly Support

Design
Simplicity. - Don't Support
Choose a system metaphor. - Don't Support
Use CRC cards for design sessions. - Support for OO systems
Create spike solutions to reduce risk. - Strongly Support
No functionality is added early. - Don't Support
Refactor whenever and wherever possible. - Partially Support

Code
The customer is always available. - Unrealistic - Don't Support
Code must be written to agreed standards. - Support
Code the unit test first. - Partially Support
All production code is pair programmed. - Don't Support
Only one pair integrates code at a time. - Don't Support
Integrate often. - Fully Support
Use collective code ownership. - Partially Support
Leave optimization till last. - Don't Support
No overtime. - Don't Support

Testing
All code must have unit tests. - Partially Support
All code must pass all unit tests before it can be released. - Support
When a bug is found tests are created. - Support
Acceptance tests are run often and the score is published. - Fully Support

No, I'm not an XP'er. I think they had some great ideas - but no, I didn't just close my eyes and say all of them were good ideas and jump on board. Am I a RESTifarian? Give me the tools to evaluate and I'll let you know.

Inserting Nouns into the Service Network

For the last 6 months I've been investigating the separation of nouns and adjectives from the verbs and adverbs. For those that don't follow my blog on a regular basis, here is a quick summary:
Nouns are people, places and things - in the software world they are our domain entities (User, Invoice, etc.) - and adjectives are the properties that describe the nouns. In the J-world we used Java classes to describe them - in the W-world we use XML schemas.

Verbs are the actions. Actions have (at least) two forms: technical (insert, update, delete, publish, etc.) and domain or business specific (ship, pack, etc.).

Technical verbs often act the same way on any given noun. Why is this important? Imagine walking into an enterprise with a set of nouns on a floppy disk. The company already has a service network in place. This ServiceNet is composed of 12 servers (portal, database, security, etc.) and runs 46 services. Each server has the capability of 'listening for new nouns' and a 'registration service' has the responsibility of: 1. Notifying the servers of newly registered nouns and 2. Notifying the servers of newly registered servers.

Ok, we just moved into a world where the network is aware of the network. No magic, just simple registration. What gets interesting is when nouns have 'default implementations' of a verb on a server. And surprisingly, you will find that this is possible and beneficial. If I add a new noun to the ServiceNet will it likely have security permissions? Will it need to be stored? Will it be viewed? Should I role all of this code by hand? Again, the goal isn't to perform magic - it is to create a network programming model where we think more about how to create smart verbs and dumb nouns. The servers are slowly given the ability to interrogate each other and eventually a common set of functions is factored out of the servers and dropped into the network.

I'm convinced that service oriented programming has the potential to get absolutely unmanageable. I talk with customers every day - they almost always start the conversation by bragging about the number of services that they have. Every time I hear this I think "Oh my God, what a maintenance nightmare! And they've only begun." In Schneider-land, the goal is to go for the smallest number of services, with the highest amount of reuse. Figuring out how to do this is a bitch.

Going from Services to the ServiceNet
The first step that I recommend is to take a look at all of the operations on all of your wsdls. Categorize what you already have (VerbOnly, VerbNoun, VerbMechanism, other). Then, determine if you could have made more re-usable services. What would they look like? Create a spreadsheet with the verbs as rows and the nouns as columns. The cells (or intersection points) are the realization of the VerbNoun. Beware of verb synonyms, or made up verbs (verbs that are really nouns). What is the smallest number of verbs you require to fulfill your needs?

Custom Metadata

I was just talking with one of my CTO buddies. He was bragging that implementing his software product at a client site requires no custom code. I paused for a moment and asked, "Does it require custom metadata?" To which he answered, "Yes, and it has a nice front-end to enter it in."

My first thought was that he was just pushing the problem from one location to another. But for some reason, it does feel better pushing the problem from code to metadata, but I'm not entirely sure why. I like the idea of not compiling everything (a benefit of metadata). I also like the idea of having domain constraints on the data being entered (versus 3rd gen languages). I guess that a system that embraces MOF/MDA/metadata concepts requires less in-depth expertise. In essence, the expertise is built into the framework, enabling a 'paint-by-number' approach to recurring pattern based problem solving (resources require less training, thus less expensive).

I'd love to hear what you think the advantages to a metadata driven approach are. Blog it. Link to this. Click through once. I'll repost referers.