Service Oriented Enterprise: 2003

Wednesday, December 31, 2003

Is the JCP obsolete?

Richard Monson-Haefel, a man who has seen Java from the beginning responds to an interesting question, "Is the JCP (Java Community Process) obsolete?

Richard defends it.

Perhaps it is no surprise that I think that Richard is dead wrong and that the JCP is largely obsolete. The Java game used to be about creating enough mass for wide spread adoption of a platform (J2SE, J2EE, J2ME, etc.) Well, this has already happened. And more importantly, a couple of vendors (IBM and BEA) have come out on top.

Richard states, "The truth is, IBM and BEA need the JCP. Neither of these companies could go it alone, outside the JCP. " IMHO, this is one of the most naive statements I've heard in a while. IBM and BEA realize that they the competition isn't Sun, Oracle or Geronimo - it is Microsoft. And as long as they have the JCP dragging their innovation cycles they will be competing in an uphill battle.

So, is the JCP obsolete? My answer is - partially. It is obsolete when the IBM / BEA need it to be. There will continue to be many technologies that aren't critical path that can be run through long laborious debates (aka, jcp). But, for those technologies that are core to competing against Microsoft, I anticipate (and hope) that they take the quickest path with the least drag on the innovation cycle.

Sunday, December 28, 2003

The Perils of Predictions

I'm writing my 2004 hot technology list at the same time that I'm outlining a paper on converging programming models. I'm quickly reminded of the perils of predictions...

Hmmm... perhaps the "Constraint Based Enterprise" ? ;-)

Top 10 Technologies of 2003

Last year at about this time, I posted my top 10 technologies for 2003. Overall, I'm pretty happy with my calls.

1. Business Process Execution Language (BPEL)
Yep, still a good call. In 2003, it became apparent that BPEL won the digital process language war. Look for adoption in 2004.

2. Web Services II / GXA
This referred to the ws-* stack. Good progress was made on standards - not much adoption.

3. Microsoft .Net
This was an easy call. MS .Net kicks ass - however their long development cycles on the tooling isn't helping.

4. Flash MX
OK, this one didn't really happen to the extent that I was predicting. Instead, I believe that we are seeing a general trend towards richer functionality user interfaces, some leveraging xml or web services.

5. Industry XML Standards
This one did OK, but could have done much better. I think that many of the standards bodies advanced their specifications and cleaned up their schemas.

6. Business Process Management (BPM)
OK, this was a bad call. BPM has sucked wind due to the 'architecture in a box' syndrome. BPEL with MDA will help.

7. Portlets
Portlets did get off the ground - but no where near what I'd hoped. Perhaps next year?

8. Total Value of Opportunity (TVO)
Bad call. Does Gartner even promote this? It sure seemed like a good idea...

9. Software Asset Reuse
Terrible call. Software asset reuse requires a major change in the programming model.

10. Extensible Business Reporting Language (XBRL)
OK, this one actually got a bit of traction. However, I'm not sure if it was hype or actual usage.

HELP - I'm running out of time! I still have to write my top 10 enterprise software technologies for 2004. If you have ideas, please send them to me: jschneider AT momentumsoftware DOT com.

Saturday, December 27, 2003

What is a programming model?

My recent entry on programming models generated a couple of responses. Shane Claussen of IBM commented that the Service Network is the model, or perhaps the SoA is the programming model. Now, I fully agree that a service oriented architecture presents a programming model, but I am not sure if it should be considered the 'first-order' model.

Per my request, Shane went on a took a couple of stabs on the definition of a 'programming model':
1. A PM is the tools and methods for building a service or an application AND
2. The PM is the visible components of an architecture that a programmer codes to/with.

Hmmm. I like these definitions. I've scanned around the internet a bit... and haven't found much better.

But Frank Martinez, CTO of a leading service fabric company (BlueTitan) posed a new question:
What's more important (i.e. strategically relevant) to "you" (i.e. the practitioner)?:
1) Infrastructure-independent tooling
2) Tooling-independent infrastructure
3) Infrastructure-driven Tooling
4) Tooling-driven infrastructure

He went on to state, "My personal answer (and preference) with respect to your question would be that your service network should enable (and encourage) a variety of service-oriented programming models...each of which could be business driven in it its own right. Additionally, your service network should feature a service-oriented extensibility model that shouldn't be constrained by any one given programming-model."

I like this. The only thing I would add would be to encourage non-service oriented programming models in the network as well. Blasphemy? Perhaps, but I hope to make my case over the next several months.

"What is my Service Oriented Extensibility Model?"

Wednesday, December 24, 2003

Reading Material - Flight Home

Here is something to read for the flight home...

Edsger Dijkstra, way ahead of his time, "Hierarchical Ordering of Sequential Processes":

Tuesday, December 23, 2003

Service Programming Models

Once again, I am on holiday break, visiting relatives - tucked away between some farms in Illinois. But luckily, StarBucks is only a mile away. Each break, I attempt to write something. One year I wrote the Java book, another I wrote Service Oriented. This year, I'm feeling as ambitious as ever, but the subject seems more complicated than those that I've pondered in the past:

"Does the architecture of your service network define your programming model or does your programming model define your service network architecture? "

Well, that is my starting point. Perhaps I'll throw out both notions and go somewhere completely different.

Friday, December 19, 2003

Ivar Jacobson - Trends

What is Ivar Jacobson talking about these days?

Abstract: In this talk Ivar Jacobson will discuss four trends, major trends that he believes will change the way we develop software from being machine centric to becoming human centric.

The trends are:
- Closing The Gap - business driven enterprise application integration
- Building Extensible Software with Aspect-Oriented Programming
- Making Software Process Execute with Agents.
- Executable UML -- eliminating the two language problem

Thursday, December 18, 2003

Advice from my mentor

I had a chance to sit down with my technical mentor tonight.
He had two pieces of advice for me:
1. The "true" bus is TCP/IP.
2. BPEL should be an enabler not a disabler. Services should be part of a fluid programming model - not a cumbersome extension.

Compositions, Services & Fabric

I thought I'd pull a slide from our deck...

Tuesday, December 16, 2003

"Yea, I'm building an ESB..."

Yesterday, I met with a consultant that I used to work with. I asked him what he has been up to and he told me that he is writing an ESB. To which I could only respond, "just you?" And he answered ,"yea.. just me, why?"

He then went on to explain to me that he was building his ESB on top of JBossMQ. And that 'what' he was building was the 'extra services' like validation, transformation and a tad of routing. He made a real interesting point. There isn't a whole hell of a lot in an ESB. The JMS based message queue is commoditized, validation services can be ripped from probably any thin client J2EE app, transformation is usually a prepackaged library, and light-weight routing isn't rocket science. He told me that he had some other services planned and that he would likely throw his version into the open source community when he was done.

Hmmm. I found myself almost speechless. But, I gave him some advice and wished him best of luck.

In the past, I've made fun of the ESB - mostly because of the pure amount of hype that has gone into it by the media and one analyst and a few vendors. But it has now occurred to me that making fun of an ESB is like making fun of 'JavaDoc' or 'log4j'. It is a very small commoditized piece of software that will work its way into many applications. I don't know if there is a big market for reselling 'log4j' nor do I know if there is a big market for the ESB. Frankly, the "Apache ESB" sounds about right. There may be a bigger market for the sophisticated ESB leverage a service fabric and can be leveraged by high-end service composition tools. But as far as I know, no vendor has gone done that road (yet).

Perhaps we could house the new open ESB here... along with handful of other buses that my partner in crime, James Higginbothamhas written over the last 7 years...

Sunday, December 14, 2003

Sorry, we still need programmers...

This kind of thinking is just plain silly:
"In theory, because composite applications use software components, they can be built by a trained business analyst rather than require the services of a full-fledged programmer. "Just as you don't need to know how a Web browser works to create a Web page," says Jason Bloomberg, senior analyst at ZapThink, "you won't need to know how one software actually interfaces with another to build a composite application."

People, we are so far off from this concept... where business analysts do some magic stuff and software pops out the other side.

These kind of comments are dangerous... they just make us look like bozo's that over promised and under-delivered. We are moving into an age of contract based development, not "miracle-based development". For some period of time the complexity of putting together service oriented software will INCREASE not DECREASE. We are trading reusability and agility for a decrease in performance and increased complexity. Programming a distributed, heterogeneous web service stack with business logic spread across the network isn't simple. Adding a set of 20+ new specifications won't make life easier either.

Business analysts will create business cases.
Process analysts will create better processes.
Architects will divide up the problem.
Service analysts will encapsulate the problem into small components.
Platform coders will program them.
Orchestration designers will tie the services back together.

No magic, just good ol'fashion hard work from a variety of specialists. Hey, I look forward to the day when 'Service Oriented BPM' is here too. I'm working on it - my competitors are working on it, but promising it now is not in our best interest.

Saturday, December 13, 2003

Cape Clear Takes On "Extra Baggage"

