|
|
| Service Oriented Enterprise |
|
|
Tuesday, December 21, 2004 Encapsulation, Polymorphism, Inheritance Greg Vaughn, weighs-in on the "four tenets": "I mean no offense to those who are trying to nail down the fundamentals of what makes an architecture “service oriented”. For some it is a very handy way to organize their own knowledge. And there’s certainly a need to have laws for any developers on a project who have not reached the required maturity and experience levels, but in my opinion these should be more project specific rather than broad architectural category laws." Here is the problem. Greg is one of the smartest developers I've ever met. For him, the concepts of SOA are obvious. He's a top 1% guy. The problem is the other 99%. Remember, "Encapsulation, Polymorphism, Inheritance"? These were the basic ideas that the OO guys were trying to teach. They may not have hit the nail on the head but they did provide guidelines for developers. Laws or rules aren't childish. They are the nourishment that leads us out of child-like naiveness. posted by jeff | 7:43 AM Monday, December 20, 2004 Sun Launches the first pure “service oriented operating system” Sun Launches the first pure “service oriented operating system” PRESS RELEASE On January 1st of 2006, Sun Microsystems is scheduled to release the world’s first service oriented operating system called SunStorm. The operating systems will be released under an open sourced license agreement, free to the public. SunStorm is based around a new model of computing known as “web services”. Early versions of operating systems were primarily developed in structured programming languages like C and were often exposed to applications using ‘objects’. According to Sun, the internals of the operating system will continue to use these highly efficient techniques for things like disk operations and memory management, but the top layer of the system will now be completely service oriented. SunStorm also has incorporated most of the capabilities of their last generation computing platform known as “J2EE”. New web services are provided inside the operating system to provide messaging, management, database connectivity and other “enterprise grade” functions. When asked about potential performance concerns, Sun representatives showcased their dynamic web service optimization techniques. Similar in concept to the “HotSpot compiler” release years earlier, SunStorm has the ability to dynamically determine the most performant mechanism to enable services to interact and in certain cases to recompile themselves into a single service which is later cached or deleted. Sun is also rolling out their new tagline, “The Network is the Application”. This tagline replaces the old line of “The Network is the Computer”. With the launch of SunStorm, Sun is initiating a new era of loosely coupled, network computing for the enterprise. Interestingly, Sun has not decided to enter into the development market for this space. Having learned from earlier mistakes made in their iPlanet group, Sun is now focusing on building out the operating system and supporting it for their enterprise customers. New to the Sun organization will be an emphasis on professional services. Apparently, SunStorm has been years in the work only recently emerging from it’s stealth status. As part of this effort, Sun has end-of-lifed both it’s Jini and JXTA technologies. The J2EE technologies have been placed in a ‘mature’ status and will continue to be supported. ================================================================ This press release is 100% false. I completely made it up. However, it is really sad that it is 100% false. posted by jeff | 11:00 AM Sunday, December 19, 2004 The Four Tenets of SOA As we near this Christmas holiday, it seems only appropriate to throw the bible into my opponent's face :-) Consider the following: 'You shall love your neighbor as yourself.' - (can, shall, may, etc.) 'Don't bang your neighbor's wife' - (don't, shall not, etc.) Subtle difference? I don't think so. Imagine the first "rule" without the second "rule". Talk about a HUGE clarification! You see, leaving room for interpretation leads to problems. That's why the Four Tenets of SOA are utterly useless (even as philosophies). Don't do X; Don't do Y. Don't do Z. Simple isn't it? Constraints. Ok, hopefully I've established the difference between philosophy and constraints. That said, let's go back and take a look at the four tenets that Don Box provides us peons to guide our professional existence for the next decade: Boundaries are Explicit Point: Because each cross-boundary communication is potentially costly, service-orientation is based on a model of explicit message passing rather than implicit method invocation. Response: This is the "distribute OO was a failure" rule. Rather than saying A. Distributed OO was a failure because Microsoft screwed the CORBA guys and fragmented the space. B. Distributed OO was a failure because CORBA was a pain in the ass and it was competing in a rough market (BPR with 2-tier RAD and RAD groupware). C. Distributed objects was a failure because we didn't adequately factor out the non-functional concerns and network programming was in its infancy. No, rather than saying A,B or C - Microsoft says "Distributed objects failed because programmers were so stupid that they couldn't tell the difference between local and remote calls. Their solution was simple. Make remote calls a pain in the ass (oops, I mean ... make them non-primitives.) Yes, create some sort of language add-on (an API?) that mandates a mapping layer between the internal type system and the 'generic' type system - that'll teach those stupid programmers to realize when it's local and when it's remote! Oh, but let's also build runtime optimization of local service calls into the Indigo stack just to mess with them!!! Sweet. In case you're wondering, the constraint for 'boundaries are explicit' is this: "language designers and extension builders SHALL NOT create a programming extension or primitive that enables service calls to be or appear to be first order primitives." (This might be the rule, but I can't wait to break it!!!) The second part of 'boundaries are explicit' is: "The notion that boundaries are explicit applies not only to inter-service communication but also to inter-developer communication...." For the life of me, I can't find a rule, philosophy or anything actionable in this one. ================================================================== Services are Autonomous This is a case of bad terminology and description (I believe). If I understand Box correctly, his real intent was this line, "services are almost always deployed atomically". Whew... that was hard. Let's cut to the end and find the constraints: 1. Newly versioned services MUST BE deployed in a manner that DOES NOT negatively affect the prior version. The second part of 'services are autonomous' states: "Service-orientation encourages a model that increases ubiquity by reducing the complexity of service interactions." Here, Box takes jumps out of the versioning issue and lands in the 'loosely coupled' issue... although, in perhaps the most ambiguous manner possible. All I can offer is that if you want loose coupling to be a tenet, than you have to make an effort to create an index on loose coupling . Saying that 'leaking intentions is bad' doesn't quite do it for me. ================================================================== Services share schema and contract, not class Box states, "Rather, services interact based solely on schemas (for structures) and contracts (for behaviors)." Schema and contract only? Crap, we have to kill SOAP with Attachments and DIME ;-) I've stated before... I don't have a good answer for this one... the problems with this tenet are clear: sharing binary information, passing predicates, bypassing the schemas with optimizations and sharing instructions other than classes like DSL's and metalogic. ================================================================== Service compatibility is determined based on policy Again, I agree. Rule: Service consumer MUST be able to determine the capabilities of a provider via a publicly accessible, standard policy. ================================================================== Now, I know that Don Box didn't mean for these to be rules... just some high level philosophies. However, if you watch the MS video, you'll see the MS-band-of-jokers butcher his material. Back to my original point; we need simple rules or someone might accidentally misunderstand things like 'love your neighbor'. It's all about constraints. :-) posted by jeff | 3:43 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
