WS-MetaDataExchange and WS-Transfer

WS-Mex, also known as WS-MetadataExhange, was updated this month.

However, in an odd move the spec does not reflect the WS-Transfer udpates:


Am I missing something? I thought this was the entire point of WS-Transfer? Don't get me wrong, I still think it is absolutely hysterical that the 'Metadata' spec is mostly hard-coded and doesn't use metadata!

I've been thinking about replacing the WS-MetadataExchange spec with my own. Here it goes:

SOS-GetWSDL
1. Append "?WSDL" to the end of a call to a valid port.
2. Expect a WSDL to be returned.
3. The end.

On WS-Opposition

Tim Bray, who has spent the last several months crapping on the WS-* stack has agreed to shut up or put up. Thank God.

If Tim and team are able to create something better than the Service Oriented Standards (S.O.S.), then I'm the first one on board. I'd love to see Sun get active. Their pissing and moaning that they weren't invited to the party is just too old. So, here are my recommendations to S.O.S. V-2:

1. Start with a vocabulary. Write down the words you will need. Don't write them in XML - write them in English (or other non-XML markup).
2. Publish your vocabulary in the simplest manner possible.
3. Ask smart people if the words and domains are correct.
4. Compare the list to existing vocabularies (J2EE, .Net, etc.); identify the delta.
5. Apply the 80/20 rule to the words, cutting as many as possible.
6. Create a constraint based architecture. Never say "You MAY", only "YOU SHALL NOT".
7. Create profiles of constraint architectures (SMB, Enterprise, etc.)
8. Publish the candidate architectures along with the vocabularies.
9. Wait for people to crap on S.O.S. V-2; they will.
10. Defend your ideas, learn from the debate and prepare for V-3.

Good Luck. Jeff

WS-CaveMan

I invented a new game for web service engineers called Cave Man. Here are the rules:
1. The game lasts for an hour.
2. When speaking to each other, all engineers are only allowed to use the following verbs: GET, PUT, DELETE and CREATE.
3. All predicates must be spoken in Latin or a language other than your native tongue.
4. Nouns and adjectives may be used but only if they have been written on a common whiteboard first.

Ok, I’m only joking – but you do realize that this is the game the web service engineers are being told to play with business systems.

What do I think of WS-Transfer? Easy, we have now created a vocabulary of four common words. At this pace, we should catch up to the pre-historic cave man in about 20-25 more years.

Don Box makes an interesting comment. He basically states that using four verbs can be dangerous. And I agree. However, I am of the opinion that the WS-* spec teams are doing a severe disservice to the community by releasing these specifications without also identifying the best practices. In my opinion, it is no longer acceptable to release paradigm changing specifications without also releasing an implementation or best practice guide to go with it.

In regard to the spec itself, I think it is fine. I don't agree with Ole' man Baker that we are just re-inventing HTTP. Pure REST has its place and SOAP has its place. Standardizing verbs is good. I was a bit curious why the group didn't create a 'verb extension' or 'verb introduction' mechanism, but rather just 'hardcoded' a handful of verbs.

IMHO, the creation of four verbs is a good thing. It will make people think about why WS-Transfer is limited, which will lead discussions on why an 'Enterprise Vocabulary' is needed.

Value-Added-Clown (VAC)

A recent IM conversation (names changed to protect the innocent)

----------------
BILL says:
I have a couple of developers working for me and I'm not terribly impressed with their abilities thus far.

BILL says:
I'm working for XYZ Finance Company

Jeff Schneider says:
*use opportunity to learn more about Finance software*

BILL says:
they were wanting to use SWT as their UI technology

Jeff Schneider says:
screw SWT and UI

BILL says:
is there something to gain from learning about finance software?

Jeff Schneider says:
learn finance domain

BILL says:
SWT blows

BILL says:
what is the advantage that I should be looking at with Finance domain?

Jeff Schneider says:
Business domain is more important than changing technology

BILL says:
yeah, I'm figuring that out

BILL says:
from a manager's POV, how should I approach my manager to tell him I don't think my developers are cutting it (if I perceive that)

Jeff Schneider says:
value is a function of cost over output

Jeff Schneider says:
make sure you know what the cost are before determining value

Jeff Schneider says:
(you see output)

BILL says:
you mean cost of bringing in new developers and getting them up to speed?

Jeff Schneider says:
if he's paying $4/hour for current people than you may be giving him bad advice

BILL says:
true

Jeff Schneider says:
don't advise until you know costs

BILL says:
aha

BILL says:
since I don't know their rates, I can't make that call then

BILL says:
right?

Jeff Schneider says:
yep - but feel free to ask

BILL says:
is that something they call tell me?

Jeff Schneider says:
sure

Jeff Schneider says:
you should also ask the manager if he/she wants your input on such items

BILL says:
what other info should factor into that decision?

Jeff Schneider says:
(output, quality, etc)

BILL says:
it has been relayed to me that I should advise on such matters so I assume that is a responsibility for me

BILL says:
but I should assume nothing

Jeff Schneider says:
if mgr doesn't want to tell then tell him what the perceived bill rate of person is "I'm guessing that your paying about $35/hr for Balu - - which seems appropriate..."

BILL says:
ok

BILL says:
you tell me if this would be a warning sign to you

BILL says:
I asked one to write a Java2D demo (as a replacement for a flash module) that was a simple graph that when values were changed, the graph adjusted)