Annrai O'Toole, CEO of Cape Clear had commented, "O'Toole claimed that complicated protocols like the Business Process Execution Language for Web services (BPEL4WS) or the Web services Choreography Interface (WSCI) are extra baggage and that any functionality that those specifications are designed to handle is easily covered by something found in virtually every system: JavaScript (also known as ECMAScript)."

Since then... he apparently has changed his mind, referencing the Cape Clear suite... "The product also supports Business Process Execution Language (BPEL) for sequential workflows and composite Web services. Through this support, users can chain sets of Web services to deliver a single, composite service, Cape Clear said. "

Well, good!

The recent article went on to say, "The Cape Clear Data Interchange is a lightweight alternative to EDI and ETL (Extraction, Transformation and Loading) and allows such documents as spreadsheets, order forms and expense reports to be exchanged between applications regardless of format."

The requirements of *real* ETL software are significantly different than those of a messaging system with transformations. In the few instances where I've seen vendors attempt to build both features into a single product they usually end up with half-baked attempts at both. My guess is that Cape Clear did something more like an ESB but is casting a broader net to see what fish they catch... more investigation is necessary.

Tuesday, December 09, 2003

Paul Brown publishes a great BPEL presentation

Paul Brown of Five Sight has published a great BPEL presentation. He has some great insights and manages to explain complex issues using simple terms.
Well done!
See:
http://blog.fivesight.com/prb/space/BPEL/BPEL4ProgArchies.pdf

Saturday, December 06, 2003

Process Oriented Uptime

As more and more applications are moved to a process-centric approach, I believe that we can anticipate a fundamental change in the systems management layer. Today, most systems management products tend to focus on measuring the uptime of a computer, a cluster or a piece of software (like an application server). As our applications become more distributed across the network (web services or other means), it will become essential to view the uptime (and other quality concerns) from a process perspective where the system would scan all of the involved services and their respective non-functional concerns. After all, a sales manager isn't concerned with the up-time of a WebLogic instance; rather, he/she is concerned with the ability to work the sales process.

Integrating software quality concerns back to the business process at hand will also allow people to prioritize the processes and re-allocate resources according to the business impact. One could see where the various 'on-demand' efforts that are being pursued could come in very handy in this scenario.

ZapThink Kicks Gartner Below the Belt

In the last fifteen years of following I.T. analysts, I am unable to remember when one analyst group called another "dead on arrival", but that is exactly what ZapThink has done.

Going far beyond their bounds of providing useful, unbiased information, ZapThink took direct aim at Gartner and called their web services framework "Inaccurate", "incomplete", "unhelpful" and an example of "a horseless carriage".

In my opinion, the decision for ZapThink to take public aim at an older Gartner report lacks professionalism and maturity. Perhaps it is time for ZapThink to reconsider their own reports, to concentrate on their customers and avoid the below-the-belt attacks on the competition.

See: http://www.zapthink.com/report.html?id=ZAPFLASH-12032003

Sunday, November 30, 2003

BPM Twist

Here's an interesting BPM twist. A company called, "Clear Technology" claims:

"Tranzax is the industry’s first business process management platform designed specifically to capture and replicate the business processing behavior of an enterprise’s best employees, and then optimize and extend these best practices across the enterprise."

I have no idea if they can pull this off, but I like the sound of it. It does raise an interesting question. If you force everyone to use the same process, how can you expect process innovation to occur?

Saturday, November 29, 2003

RFID Chips used for Mind Control

According to the former Chief Medical Officer of Finland, RFID chips are now being used for mind control. Now, I know what you're thinking... the transmission and storage capabilities of RFID are so low, how does it work? Well, I don't know. Apparently, the trick is to hook the antenna up to the brain stem and the electricity wires up to the cerebrum and then 'think' real hard.

The application for the device is targeted at creating a more choreographed dance line. Joseph O'Shea, the producer of 'River Dance' commented, "Gettin all these dancers to move together is a real pain. That's why we are switching to RFID Mind Control". However early tests of the device were less than successful.

We determined that midgets and fat people are less susceptible to the radio waves, as well as people that have consumed large amounts of Mad-Dog 20/20. More recent tests have confirmed that the systems works best with gay Irish men dressed in black.

The company behind this venture, "Coordinated Dancing Inc." are considering new markets. Unfortunately, most of the senior management team has been infected with gangrene of the medula which has left them without control of their bladders and urinary tract. CFO, Jimmy McDonald commented, "We've got a think tank working on the issue now - everything from more company toilets to bulk purchases of 'Depends' - we will not let gangrene of the brain slow us down. Inserting 10 cent chips into the brain of every man, woman and child is the future!"

Friday, November 28, 2003

A Service Oriented Coupling Index

In December of last year, I issued a challenge (really to myself) to work on a 'service oriented coupling index'. I was searching for a quantitative way of determining how loose or tightly coupled software entities are. I took a look at much of the academic literature but found that most of it was out of date or needed rethinking in the service oriented world. More recent work, such as that performed by Doug Kaye was a great help in the pursuit.

At the end, I produced an initial report called, "An Inter-Service Coupling Index for Lossless Exchanges"

I learned a couple of lessons in the process:
1. A coupling index is possible, however the quantitative aspect still lies in the eye of the beholder (which Doug and others warned be about). Thus, in many ways the coupling index becomes a 'best practices' in coupling guide.
2. The pursuit of the coupling index was extremely interesting. I am convinced that the value to be taken away from the report isn't the index but rather the insight on areas where coupling may still be reduced.

Please feel free to send me your thoughts (good or bad). I plan on putting out an updated version on Jan 1. And thanks again to all of you who sent me early feedback. Have Fun! jeff

Thursday, November 27, 2003

MS Millennium Goals for OS

I just ran across an interesting paper from MS, see:
http://research.microsoft.com/sn/Millennium/mgoals.html
Perhaps Christian would be kind enough to blog on 'Longhorn' and how close it is to reaching some of the goals.

Wednesday, November 26, 2003

Service Data Objects

IBM & BEA released a new specification for Service Data Objects. In my opinion, this is a much needed and perhaps overdue specification. SDO introduces Data Objects and Data Graphs which are self-describing data containers that can be manipulated, serialized and navigated. The feature that really got my attention was the ability to create a 'change log' of the data set. In essence, this feature mimics the functionality found in .Net called, "disconnected datasets'.

It is also apparent that the specification writers have gone out of their way to plan for a service oriented world. The use of XML Schema and a SOAP binding are utilized. I'm getting the feeling that this will be an underlying work-horse for some follow-on specifications.

Tuesday, November 25, 2003

OpenStorm Demo

Starting in December, I will be giving some one-on-one demonstrations of the OpenStorm Suite to prospects.
Here are my initial travel plans:
Dec. 2 - Houston
Dec. 3 - Dallas
Dec. 4 - New York
Dec. 5 - Atlanta
Dec. 10-11 Philadelphia
Dec. 18 - St. Louis
Dec. 19 - Chicago

Most of these days are only partially booked. If you are considering a purchase in this space and the date/location works for you shoot me a note! jschneider AT OpenStorm DOT com. The talk will focus on Service Oriented Integration techniques, the Service Network and using BPEL as an integration mechanism.

I'll be setting up a west coast visit in January.

Monday, November 24, 2003

OCL for Web Services

Radovan wants OCL for web services (or more precisely, he wants a Service Constraint Language). I do too. As far as I know, a variation of the Object Constraint Language doesn't exist - let's call it SCL.

But be careful, just because you define constraints (pre-conditions, post-conditions, message verification - and potentially even the order of service participants), you haven't created a replacement for a fully defined business process. I love constraints - and I love fully described digital business processes - and I really love when the two are combined.

I've been having some offline conversations on the 'coupling index' - a means to quantitatively determine a 'loose or tight coupling factor'. One thing I noticed is that by having a centrally defined business process, we are able to have more fully encapsulated services (we shift knowledge out of the service and into the process). However, I've also noticed that the current state of web services fails dramatically in being 'fully encapsulated' - mostly due to the lack of constraints put on the operations. That is, a significant amount of knowledge beyond the interface is still required.

