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?