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