And yes, if we wanted... we could build an SCL as a web service... which means we could orchestrate the pre- and post condition calls. :-0 (not that you would want to... I'm still in that mode where everything looks like an orchestration...)

p.s., I'm a fan of point-to-point integration as well!

Saturday, November 22, 2003

Service Hijacking

I've been playing with a BPEL concept that I'd like to share... I'm calling it 'service hijacking'. It goes like this:

Some company releases a web service; for example, Amazon. This web service has a wsdl describing all of the operations and messages. The wsdl is published in a public directory for consumption.

Some other company, "OnlineBooks", decides to launch a marketplace for book shopping. So they create a BPEL service that front-ends the Amazon service, but adds calls to "Barnes & Noble" and a few others. Perhaps they even kept their wsdl the same as the original Amazon wsdl in order to allow the 'consumers' to easily switch over. At this point, we have added new value to the consumer, so all is good.

Then, some other company, "MarketResearchBooks", launches a new service to front-end the "OnlineBooks" service. They support all of the same features, but also keep records of who had the lowest price and then sell that information back to the original retailer. And yes, to the best extent possible, they kept their wsdl looking like the original WSDL Amazon wsdl. At this point, we didn't *really* add new value to the consumer, but we didn't take any value away.

Then, another company, "OnlineSuckers", launches a service to front-end the "MarketResearchBooks". It adds no new value, but asks people to pay for the service on a per-use basis. Now, we have a problem. The value of the service went down, not up.

Making information available online in a structured format for public consumption is a tricky proposition. In some cases, you don't care what people do with your information, while in other cases (OnlineSuckers), you might care. In my opinion, a service is hijacked when the value of the service goes down (rather than up) from the re-purposing of the call.

The earlier examples ("Online Books" and "MarketResearchBooks") are what I call either 'service piping' or 'service chaining'. These are good things. They take information and add or maintain the same level of value. Of course, there is a different technical argument to be made against long chains of services, but I'll save that for another day.

---- after thought----
It just hit me that if you don't write BPEL scripts everday, you might be wondering what this concept has to do with BPEL. Yes, service hijacking can be accomplished through your favorite programming language (java, c#, etc.) However, BPEL facilitates this functionality with VERY little effort. With the OpenStorm suite, I can service chain Amazon in under a minute, add marketing statistics in a couple of minutes and hijack on a payment service in under a minute. I guess my point is that BPEL makes this stuff very easy to do.

Friday, November 21, 2003

BPEL Validator :-)

It might be time to get that BPEL Validator routine up and running.... just in case any company were to release a few BPEL extensions...

:-)

And congratulations on the release.

Monday, November 17, 2003

Bean-counters to Join Programmers

VentureWire had great news today. More accounting and finance jobs will be moved offshore!!

It is clear that geeky American programmers have no idea on how to influence congress. Surely our accounting brothers can help out...

=============================
Ephinay Raises $10M Series B
By VentureWire Staff Reporters 11/17/2003

Charlotte, N.c.Ephinay, a finance and accounting business process outsourcing firm, said it received $10 million in Series B financing. [full story]
http://www.ephinay.com
=============================

Outsource Partners International Raises a Potential $20M in Series B
By VentureWire Staff Reporters 11/17/2003

Outsource Partners International (OPI), a provider of finance and accounting outsourcing services, said it has raised $12 million in its Series B round. The round could potentially bring in $8 million more. [full story]
http://www.opiglobal.com

=============================

Two in one day!!! Kwe Kwe is going to get crowded!!

Sunday, November 16, 2003

Junglemen Hex American Programmers

In a rare move, the normally friendly tribesmen of the Zimbabwe jungle put a voodoo-like-hex on the American programmers working there.

Frank, who was laid off from General Electric's I.T. department some time back explained, "After training my Indian replacement at G.E., I decided I was going to beat the game. If the trans-national corporations were only interested in low-cost labor, it was clear that I'd have to reduce my cost-of-living expenses. That's why our whole development team moved to the jungles of Zimbabwe."

"Unfortunately, we were found by the local tribesman. I don't fully understand their language, although it appears to be a blend of Morse-code and ASCII. From what I've gathered, they are concerned about too many U.S. programmers coming here." In an effort to remedy the concerns, Frank intends to meet with the local governing council. "I will explain to the council that we can put 'caps' on the number of American programmers that can come to the jungle - AND... they will be forced to leave after a certain number of years. In essence, we are pitching them a variation of the H1 and L1 programs!!!"

The city of Kwe Kwe, Zimbabwe is quickly becoming a technology hotbed. In addition to American programmers, recently displaced developers from Hyderabad, India are also flocking over. Amit Maheshwari explains, "Yes, we used to specialize in convincing American companies to come to India... now, we make our money selling the U.S. trans-nationals infrastructure to create wireless zones in the jungle. We have also tried to get them to subsidize the mosquito repellent, but so far haven't had any luck."

Saturday, November 15, 2003

Project Liberty & WS-Federation

Project Liberty, is a federated trust & identity based scheme. It was created as a "Microsoft Passport Killer". A couple of years ago, MS was pushing Hailstorm and Passport as a mechanism to centrally control identity and schema based data. The fine folks over at Sun (and friends), came to the conclusion that they didn't want MS to control all of the user id's in the world - and for good reason. Thus, they came up with a specification to decentralize identity & trust. The program came to fruition just after the September 11th tragedy, and was given the very awkward name, "Project Liberty" - I guess they felt that they were 'liberating identity' or something like that...

Well, Project Liberty did what it was supposed to do. It created an alternative means to accomplish the same goal as Passport, without handing over the family jewels to MS. However, Project Liberty was created prior to the creation of the WS-* specifications. This means that for the most part, it has overlap with some of the newer specifications created, like WS-Trust, WS-Privacy and WS-Metadata.

I'm a huge fan of "concern-based protocols". Thus, I like having 'trust' as its own protocol - and 'privacy' as another protocol. I don't like mixing concerns in a single protocol; which I believe Project Liberty is guilty of. From a cursory view, it is appears as though WS-Federation covers the bulk of what is actually needed. I'm not an expert in this area - but so far, it looks 'good enough'.

The Project Liberty group recently published a paper comparing the approaches. Although the paper attempts to subtly convince the reader that their approach is better, for me, it has the opposite effect. They basically claim that they have successfully lumped a bunch of standalone concerns into one specification. In addition, they did it prior to the existence of the WS-* specifications, thus the implementations that are available won't be technically aligned with the needs of the next generation web service developer.

I'm not ready to say, "let's kill Project Liberty"... yet. But, I am mentally preparing for the funeral. In my opinion, Project Liberty did what it was supposed to do: force Microsoft down a standards based decentralized ID system. And this is exactly what happened... thus, I consider the project a raging success. But it served its purpose and now it may be time to move on.

Thursday, November 13, 2003

New RFID Application - Knicker Surfing!

According to the Chicago Sun Times, "RFID chips could make your daily life easier, but they also could let anyone with a scanning device know what kind of underwear you have on and how much money is in your wallet".

At first I thought to myself - Wow, what an invasion of privacy! Then, I realized that the Chicago Sun Times may have just found the killer application for RFID. By targeting perverts, we will be able to sell millions of handheld readers to identify the 'kind of underwear' that people are wearing. This is genius!!! Unfortunately, I found out that there is already a growing population of what I am dubbing, "knicker surfers":

Gary, a regular knicker surfer reports, "Yea, it's cool. Me and my buddies come out here all the time and knicker surf. I just hope Walmart pushes PML. Right now, I can only get the underwear brand... with PML I'll be able to get the size too!"

I had no idea. :-)

Wednesday, November 12, 2003

Storing Transient Data

John Udell reports, "Today, most IT shops can't store or process massive flows of transient data. But XML message traffic is a resource that creates strategic opportunity for those who learn to manage it well. Tools for doing that are on the way. "

Hmmm... if I create a persistent store of transient data, is it still transient? Maybe there is a reason most IT shops don't store transient data - wouldn't that just be considered 'persistent data'??
:-)

Ok, I understand what he means - perhaps instead of 'transient' maybe we could call it 'inter-service message data' or just 'message data'? Still, I'm not sure that I buy into the concept. Most I.T. shops do a significant amount of warehousing and reporting off the system of records that generate the messages. The reliability side is currently taken care of by message queue journaling, and realtime inquiry on state is best handled through an inquiry to a business process engine or BAM notification.

Right now, collecting transient data sounds like a bad habit... I need a use-case, with strong, strong justification.

Monday, November 10, 2003

The Realist and the Idealist

I recently had the opportunity to engage in a technical discussion with Chris Sells. We found ourselves agreeing to disagree. He took on the role of the realist, I took on the role of the idealist.

First, Chris and I seemed to be in agreement that distributed computing was easy to screw up. As he stated, it was necessary for consultants to travel the world preaching about *round-trips* (overly verbose message exchanges).

The Realist
Now, I hope I don't screw this up (Chris, correct me if I do).
Chris is of the opinion that we shouldn't paper-over the complexities of distributed computing. By extending the object paradigm into a distributed object paradigm, we unintentionally encourage developers to think in *local mode*, when really they should be thinking in *distributed mode*. His point is that additional considerations must be met (time, reliability, security, etc.) And by forcing the developer to acknowledge these concerns, runtime disasters will be decreased. His feeling is that Indigo (from Microsoft) does a good job of making the developer acknowledge the distinction between local and distributed calls, thus meeting a need in the developer community.

