Service Oriented Enterprise

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

posted by jeff | 1:46 PM

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.

posted by jeff | 7:50 PM

Compositions, Services & Fabric  

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

posted by jeff | 1:45 PM

Wednesday, December 17, 2003

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.

posted by jeff | 9:36 PM

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

posted by jeff | 8:37 AM

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.

posted by jeff | 10:14 AM