BILL says:
he proceeded to download sample code from Sun and paste it and tried to modify it (this was after he told me he felt very comfy with Java2D)

BILL says:
would that be a red flag?

Jeff Schneider says:
maybe - but not necessarily...

BILL says:
what would your thoughts be?

Jeff Schneider says:
1. I'd assume person lied about expertise in the technology (people always do)

BILL says:
oh yeah, I had to help him get a demo going cuz he couldn't figure out his compiler error (tried to instantiate an anon inner class from a main)

Jeff Schneider says:
2. I'd be more concerned about ability to get up to speed and then get dedicated to knocking it out

BILL says:
yeah, I've already figured out that they lied

Jeff Schneider says:
3. Then concerned about willingness to refactor until the design was correct (on his own dollar)

BILL says:
would you say micromanagement is going to be my best bet at getting this delivered as it should be?

Jeff Schneider says:
no, but tight iterations would be advised

BILL says:
yeah, weekly code reviews a good thing?

BILL says:
I'm already drawing up a standards doc as a guide

Jeff Schneider says:
sure, lots of builds, demos with mgmt, etc

Jeff Schneider says:
Visibility = "Putting glass box around large turd."

BILL says:
hehe

BILL says:
kewl

Jeff Schneider says:
your first duty is to make them succeed though

BILL says:
right

Jeff Schneider says:
more times than not, you'll end up with Bozo's on your team. Great engineers are ones that can turn clowns into productive team members

BILL says:
guess that would be a good test of my ability ?

BILL says:
hehe

BILL says:
how yucky

Jeff Schneider says:
yep - but that's what separates the pack

Jeff Schneider says:
give mgmt visibility while backing clowns
-----------------

So, I really believe the advice that I gave to *Bill*. Any jack ass can throw another incompetent engineer under the car. The manager should have visibility into *suspect* engineers, but until a *suspect* is proven guilty, it is the job of the more senior engineer to make the rest of the team succeed.

The Mob Effect on the CEO

I've been witness to a recent phenomenon. I don't know what to call it, but I'll attempt to describe it to you.

Software companies have been hiring huge teams (Mobs) of programmers in India and other low cost labor supply areas. The purpose for these hires is to 'create more software, faster'.

When the CEO goes to see the Mob they get excited. They see dozens of cheap bodies lined up and ready to work on whatever brilliant idea is floating in the heads of the executive team. They become drunk on this new, cheap power. They get 'beer muscles'. At the sight of all of these cheap bodies they feel like they have their own little army and can take on the world (or at least a larger competitor). And this is where it begins.

Mob Mania has struck more CEO's than I can count. With their new perceived power they begin to do the unthinkable. They build products in spaces where they know very little. They create a 'portfolio of checkmarks'; that is, they build products purely for the sake of rounding out a portfolio and checking off products. Checkmark Portfolios are never about having the best product - they are about having all products. It is almost an acknowledgment that the executive team was too stupid or lazy to do their homework and determine which products really needed to be built and which should have been OEM'd or left out of the portfolio all together.

Checkmark Portfolios lead to an interesting destination. Buyers see dozens of vendors all claiming to have the exact same set of products. They look under the covers and find that the products were designed with minimal depth while maximizing breadth. The amazing similarity of the products being offered by direct competitors leads to a new buying process.

Now, the focus is moving off of: 1. Having the product or 2. Having the rounded portfolio and since the product was built at dirt cheap prices, the focus usually isn't on the price. The focus is on 'trust'. Said another way, the focus is on brand.

Like all products that are easily commoditizable, the focus moves off of product differentiation and to brand awareness and brand identity. However, it is an interesting time to create brands. With the low investment model required to create a Mob, more and more small companies are sprouting up determined to get a piece of the action (many of these companies are now based in Europe or South East Asia).

The room of vendors is crowded and everyone is yelling for attention. The CEO sees this and thinks two things:
1. "It's going to cost some serious money to get my message above the noise level."
2. "Oh shit, what an awful time to have a commoditized product."

Life has taught me that heard mentality pays for the few. I've seen it over and over again. I watched the VC's pull a heard model and now I watch another. The leaders of the heard will win. The followers will be left in the dust. Second and third tier ISV's will be crushed in a battle whose outcome is so obvious that it is almost uninteresting.

Things are busy...

Well, I've been busy.

We've seen our consulting business pick up considerably and the sales pipeline remains very strong. Momentum has been adding a new employee about every 5 days and I believe this will continue through the end of the year.

Most of our projects now have some component of web services. Here is a sampling:
- SOAP gateways to access legacy systems
- business objects being converted to business services; data layers being turned into data services
- laying down foundational ws-infrastructure (policy, monitoring, balancing, etc.)

Some other trends:
- desire to have pure SOAP as well as a slimmed down XML services (no RM, Sec or TR)
- "ESB" has made its way into RFP's
- brand awareness of ws-pure plays is much higher (Systinet, Blue Titan, AmberPoint, etc.)

Still, the world remains divided on how they view web services. As I recently told one of our customers:
"The web service protocols are at an adoption level equivalent to where you may have found TCP/IP in 1993 or 1994. Mass adoption has not yet occurred, but the writing is on the wall and no one is buying proprietary standards (Novell IPX/SPX). As we begin 2005, web services will enter into their 5th year in existence and remain the cornerstone strategy for vendors like IBM, SAP and Microsoft. This must be part of any go forward integration strategy for a Fortune 2000 company."

Come to think of it... some of those customers are still running IPX/SPX :-)