The Idealist
On the hand, I am the idealist. It is my opinion that we should continue to strive towards location transparency. Thus, we should continue to use one programming model (and invocation model) for both local and distributed calls. I believe that the SOA model largely facilitates location transparency and this should be leveraged. However, Chris (and others) will be quick to point out that this is like getting half-pregnant. Either your system is working efficiently in distributed mode, or it isn't. And in virtually every occasion, computer scientists will tell me that the great hurdle in location transparency deals with the static nature of message exchange sequences between client and server. In local mode, people strive towards fine-grained calls and in the remote mode, the coarse grained method is preferred. As an idealist, I am of the opinion that we shouldn't *dumb down* the programming model to reduce developer design errors. Rather, I feel that we should take the bull by the horns and look at the real issue of automating the granularity at run time (based on costing functions). However, to accomplish this, we need to give our runtime containers mode knowledge about our *intent* (think 'use case based sequence diagrams'). Now, instead of asking for a single method to be called, we ask for a 'use case' to be fulfilled. IMHO, more emphasis needs to go on writing smart software that fulfills an intent, rather than acting out a predetermined recipe.

Does Indigo excite me? Not really - I see good concepts from P2P, AOP and Trust rolled together. The exciting part is that MS has the resources to pull it off and make it easy to use.

Chris is a smart guy - he might be right. I don't know.

Sunday, November 09, 2003

This post is about the hottest enterprise technology.

I bet you think I'm talking about web services. Well, I'm not. It's time for me to start blogging about RFID and more precisely EPC.

I've considered starting a new blog dedicated to RFID, but I think I'm going to keep the posts inside of this blog. Web services and RFID will likely settle into a symbiotic relationship.

About 6 years ago, I had sector level responsibility for manufacturing systems at 3M. This involved building, buying and integrating all of the usual suspects (demand management, MRP, Lab BOM, Lab content mgmt., SCE (pick, pack, ship, label, optimize, capacity planning, etc.) Recently, I've had the pleasure of working on a supply chain project with Procter & Gamble. This has been a great experience. The first thing I noticed was that not much has really changed in the last decade. Sure collaborative planning, forecasting, dynamic safety stocks, etc. are all incrementally improving. But for the most part the changes are incremental.

RFID / EPC is not incremental. It is monumental. I'm going to blog more on this later. For now, if you want to get educated , go to the following sites:

http://www.rfidjournal.com/
http://www.autoidcenter.org/
http://www.epcglobalinc.org

Saturday, November 08, 2003

Chris Sells and the Royal We

I just saw where Chris Sells of Microsoft was being questioned about the use of the word 'we':
In the '90s, we invented component technologies, like COM and Java, to bring DLLs into memory and we were very proud of ourselves.

Some of the readers were confused, thinking that Microsoft was claiming that they invented Java. But I understood, instead of "we", he meant to say, "people other than me and my company".

But then he goes on...
Unfortunately, we were so proud that we stretched the metaphor too far with technologies like DCOM, CORBA, and Java RMI. The problem is the idea of a proxy, which was designed to serve as an in-process stand-in for the remote code, hiding the fact that each method call was a round-trip of uncertain duration and uneven reliability. Indigo, on the other hand, is a platform technology that breaks from this metaphor to use a decidedly different way of connecting applications together. Specifically, Indigo uses services, not components, to model reusable units of code.

Holy shit - MICROSOFT USES SERVICES - why didn't the CORBA people think of that??? ROTFL
That's great... unlike DCE and CORBA, we (Chris + Microsoft + Indigo) use services.

Chris, with all due respect, it would be reading a book on the history of distributed computing, then rewriting your article.

Friday, November 07, 2003

Don Box on XAML

Don recently posted on XAML.

Take a good look at the source and the build code. Now ask yourself, are you excited to go out and whip up some XAML?

I.T. Doesn't Matter - Business Process Do

A few days back I mentioned that the new Howard Smith book came out called, "I.T. Doesn't Matter - Business Processes Do". I've had enough conversations with Howard to believe that he is one of the best minds in process driven, service oriented thinking. However, this book was quite disappointing.

Don't get me wrong. I think that Nicholas Carr is an incompetent pansy with a silver spoon stuck up his ass. As far as I can tell, Nicholas has never worked in an I.T. department, been a vendor to an I.T. department, or been the user of an I.T. department. He is a professional writer that gets paid by the word, regardless of the truth in the word.

Unlike Nicholas, Howard is an innovator, a practitioner and an evangelist. However, his critical analysis of Nicholas Carr's work was shabby at best. It appears as though he cranked out 120 pages of material while his emotions had control of him, and bitter emotions at that. It was clear to me that he was racing a publication to press while the Carr episode remained hot in peoples mind.

Save your money. Here are a couple great books:
For business dudes: "Designing and Managing the Supply Chain"
For geeks: "Non Functional Requirements in Software Engineering"

Wednesday, November 05, 2003

Is John Udell Confused?

Is John Udell Confused? If not, I am.

A while back, a librarian wrote to me asking how she could integrate her OPAC with LibraryLookup. I investigated and found that her vendor's implementation was based on a Java applet, and there was no way to link into it. As I mentioned to Eric Rudder and Don Box at a meeting in Redmond, this librarian later posted to a mailing list that her OPAC couldn't support LibraryLookup because it was built on the "wrong kind" of software, where "wrong" meant -- though she wouldn't have called it this -- non-RESTful. For her, the richer experience of that Java applet was a poor tradeoff, since it precluded LibraryLookup's lightweight style of integration.

Is John confusing open systems with "a RESTful" approach? I might be confused... but it sounds like the librarian had an open integration problem - not something that necessarily demanded a RESTful solution. Let's see... if the year was 1993, the librarian may have had a 'CORBAful' issue... or if it was 1990, she had a 'DCE-ful' issue. Maybe what John is trying to say is that we finally have a quick & easy way to store off profile information - - kind of like the 'Win.ini' file in early versions of Windows. It smells like John is wanting to solve some problem with REST, or I could be confused.

Novell Wakes Up

After a long, long, long sleep - it appears as though the team at Novell has woken up and decided to get in the game.

First, Novell acquires Ximian which gives them Mono, a platform for running .Net applications on a Linux platform.
Now, Novell is acquiring SuSE Linux for $210 million in cash.

The way I see it, IBM will be encouraged to remain pure Java - while Microsoft will be encouraged to remain pure .Net. This leaves the 'neutral' ground in the middle wide open.

So, where does Novell go from here? I see more acquisitions. My conversations with people close to Novell lead me to believe that Novell really believes that web services are the *network operating system*. Thus, the Ximian and SuSe acquisitions were only laying the foundation for a distributed computing platform. I would look for Novell to continue down the M&A path, but this time moving up the stack - taking a hard look at web service platform vendors and perhaps even tool vendors like Borland.

But the real question deals with timing. Is it too late for Novell? Did they already lose the hearts and minds of the developer? I personally don't think that it is too late - remember, Novell was the company that forged programs like 'Gold Certified Novell Partner'. If Novell continues to make bold moves, they will attract the talent to create new developer-community offerings.

To Novell - Congratulations. I hope all that sleep you took gave you the rest needed to get into the next big battle.

Tuesday, November 04, 2003

Orchestrating BPEL Validation

This is a repost from the SOA news group:

>
We have been testing our implementations against some pretty large bpel documents with good results. Also, it is easy enough to enforce syntactic validation as a web service. Thus, each vendor (OpenStorm, Collaxa, Vitria, etc.) would expose a service to validate a bpel, then we would publish a simple "validation orchestration" that tested the syntax against each vendors implementation. The customer builds the bpel schedule and then calls the orchestration, which in turn calls each vendors validator. The results are aggregated and returned to the vendor. I can not commit on behalf of any other vendors, but I can commit that OpenStorm will offer this as a service.

The service world (and orchestration) may force standards to remain, well... standards.
Jeff

I would bet that my esteemed colleagues at Collaxa are game for an open validation service / orchestration as well.

Saturday, November 01, 2003

Publishing SOAP Calls

WSDL doesn't completely suck. But it isn't the friendliest vehicle for giving a person access to some piece of information.

Let's get real. WSDL as it exists today was largely designed by distributed computing gurus who have added the art of aspect oriented programming to the art of IDL design, while plopping it all on top of our latest markup language, XML.

The Interface
Now, one thing that I do like about WSDL is that I can define the contract (or interface) without specifying an implementer (the binding / port). This allows me to head down the 'contract-first' design path. It also allows me to create a service contract and easily share it with other people. Interfaces with aspect oriented, or declarative resolution of non-functional requirements are pretty damn cool too. Well done.

The Service
A service is created by binding an interface to an implementation (i.e., listen for the call on port 80, with HTTP...). Thus, a service not only specifies the contract (Types, Messages, PortTypes, Operations & Fault), but one that also specifies the aforementioned deployment considerations (Service, Port, Binding).

Design Time: When you are designing your functional solution, you knock your contracts (interfaces).

Deployment Time: When you are designing your non-functional solution (scalability, availability), you knock out your services.

Publish Time: Now, an interesting question arises when I want to publish my contract and its binding for others to consume. As developers, we tend to think that of sticking a pointer to the WSDL in the UBR or shoving it into Xmethods. Nothing wrong with this, as long as you realize that WSDL isn't easy to consume and that it is very likely that someone will give it a shot and eventually give up because the WSDL didn't give enough information to actually be used for its intended purpose. For that matter, they may just look at the 25 different operations specified in the Port Type and realize that they don't even know which operation to call.

Calls
This leads me to Calls. A Call is an instance of an invocation to a Service. Put another way; it is the SOAP envelope all filled out. In many cases, this is what people really want. Consider this: what if instead of publishing my WSDL (with many operations), I merely publish a single operation with many of the parameters all filled out (default values). Now, instead of exposing a WSDL that has a PortType holding 25 different operations to my Calendar Server, I simply publish a SOAP document that performs a call:
What: CalendarAgendaRequest
Who: Jeff Schneider
How: Use the SOAP format and send it to WS-Addressing( location XYZ)

Prior to the WS-* specs, publishing a call didn't do any good. The calls were self-contained (contractually), but were not self-contained from a service perspective (binding). That has all changed. This means that for the first time, we can pre-populate SOAP calls, save them off and make them available to our end users. This is a HUGE leap forward in usability.

Now, developers will have two options: 1. Create a WSDL will all operations and combinations (for power developers) and 2. Create a SOAP message, partially pre-populated (for business users). Now, in order for this to work, it means that we have to quit writing applications that only suck in WSDL's (like InfoPath, Excel, etc.). In addition, you will have the option to pass in a URL to the SOAP envelope (AKA, SOAP Poiner).

Again, the reason for publishing a call is to make it EASY for a non-developer to gain access to some operation.

Monday, October 27, 2003

Indigo documentation

I finally found some documentation on Indigo:
http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx

Saturday, October 25, 2003

InfoPath to BizTalk

I was just browsing an MS slidedeck on Infopath & Biztalk... One slide pretty much summed it up:

See:
http://download.microsoft.com/download/8/d/7/8d71c8b0-0a3e-4b7d-a301-ba9c9ccf5a9b/ ebz301%20Woodgate.ppt

Friday, October 24, 2003

IT Doesn't Matter - Smith & Fingar

I look forward to reading this one. I really enjoyed his last work.

A new book by Howard Smith and Peter Fingar

From the authors of the bestselling Business Process Management: The Third Wave, read Howard Smith and Peter Fingar's critical analysis of Nicholas Carr's infamous IT article in the Harvard Business Review.

Smith and Fingar have been busy expanding on the BPM breakthrough through a number of articles and this new book. What prompted the book was an article in the Harvard Business Review in May that triggered a flurry of debate in business and high-tech circles, and even some calls from Harvard's business school to sever its links to the venerable Business Review. The sensationally titled article, "IT Doesn't Matter," declared that information technology has matured to the point where it no longer gives companies competitive advantages. Now comes the in-depth monograph that debunks the underlying assumptions and conclusions of the article. A Washington Post feature provides an apt summary of the new book, "In IT Doesn't Matter-- Business Processes Do," Smith and Fingar, draw the opposite conclusion: "The strategic importance of IT is actually increasing as the recent 'business process rEvolution' allows companies to innovate the way they do business." As you pursue your work and spread the word about BPM to your current and future business customers, you'll no doubt be confronted with the IT doesn't matter way of thinking--but now you you have a concise resource to explain how value is linked to IT by basing IT on BPM principles.

Thursday, October 23, 2003

Commerce One: All Hands Meeting

Commerce One, developer of a 'composite process management' solution has been facing difficult times. I've been told that their 'all-hands-meeting' this week was not favorable. They have laid off just about everyone and are keeping a skeleton crew around to service existing customers.

Best of luck to those who fought the good fight at Commerce One.

Wednesday, October 22, 2003

WS-* Extensions for Axis??

Does anyone know if the WS-* extensions have been written for Apache Axis, or are in process?

I've been thinking about kicking off a sourceforge project to start knocking them out. I don't want to duplicate efforts if someone else is already working on them though... send info to: jschneider @ momentumsoftware.com
thx. jeff

Borland Exec Reads McKinsey Report...I'm packing my things

Here's a great quote from news.com:
"And because the aging baby boomer generation is nearing retirement, the United States may be headed for another work force shortage, said William Miller, professor emeritus at Stanford University and chairman of Borland Software. In the meantime, displaced IT workers should get training and be willing to relocate to find new jobs, he said. " - Now there is an individual really thinking on his own!

Here's another interesting one: "People have to be prepared to move," Miller said. "That will be one of the requirements of the work force in the future; people must be willing to move where the jobs are." - Does this mean I will have to move to India?

Moving to India will be a blast. I could go bike riding with all of my other American software associates. I can't wait!!!

My only concern is that all of the jobs in India get moved to China. But surely, India has an aging baby booming problem too... perhaps I could take care of their elderly.

Monday, October 20, 2003

Conference sells out

When is the last time that you remember a software conference selling out?

They are turning people away...

Sunday, October 19, 2003

Radovan has something up his sleeve...

Ok, Ok, I give... what is it?

http://radovanjanecek.net/blog/archives/000026.html

Where did "service fabric' come from?

I recently had someone tell me that when 'graham glass invented service fabric...blah, blah, blah...", to which I commented... you know, I don't know who invented the term 'service fabric', but Microsoft has been using it for a while now...

---- from DevX --- *a few years ago*
In the following paragraph from the same HailStorm announcement, Mark Lucovsky, HailStorm's primary architect of HailStorm, explains the architectural structure for developers:

We have a thing that we're calling the "service fabric," which is the glue that holds [HailStorm], that makes this system possible. It's a common infrastructure that we've built that all these services to run under. It's a common way to name the services. It's a common way to think about the services. It's a common set of interfaces that if you're writing a HailStorm service, that service must expose in order to have uniform query across all the different services, to have uniform data manipulation. So if I want to add a chunk of XML to a service, I don't have to learn a new way [to do it] for Calendar versus an Address Book. It's the same add method. The data might be different. The schema for that particular service might be different, but the programming model and the service fabric and the glue that holds it all together is uniform.

anyone? surely one of you dinosaurs will tell me that Iona invented it, or it was an MPI term or some shit like that...
:-)

