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.

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.

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?"

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":

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.

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

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

The Service Network

I've identified 100 services that could be considered part of an enterprise "Service Network". These services can be sub-divided into two categories:
A. Services that fulfill non-functional requirements (the ilities)
B. Services that are functional building blocks to modern applications.

The service network goes far beyond queues, routers and transforms. It serves as the foundation for creating a true service oriented enterprise. Some of the items will be found in 'service fabrics' others in a 'service bus', but most will not. Rather, most of the services will end up levaraging your fabric or bus.

I will contend that is the job of the architect to begin creating your enterprise wide service network - lay the fabric, plug in a bus... do what you must, but start your network. Implement a consistent foundation for the other services. Demand that your infrastructure vendor explain *how* these services come together in their offering. Know which are in scope - which are part of the vendors roadmap - and which are not. Set your expectations - create a plan - and get moving!

Common Services in a Service Network
1. Publish / Subscribe Service
2. Configuration Services
3. Broadcast Service
4. Page Controller Service
5. Syndication Service
6. E-mail Service
7. Relational Database Service
8. Object Database Service
9. Authentication Service
10. Access Control Service
11. Routing Service
12. Encryption Service
13. Hashing Service
14. Data Caching Service
15. Business Rules Engine Service
16. Business Object Service
17. OMF Service
18. Application Deployment Service
19. Version Control Service
20. Directory Lookup Service
21. Content-based Routing Service
22. Orchestration Service
23. Choreography Service
24. Queuing Service
25. Notification Service
26. Presence Detection Service
27. Protocol Translation Service
28. Tuple Service
29. System Monitoring Service
30. Legacy Adapter Service
31. License Management Service
32. Logging Service
33. Transformation Service
34. Job Scheduling Service
35. Peripheral Services (printer, etc.)
36. Language Translation Service
37. Presentation Service
38. Workflow Service
39. Gateway Service
40. Background Service
41. Network Browser Service
42. Indexing Service
43. Search Service
44. Collaborative Filtering Service
45. File Manipulation Service
46. Hardware management Service
47. QOS Management Service
48. Telephony Service
49. Installation Service
50. Policy Service
51. Provisioning Service
52. Fail-over Service
53. Clustering Service
54. Data Aggregation Service
55. Reporting Service
56. Formatting Service
57. Imaging Service
58. Faxing Service
59. OCR Service
60. Transaction Service
61. Benchmarking Service
62. Testing Service
63. Media Conversion Service
64. Compression Service
65. Parsing Service
66. Compiling Service
67. Speech Service
68. Portal Service
69. Single Sign-On Service
70. Instant Messaging Service
71. Concurrency Service
72. Parallel Execution Service
73. Streaming Service
74. Trust Service
75. 2D / 3D Rendering Service
76. Profiling Service
77. Session Management Service
78. Synchronization Service
79. Timer Service
80. Remote Publishing Service
81. Validation Service
82. Archival Service
83. Journaling Service
84. Naming Service
85. Life Cycle Service
86. Analytics Service
87. Debugging Service
88. Obfuscating Service
89. Sorting Service
90. Merging Service
91. Error Detection & Correction Service
92. Expression Evaluation Service
93. Leasing Service
94. Marshalling Service
95. Serialization Service
96. Filtering Service
97. Content Management Service
98. Web (HTML) Service
99. Terminal Service
100. Resource Manager Service

In addition, be aware that not all web service infrastructure vendors are service vendors. Many of them focus on the "Protocol Network". That is, the layer beneath the Service Network that provides functionality through protocol realization (SOAP, UDDI, WSDL, WS-*, protocol tooling, etc.) In many cases, these vendors also have service network offerings. It is good to understand where their offerings start and stop - and how they help enable consistency in the service network.

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

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.

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.

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

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