Top 10 Reasons Why the UBR Sucks...

I thought I'd do a top ten list on the UBR - but first, I am reaching out to you... send me your thoughts on why the UBR sucks (or doesn't)... jschneider @ momentumsoftware.com

10.
9.
8.
7.
6.
5.
4.
3.
2.
1.

I'll publish the results in a couple of weeks.

Netscape 7.1 - So far, so good

About three years ago, I switched from Netscape to MS IE. I felt guilty when I did this. To rid my guilt, I have been downloading Netscape about every 6 months waiting for a version that 'works'. Well, I have to admit that Netscape 7.1 might just be the version I've been waiting for...

http://channels.netscape.com/ns/browsers/download.jsp

Saturday, October 18, 2003

Services Oriented Enterprise

Sonic has dropped a reprint from "Enterprise Architect" at their site, titled "Services Oriented Enterprise".

Basically it says that the SOE is coming. More exciting, David Chappell got a nice picture of himself posing over a marketing piece showing JMS hooking up to parnters in a bus topology.

COMPLETELY UNRELATED.... here are some pictures of crashed buses:

ROTFL - jeff.

Iona to release web services product on Monday

Although web services are still an emerging technology and part of a long-term investment program; Iona has stated that its new product "Artix" is part of a "get back to profitability" program:

http://zdnet.com.com/2100-1104_2-5093213.html

If I remember the BCG product portfolio matrix correctly, the Cash Cow is supposed to sustain your profitability. The Rising Star is supposed to bring new profits...

This poses a common dilemma - what to do when your Cash Cow runs out of milk and your Rising Star is still in early adopter stage.

Friday, October 17, 2003

Gartner has nice clipart

I just previewed the new Gartner presentation on, "The Business of Web Services: Models and Opportunities" by Whit Andrews.

Despite the amazing lack of substance, Whit managed to find some real nice clipart. However, I am now of the opinion that the clipart drove the message of his presentation. If you are looking for substance on web services, you will likely need to go somewhere else, however, if you are looking for clipart, Gartner is the place to be!

Keep up the fine work. :-)

Tuesday, October 14, 2003

Market Yawns at WebMethods

If three acquisitions in the same day won't move the stock, what will?

Monday, October 13, 2003

The Mind Electric is Acquired

See:
http://news.com.com/2100-1012_3-5090102.html?tag=nefd_top

Sunday, October 12, 2003

Offshoring and Wiping Baby Boomers Bedridden Asses

I finally broke down and read the McKinsey report on offshoring. This is the report that everyone references when they don't know the facts about the effects of offshoring on the U.S. economy, the U.S. corporation or the U.S. citizen. Instead, people just say stuff like... "well, offshoring is natural. Didn't you read the McKinsey report? It actually benefits everyone!" Normally you need an MBA to make such an asinine statement. I can say, "Yes, I read the report"

Now, I'd like to hold a made-up, virtual conversation between Senator Adam Smith and myself:

Jeff responds, "Yes, I did read the McKinsey report. Well... as I'm sure you know, it isn't actually a "report" - it is a 'perspective' that was published preceding the release of any factual data. Senator, the thing that got me was that McKinsey decided to have a person from India write the report. Now, I'm sure that the author Vivek Agrawal didn't have any conflicts of interest - nor did McKinsey - even though their entire customer base is mostly globalized corporations that get short-term benefits from laying off American workers and replacing them with cheap offshore labor. But, I’m sure that when they put out their final report it will be under FULL DISCLOSURE.

The report was a good read. I really liked the part where they referred to laid off workers as being, "freed up to take other jobs" - holy shit, Senator - that Vivek really has a way with words!

Senator Smith comments back..."Come on Jeff. You're being critical. What Vivek was saying is that by reducing labor costs we are able to produce goods at a lower cost. This will have an immediate positive margin effect on the business owner and investor, allowing them to reinvest, which would lead to hiring new workers."

Jeff comments, "Come on Senator, new jobs? Doing what? These people can't fight the Asian pay scales. They're screwed. "

Senator Smith quips, "Now Jeff, they're not screwed. You saw the report. America is aging. The baby boomers will be retiring soon. This will deplete the workforce and create a new burden to take care of the elderly."

"So what you're saying is that for the sake of corporate profits, American lawmakers will tell well educated software professionals to move into health care? Sir, with all due respect, many of these guys have masters degrees in computer science, 10 years of experience and more importantly - THIS IS WHAT THEY LOVE DOING". You can't just tell them to start wiping baby boomers bed ridden asses as a new career, can you?"

Now Senator Smith is agitated. "You know I'm not recommending all software people start wiping asses for a living. I'm just saying that in order to remain competitive, we do.... well, what we have to. And you saw the McKinsey recommendation. They recommend that we offer a new insurance to those that groups most affected by offshoring. Thus, the employee will get 70% any difference in wage losses."

Jeff smiles. "Great, now I get to wipe asses and get sympathy insurance.... and I'm still not making as much as I used to. This makes me feel great!! But wait... if the employer gets stuck picking up the tab for ‘offshore insurance’ of 'freed-up workers' and the 'freed up' worker can't get a job then won't this lead to higher insurance premiums. And won't those premiums negate most of the benefits of going offshore in the first place?"

Senator - "Yes! Now you're getting it. The insurance package will have a payment system that penalizes corporations for laying off workers when the talent pool is high. Thus, if a corporation is only laying off people because they want cheap labor and there are lots of 'freed-up' American workers, then they should have to pay higher premiums."

"But Senator, when the economy is poor we usually see two things, 1. people getting laid off and 2. corporations trying to figure out how to make a margin. What you are telling me is that when corporations really need to squeeze out margins they won't be able to move work offshore because it will be cost prohibitive due to insurance premiums. That doesn't make sense.

On that note, why would I hire American workers at all - knowing that I'm going to get stuck paying for offshore insurance? So, let's say that I start a new company with some of that money I saved by laying off my American employees. Now, why would I hire Americans? Not only are they more expensive, but now they have a offshore tax that is associated with them."

Senator, "Well, Jeff... maybe you wouldn't. Maybe you'd just go offshore and take the higher margins the whole way. Then again, maybe you would hire locally because the job was better suited for proximity-based labor," commented the Senator.

Jeff sighs. "Gee Senator - I sure wish that I could believe the McKinsey report. I wish I could believe you. But for some reason, it just doesn't make sense. It is rare to find occasion where it is a true 'win-win' - I've found that usually one party wins, the other party wins, or it is a zero-sum-gain. I clearly see how the Indian government wins. I clearly see how the Indian corporation wins. I clearly see how the Indian employee wins. Conversely, I clearly see how the American employee (ass wiper) loses. What is less clear is the fate of the U.S. government and the U.S. corporation. I could see where the U.S. corporation could take short-term gains by 'freeing-up' labor. But 'freed-up labor' makes less money, has less purchasing power and ultimately buys less from those same corporations - which means that the U.S. government is collecting less sales and income tax. Senator, if I could make one suggestion?"

"Sure Jeff, what is it?", says the Senator.

"Senator, read the McKinsey report. I mean actually study it. Keep track of who wins and who loses (US government versus offshore government), (short term versus long term), (employee versus employer). My gut tells me that you're not going to like the outcome of your matrix. McKinsey has a great reputation - but I got a feeling that this one could end up being a real embarrassment for them. "

"Jeff, that sounds like solid advice. Can I get you another glass of wine... I think it's French!"

Saturday, October 11, 2003

Microsoft just gets it...

Microsoft just plain gets it. They understand web services and they understand developer needs.

Take a look at this screen shot from the MS WSE documentation. One nice set of docs around all the WS-* specs. It is a thing of beauty...

Friday, October 10, 2003

Public SOAP Router

I pistol-whipped one of my consultants into putting up a public SOAP router. It is the WSE 2.0 impl. If anyone wants to donate another impl, I'll gladly put that up as well.

For now, there is no dynamic routing algorithm.. just a static routing table. We are going to use 'to' fields in WS-Addressing as the final destination (for now).

We are also hoping to put up an unreliable-router soon (to test WS-ReliableMessaging, along with a static WSRM Policy Assertion).

This is super-duper beta kind of stuff. Send me an email if you are interested in testing out the public router: jschneider@momentumsoftware.com

We are building an HTML front-end so that you can add your own entries but this isn't out yet. Til then, you'll have to email us your endpoint information.

[[try to use 'pistol-whip' in a casual sentence when talking to friends - it will likely bring a smile to your face!]] LOL

Microsoft & Amazon link up via web services

By integrating Amazon Web Services, Amazon.com Research Services for Microsoft Office System will provide Microsoft Office System users with access to Amazon.com from within Microsoft productivity applications via the Research Task Pane. Users can access Amazon.com information and make purchases without launching a browser or leaving a document, email message, or presentation. For example, a customer reading a bibliography in a Word document could click on a book title and purchase it from within the Research Task Pane without leaving the Word document. Alternatively, a user will be able to add a footnote, bibliography entry and cover art for books without manually entering the information into a document.

See: http://www.econtentmag.com/Articles/ArticleReader.aspx?ArticleID=5611

Thursday, October 09, 2003

Logical Services

In web service composition (service piping, orchestration, etc.) you have the ability to make one service front-end multiple services. In BPEL, every orchestration is exposed as a web service despite the fact that it potentially encapsulates *many* web service calls.

I've blogged in the past about how the granularity of the service shouldn't matter. Granularity should be adjusted on the fly (when possible). I've blogged about *cheats* - that is, in-process calls that never actually used the network services (TCP & HTTP) - or even web service calls that were too lazy to use XML Schema - they realized that they were running in the same JVM or CLR and just used shared memory. These concepts are related to my vision of SODA (a concept popularized by Darryl Plummer at Gartner) or Service Oriented Development of Applications. The fact is that SODA doesn't work unless you cheat. You must have both static and dynamic optimizations of service-to-service calls.

When you do this you begin to realize that the piece of code that you called your 'service' was aggregated with another piece of code also called a 'service'. After a while, you realize that all of your services were really just logical things that could have their boundaries redrawn.

Web services are logical - hell, software is logical. The interfaces, the boundaries, the messages between them - all logical. Thus, the ability to recombine them in new ways is not only possible and practical, but perhaps inevitable. Future SODA tools will have the ability to *compile* multiple services together into single service.

Now, what does *compile* mean? Hmm... interesting question. Well, it could mean actually compiling. Or it could mean orchestrating. Or perhaps, just redelivering the service to a runtime container that knew how to *cheat*. Any way you look at it, the art of SODA will be about the ability to combine services in a variety ways. It should protect the black-boxed nature of the service while still giving the developer all of the functionality and performance of a compiled application.

SODA is the evolution of programming; when should an object be a component? When should a component be a service? If you answered these questions based on interface granularity then you don't understand SODA.

Stencil Group Changes Mission: Conspiracy Theorists

Ok. Just kidding of course. The Stencil Group does great work - however, I really, really don't understand the conspiracy piece that Bill Robins wrote about at news.com.

Why would IBM and MS share the stage to promote web services? The answer is simple. They need to create a compelling reason for their customers to buy the next generation of software suites. The major advancement in the suites is web services - and yes again, interoperability is required. IBM and MS must do more sessions with top people demonstrating this in order for them to convince the customer base of the primary value proposition.

One more time...
A compelling reason to buy.
Microsoft makes decisions based on making money... selling products... providing value; it is real simple.

Tuesday, October 07, 2003

Becky Dias at MS is blogging

I just found the blog for Becky Dias, the WSE product manager at Microsoft.
Check out: http://blogs.gotdotnet.com/rdias/

Monday, October 06, 2003

Interwoven release SOA version

See:
http://www.interwoven.com/news/press/2003/0721sdk.html

Wednesday, October 01, 2003

Cape Clear has a nice WSDL editor...

So I needed to hack up a quick wsdl - so I sucked down the free one from Cape Clear.
It rocks. However, I didn't fully understand this:

Tuesday, September 30, 2003

Web Services Enterprise Edition

What is the standard .wsdl for a workflow engine to expose its state?

What is the standard .wsdl to expose a message queue? What about a pub/sub topic?

What is the standard .wsdl to expose LDAP?

What is the standard .wsdl to expose POP? SMTP? FTP?

You know, it's great to have one-off wsdl's over at xMethods. But at some point we are going to have to pull together a 'library' (or profile) of wsdl's to expose the technology architecture. The library should be consistent in style. After we finish it we should throw it away - because it will be wrong. Then we should start over.

The end of BPM-1, the beginning of BPM-2

I dropped a few comments on BPM-2 at 'Loosely Coupled'. I'll try to elaborate on this article in the coming days.

Also, I seem to be losing the battle to change the name of an ESB to something that makes sense. So, if you can't beat'em join'em. Message oriented services with durable load tempering devices is a solid concept. It's still a stupid name - but I'll get over it.

EAI vendor revenues continue to topple

Wow... if this is our bull, I'd hate to see the bear!

Saturday, September 27, 2003

7 Things Great Software Architects Have

1. Friends that are also great architects
2. Loyal associates that are great designers and programmers that will work with them no matter what the project is
3. Extensive experience on at least 3 platforms (mainframe, J2EE, .net, CORBA, TOGAF, etc.)
4. A bookshelf that is about to topple over and a mechanism for demoting bad books
5. 3 or more candidate architectures or software architecture documents (SAD's) on your hard drive
6. Your personal ontology of non-functional requirements
7. 'Success Patterns' - things you know which have worked on previous engagements

Thursday, September 25, 2003

Lou Dobbs - Exporting America

WOW - I just watched Lou Dobbs. He is running a special series called, "Exporting America". He is spot lighting the overwhelming move of American jobs to low wage countries like India and China. Lou is one of only a small handful of people that have had the balls to stand up and fight for the American I.T. worker and the current unfair trade policies that exist.

Tonight, he had Adam Smith, congressman from Washington on the show. Adam has initiated a study with the GAO to look into the effect of the multi-national corporations decision to fire American workers and hire cheap offshore labor.

What was extremely disturbing was that Adam Smith seemed to already have his mind made up. He commented that he didn't have any issues with the H1B program, and thought that there *might* be some issues with the L1B program. Adam Smith are you nuts? The American I.T. worker has taken it up the ass.

Last week my company had some job openings and I did the interviewing. I had three candidates in a row all come in who were on an L1B program, hadn't had a job in months, continued to stay in America and were commenting that they would work for "whatever I wanted to pay". I asked them who sponsored their visa and they all told me names of different Indian based 'body shops'. Naturally, I asked if the shops that brought them in employed them. They then explained to me that the Indian shop provided them a plane ticket. In exchange for the ticket, the individual would have to pay the sponsor 20% of all of their wages while in the U.S. It was the individuals responsibility to go and get a 'real employer'. In essence, they were indentured servants to the company that bought their ticket. Adam Smith this is reality. Don't believe me? Get an employers account on Monster.com, do a search for "Java" - you pick the city, call the first ten results and ask the individuals their situation. I dare you.

Here is the contact page for Adam Smith:
http://www.house.gov/adamsmith/contact/contact.html#
Take the time and fill out the form. Please.

Wednesday, September 24, 2003

The 2-pin theory.

Sean McGrath wrote a thought provoking piece.

I caught myself responding on one of the news groups & thought I'd share...
===================================

Wow - nice piece from Sean. Thought provoking.

Is the *magic* of the interface related to the *2-pin* theory (i.e., do(x)) or it related to advancements in protocol negotiation? Does USB work better because of the number of pins or because of the structured negotiation between participating components? What about BlueTooth?

WS-* is moving into a world where dynamic protocol negotiation for non-functional requirements will be able to happen on the fly.

An example of two web services talking to each other (think consumer:producer) :
Service 1: Can you do encrypted?
Service 2: Yes, I do TripleDES, Do you?
Service 1: Yes, let's do it!
Service 1: Do you do Reliable Messaging?
Service 2: No, not for this operation.
Service 1: Can you treat this operatin as part of a transaction?
Service 2: No, I can't, but I do have a compensating mechanism, see URI:xxx.wsdl
Service 1. Great, I'm going to use it.

Now, an interesting question is how did databases servers get away with a small number of interfaces / operations? The answer is that they created languages which could be shipped across a wire to perform more complex functionality. Thus, the database has the notion of the do(x) - or if you'd like, you could say that it had:
do(DDL)
do(ANSI SQL 92)
do(stored procedure), etc.

Back to the conversation:
Service 1: Now, it is time for us to do some real work, I need some data, do you support XQuery 2.0?
Service 2: Of course! Send your query on over!
Service 1: Ok, here it is: (query blah, blah, blah)
Service 2: Great! Here is your result (some data, ....)

Now, of course, you wouldn't want the conversation to be anywhere near this verbose... but you get the idea. Simplicity in interface doesn't just happen by creating a magic "do(x)" - you have to actually have some meat behind the operation. Web service protocol designers are attacking both of these fronts (NFR protocol negotiation and ubiquitous, shippable languages like XQuery).

IMHO, looking for simplified interfaces is good - just be careful not to throw away your meta-data just to make a clean WSDL.
Jeff

Saturday, September 20, 2003

WSDL of the Day?

If Don Box can do a Win32 API of the Day... surely I could do a 'WSDL of the Day' !

Hmmm... sounds like a lot of work. Anyone want to help? (If not, it will likely turn into WSDL of the Month :-)

Friday, September 19, 2003

OASIS to look at EVERYTHING

I just stopped by the OASIS Messaging and Coordination page and got a good laugh. It appears that Karl Best and friends have decided to take on a few more specs. So, in addition to BPEL, we have:

Business Transaction Protocol (BTP)
OASIS Asynchronous Service Access Protocol TC
OASIS Web Services Composite Application Framework (WS-CAF) Technical Committee
W3C Web Services Choreography Working Group
Web Service Choreography Interface (WSCI)
Web Service Composite Applications Framework (WS-CAF)
Web Service Context (WS-CTX)
Web Service Coordination Framework (WS-CF)
Web Services Transaction Management (WS-TXM)
Web Services Choreography Description Language (WS-CDL)
Web Services Conversation Language (WSCL)
Web Services Transaction Framework
Web Services Atomic Transaction (WS-AtomicTransaction) [replaces WS-Transaction-V1, Part I]
Web Services Coordination (WS-Coordination) [Version 2]
Web Services Business Activity (WS-BusinessActivity) [to replace WS-Transaction-V1, Part II]
Web Services Transaction (WS-Transaction) [Version 1]
Web Services Coordination (WS-Coordination) [Version 1]
WS Choreography

A Bounty
Ok, enough is enough. Can we put out a bounty to be paid to anyone that manages to kill a working group? Honestly, I will kick in my fair share. For starters, let's whack WS-Choreography - I'll pay $500 USD to the person that disassembles this working group. Surely there are others that will kick in too... My fear is that as quick as we knock them down, the fine folks at Oracle, Sun and Iona will create new ones to replace the old ones. Hence, I propose that we find the professional spec writers at the aforementioned companies new jobs. Got a startup? Offer one of these guys a job! Not because you need them... because you'll have to spend less on marketing to educate the world on why your product doesn't support some bullshit specification that these people made up. In the end... it will all pay off
:-)

Tuesday, September 16, 2003

OASIS to look at Methodology

Name of the TC: OASIS Framework for Web Services Implementation (FWSI)
Technical Committee

Statement of Purpose

The purpose of OASIS FWSI TC is to facilitate implementation of robust
Web Services by defining a practical and extensible methodology
consisting of implementation processes and common functional elements
that practitioners can adopt to create high quality Web Services systems
without re-inventing them for each implementation.

It solves the problem of the slow adoption of Web Services because of
lack of methodologies to implement Web Services, and a lack of
understanding of whether solutions proposed by vendors have the
necessary components to reliably implement an application based on Web
Services.

Monday, September 15, 2003

Model Driven Services

The model for creating business software has leveraged the concept of utilizing a base engine (or server) and extending its functionality with specialized models, templates or other consumable metadata. In J2EE, we use a JSP template engine to consume JSP's, we use an EJB container to consume EJB's, etc. Typically we then chain together engines (JSP engines + EJB engine + DB engine) to fulfill some use case.

Many of the web services that I have created were "home grown", that is to say that they were written from scratch and didn't leverage any engine. The more I looked around, the more I realized that others (including vendors) seemed to be caught in the same boat. Moving web services into the (model + engine) world is obvious.

I found myself asking how come we haven't seen more model driven services? I think one reason is that many developers are too concerned about the SOA triangle (producer, consumer, directory). The SOA triangle is an architectural pattern that will be used over and over again inside of service-based applications. However, it isn't the end. Extending the triangle, or leveraging other patterns is absolutely necessary.

So, here are some interesting questions to ponder....
1. To what extent does one attempt to standardize authoring environment interfaces?
2. Does an authoring environment service provide a default UI customizer that is shippable (JNLP style)?
3. Should the customizers (models, meta data, etc.) be logically held together at the use-case / scenario level?

Sunday, September 14, 2003

IBM, Batty, Autonomic Computing

I've been blogging how IBM is Batty on a few subjects... most recently on web services, grid (OGSA), model driven architecture (MDA)... and now autonomic computing.
See:
http://www.research.ibm.com/autonomic/

The convergence of the aforementioned technologies could create one interesting model!

From UML to BPEL

Keith Mantell at IBM wrote an article on using UML and MDA concepts to gen your bpel. See:
http://www-106.ibm.com/developerworks/webservices/library/ws-uml2bpel/

He creates a UML profile that has the semantics to represent bpel and then discusses making a map from the model to the bpel code. The base process is represented as a class and the orchestration is modeled as an Activity Diagram.

All in all, it is an interesting concept. One concern that I have is that people don't try too hard to shove a square peg (UML) into a triangular hole (SOA & BPEL). The base UML models were developed some time back and don't always represent the concepts that we need. For instance, I use a Service-Based Sequence Diagram rather than Activity Diagrams to represent orchestrations... just seems easier.

Wednesday, September 03, 2003

Web service testing ... no fun

Anyone that has had to serious testing of web services knows that it is no fun - just noticed that Optimyz has put out version 2.0 of their tool:
http://www.optimyz.com/product_overview.html

and not to forget the fine folks at Mindreef who have released version 2.0 as well:
http://sdtimes.com/news/085/story13.htm

Web Services Enable New Front Ends

I've seen a couple of these now... new portals that use web services to collect information from a variety of sources:

http://www.anacubis.com/amazondemo/

Although still early, I anticipate many sites to begin incorporating cross-site, cross-database integration.

Monday, September 01, 2003

StrikeIron Web Services Analyzer

I've been playing with a tool to invoke web services from StrikeIron. Overall, I think they did a pretty good job!

One thing I like is how they are displaying the results in a grid-format, rather than having you traverse a tree. One thing I don't like is that you can't abend run-away queries.

Friday, August 29, 2003

Offshore Backlash

You know that an offshore backlash is in effect when 'The Economist' publishes pictures of 'Casual Friday' at an offshore company like this:

More confusion on course / fine grained at Syscon

STOP THE MADNESS!!

Yet another article has come out saying that we should write our web services using course grain interfaces. Authors, please stop writing this nonsense.

The course/fine grain issue does not have a 1:1 relationship with web services.
The course/fine grain trade-off is often related to distributed computing, but even that is incomplete.
The course/fine grain trade-off is an issue of latency and usability.

A web service that implements fine grained interfaces and is meant for local invocation is PERFECTLY FINE.
A web service that implements fine grained interfaces and is meant for distributed invocation and is on a low-latency network is also PERFECTLY FINE.

I really wish that Doug Kaye would get on the bandwagon and speak out on this issue - many, many people have misunderstood his book. I do like the SO design guidelines Mr. McDowall has going, note that he doesn't mention asynchronous or course grained (thank God).

Now that both the Microsoft WSE and WebSphere 5.02 both support local in-proc web service calls without hitting the socket or marshalling the data to an XML format, we need people to QUIT saying that web services should be designed with course grained interfaces - it is wrong. Design web services using a course grained interface when you know that there is a latency issue - or when it just plain makes it easier (usability) on the end developer (and has no side effect).

See:
http://sys-con.com/webservices/article.cfm?id=641

Thursday, August 28, 2003

Stuck in Java Land

I just caught the thread in "The Server Side" where the 50+ people all tried to say that Don Box was full of crap for commenting that SOA will eclipse OO as a programming model, see:

http://www.theserverside.com/home/thread.jsp?thread_id=21132&article_count=39

Well, this seems to be the typical response that Java dudes have to web services and SOA. Now, if it was Bill Joy or James Gosling that made the comment these guys may have taken it seriously. So, BEA is on the SOA bandwagon - they seem to get it (thank Adam?), IBM gets it... but doesn't really have the evangelism going. I look forward to the day when the masses 'get it' and quit dogging on thought leaders like Box.

Monday, August 25, 2003

Sun sees BPM, just doesn't know what the acronym is...

Sure, 99.9999% of the world believes that BPM stands for Business Process Management, but to SUN it stands for Business Process Machines - good going. Alright, it is no secret that I think that Sun has screwed up their chance to dominate enterprise computing architectures in the coming years. By fighting the web services trend and running after Java-only platforms and CBD style programming, they gave IBM and Microsoft the keys to the kingdom.

In an attempt to get back in the game, Sun is pursuing a strategy called JBI or Java Business Integration. This venture acknowledges that Java needs more than API's for calling web services, thus the JAX solutions are merely bridges between old and new environments (Java CBD and SOA). JBI, however, is a restating of the problem. It acknolwedges that first order concerns in architectural design are interoperability and integrate-ability.

In their words,
JBI is intended to support the full range of integration solutions,including simple,synchronous point-to-point EAI or more complex B2B business process automation incorporating long-running transactions and complex workflows. However, it is especially well suited for business process automation problems, with the goal of enabling much simpler development of solutions that today are complex and time consuming to implement. Examples of the solutions JBI will facilitate include:
•Self-service customer portals
•Enterprise employee portals
•Customer relationship management (CRM)integration
•Supply chain integration
•EDI replacement

And what will the approach look like?
JBI will support an RPC-oriented Web services programming model as well as a message-oriented Web services programming model,in particular,the constructs of:
•Components as services with interfaces that are publicly and explicitly described by standard metadata,for example,the Web Services Description Language (WSDL)
•Document-centric processing where component services act on standard,structured XML documents that contain both business data and metadata,which provides context for service execution
•Asynchronous communication between components with support for long-running transactions

And the scope is?
The current scope of the JBI architecture standard, as described in the approved JSR 208 proposal, is not to specify how components are themselves implemented. Instead, it only specifies the interfaces they must support for plugging into the JBI environment to use its services and interact with one another to request and deliver services. Thus,JBI is at least initially about system programming interfaces (SPIs)and not about application programming interfaces (APIs), and therefore pertains more directly to those who build integration servers and tools than to those who build solutions with them.

You know, I really like this idea. However, I have this bad feeling that Sun will screw it up. They will likely continue to treat their language (Java) and platform (J2EE) as their primary concerns and treat JBI as an add-on (rather than the other way around). Sun will have to throw away their notion that everything is either an API or is Java P-code and move towards protocols and language neutral interfaces. Lastly, they will have to quit fighting IBM on EVERYTHING. If IBM & Microsoft agree on a new specification, just go along - and win with the implementation. They must stop trying to win the ego battle. Perhaps a tough job for a company run by McNealy.

For more on JBI, see: http://www.webservices.org/papers/JBIwp70903.fm.pdf

Sunday, August 24, 2003

Microsoft Changes Group Name

The group that housed the MS web services team was known as GXA (Global XML Architecture). They are now called WSA (Web Services Architecture).

Also of interest is that MS has taken WS-Routing off the list of WS standards they support. This should mark the official death of it, with WS-Addressing superceding it:
http://msdn.microsoft.com/webservices/understanding/specs/default.aspx

IBM is batty over OGSA

From what I can tell, three major themes are coming out of the IBM software group:
1. Model Driven Architecture (a byproduct of purchasing Rational)
2. Web Services (a byproduct of being in bed with Microsoft)
3. OGSA (a byproduct of wanting to beat Microsoft)

The OGSA is an interesting beast and at the heart of it you will find web services:

For more information on OGSA, check out:
http://www-106.ibm.com/developerworks/webservices/library/gr-visual/

One thing I didn't really get was why they have OGSI services laying on top of web services, and their explanation didn't help:

Let's look more closely at the two main logical components of OGSA -- the Web services-plus-OGSI layer, and the OGSA architected services layer. See Figure 2. Why are they separated like this? The GGF OGSA working group believed it was necessary to augment core Web services functionality to address grid services requirements. OGSI extends Web services by introducing interfaces and conventions in two main areas.

First, there's the dynamic and potentially transient nature of services in a grid. In a grid, particular service instances may come and go as work is dispatched, as resources are configured and provisioned, and as system state changes. Therefore, grid services need interfaces to manage their creation, destruction, and life cycle management.

Second, there's state. Grid services can have attributes and data associated with them. This is similar in concept to the traditional structure of objects in object-oriented programming. Objects have behavior and data. Likewise, Web services needed to be extended to support state data associated with grid services.

IMHO, the ws layer should front end all of the service - both of the aforementioned issues seem resolvable. Perhaps the IBM boys will set them straight...