|
|
| Service Oriented Enterprise |
|
|
Friday, April 30, 2004 RESTifarian Evaluation Per my earlier note, I have evaluated my feelings on the units of REST: 1. An architecture is defined by its constraints - Strongly Support 2. Separate client from server - Strongly Support 3. The client / server relationship must remain stateless - Support 4. The client must be able to cache data - Support 5. Uniform Interface - Support 5.1 Identification of Resources - Strongly Support 5.2 Manipulation of Resources through Representations - Strongly Support 5.3 Self Descriptive Messages - Strongly Support 5.4 Hypermedia as the engine of application state - Support 6. Layered System - Support 7. Code on Demand - Don't Support REST is a single candidate architecture. And an architecture must be evaluated on the whole, rather than the individual parts. Fielding does a great job of stating that every decision in the candidate architecture has trade-offs. He further identifies the applicability of the architecture (distributed systems, system 'feels' stateless, desire to scale, desire to evolve, etc.) Like all candidate architectures, one can only evaluate the architecture against a problem that you are trying to solve. REST by itself can not be evaluated, only evaluated as a candidate solution to a pre-identified problem. What was interesting to me was the lack of association between REST and HTTP, or more precisely the 'verbs' of HTTP. Instead, Fielding places significant attention on the need to use Resources (think URI), Self Descriptive Messages (think XML), but does imply that a generic interface is required. Somehow... I find myself agreeing with Fielding but disagreeing with many RESTifarians (I'm not sure how this is possible). Fielding suggests a "a uniform interface between components ", however he never mandates what that interface should be - only stating the characteristics. However, I find significant 'folklore' stating that the interface is, "...defined completely and solely by the specified semantics of HTTP, i.e. GET / PUT / POST, etc." (Jeff Bone) He continues to argue, "*there are no applications you can think of which cannot be made to fit into the GET / PUT / POST / resources / representations model of the world!*" The only issue I have is his term "made to fit" - meaning, what was the price of 'making something fit'? So, with all of this said, where am I landing? 1. REST is a great example of a candidate architecture and should be evaluated based on the problem at hand. 2. REST doesn't dictate HTTP or the HTTP verbs and this is a good thing. 3. REST does state that the interface should be uniform, and this too is a good thing. 4. The base HTTP application semantics can be 'forced' to solve any problem, they just aren't always a good fit. 5. Additional exercises should be performed to document how many RPC style verbs would be translated into a more REST-stlye. Verbs that don't translate shouldn't be forced to fit, rather new verbs should be introduces as part of the first-order vocabulary. posted by jeff | 4:24 AM Thursday, April 29, 2004 Tim Bray on things Tim is now at Sun :-) and has new things to say. 1. He doesn't like composable message architectures. He doesn't like describing the resolution to non-functional requirements of distributed computing via specifications because it is hard. In my opinion, you either specify your separation of concerns with specifications or make them proprietary. I lean towards specifications. Also, the solution will utilize a building block approach or a big-bang approach. Your call. I prefer building block. 2. He doesn't like automated service discovery (UDDI). I think he misunderstood what UDDI was all about. That's ok, many people do - it is a design time service, not a run time. Throw away the "automated" part and you're a lot closer. 3. He doesn't like declarative application building. He mentions BPEL and ws-chor as examples of this - unfortunately neither of them are valid examples. Actually, I kind of wish they were! Declarative approaches for state based decision making and distributed invocation has a real place in software development. 4. He doesn't like leaky abstractions. Me either, but unfortunately he doesn't give an example. 5. He's concerned about the standards process. Perhaps the new Sun employee should take a look at the JSR process :-) 6. He's concerned that we aren't making it simple enough. Here he has a decent point - it is complicated. Could it be simplified? Sure, throw away functionality and we can simplify it. Keep in things like reliable messaging, self-contained enveloping, trust, authentication, multiple levels of transactions, etc... yea, you can make it as simple as you'd like! Welcome to web services :-) posted by jeff | 6:24 PM RESTifarian? Mark Baker declared that I was on the way to enlightenment (AKA, seeing things his way). You know, I'm not sure if I am a RESTifarian. When I first saw this: http://www.extremeprogramming.org/rules.html I used it as a tool to determine what components of XP I believed in. It is tough to say, "Yea, I am an XP guy or Yea, I'm a RESTifarian". I've looked at some of the REST wiki's out there and I haven't found the simple list of rules and guidelines. What I'd like to be able to do is say, "I support RESTifarian rules/practices 3, 5, 9, 11 and 14." Perhaps if one of the REST supporters would give me the discrete rules for REST, I could more clearly state my opinion. ------- Side note: The XP guys did a great job. For the record, I'm not an XP'er. I've worked too many huge projects. Here is my stance: Planning User stories are written. - Support Release planning creates the schedule.- Unsure Make frequent small releases. - Strongly Support The Project Velocity is measured. - Unsure The project is divided into iterations. - Strongly Support Iteration planning starts each iteration. - Strongly Support Move people around. - Support A stand-up meeting starts each day. - Partially Support Fix XP when it breaks. - Strongly Support Design Simplicity. - Don't Support Choose a system metaphor. - Don't Support Use CRC cards for design sessions. - Support for OO systems Create spike solutions to reduce risk. - Strongly Support No functionality is added early. - Don't Support Refactor whenever and wherever possible. - Partially Support Code The customer is always available. - Unrealistic - Don't Support Code must be written to agreed standards. - Support Code the unit test first. - Partially Support All production code is pair programmed. - Don't Support Only one pair integrates code at a time. - Don't Support Integrate often. - Fully Support Use collective code ownership. - Partially Support Leave optimization till last. - Don't Support No overtime. - Don't Support Testing All code must have unit tests. - Partially Support All code must pass all unit tests before it can be released. - Support When a bug is found tests are created. - Support Acceptance tests are run often and the score is published. - Fully Support No, I'm not an XP'er. I think they had some great ideas - but no, I didn't just close my eyes and say all of them were good ideas and jump on board. Am I a RESTifarian? Give me the tools to evaluate and I'll let you know. posted by jeff | 7:24 AM Wednesday, April 28, 2004 Inserting Nouns into the Service Network For the last 6 months I've been investigating the separation of nouns and adjectives from the verbs and adverbs. For those that don't follow my blog on a regular basis, here is a quick summary: Nouns are people, places and things - in the software world they are our domain entities (User, Invoice, etc.) - and adjectives are the properties that describe the nouns. In the J-world we used Java classes to describe them - in the W-world we use XML schemas. Verbs are the actions. Actions have (at least) two forms: technical (insert, update, delete, publish, etc.) and domain or business specific (ship, pack, etc.). Technical verbs often act the same way on any given noun. Why is this important? Imagine walking into an enterprise with a set of nouns on a floppy disk. The company already has a service network in place. This ServiceNet is composed of 12 servers (portal, database, security, etc.) and runs 46 services. Each server has the capability of 'listening for new nouns' and a 'registration service' has the responsibility of: 1. Notifying the servers of newly registered nouns and 2. Notifying the servers of newly registered servers. Ok, we just moved into a world where the network is aware of the network. No magic, just simple registration. What gets interesting is when nouns have 'default implementations' of a verb on a server. And surprisingly, you will find that this is possible and beneficial. If I add a new noun to the ServiceNet will it likely have security permissions? Will it need to be stored? Will it be viewed? Should I role all of this code by hand? Again, the goal isn't to perform magic - it is to create a network programming model where we think more about how to create smart verbs and dumb nouns. The servers are slowly given the ability to interrogate each other and eventually a common set of functions is factored out of the servers and dropped into the network. I'm convinced that service oriented programming has the potential to get absolutely unmanageable. I talk with customers every day - they almost always start the conversation by bragging about the number of services that they have. Every time I hear this I think "Oh my God, what a maintenance nightmare! And they've only begun." In Schneider-land, the goal is to go for the smallest number of services, with the highest amount of reuse. Figuring out how to do this is a bitch. Going from Services to the ServiceNet The first step that I recommend is to take a look at all of the operations on all of your wsdls. Categorize what you already have (VerbOnly, VerbNoun, VerbMechanism, other). Then, determine if you could have made more re-usable services. What would they look like? Create a spreadsheet with the verbs as rows and the nouns as columns. The cells (or intersection points) are the realization of the VerbNoun. Beware of verb synonyms, or made up verbs (verbs that are really nouns). What is the smallest number of verbs you require to fulfill your needs? posted by jeff | 7:25 AM Monday, April 26, 2004 Custom Metadata I was just talking with one of my CTO buddies. He was bragging that implementing his software product at a client site requires no custom code. I paused for a moment and asked, "Does it require custom metadata?" To which he answered, "Yes, and it has a nice front-end to enter it in." My first thought was that he was just pushing the problem from one location to another. But for some reason, it does feel better pushing the problem from code to metadata, but I'm not entirely sure why. I like the idea of not compiling everything (a benefit of metadata). I also like the idea of having domain constraints on the data being entered (versus 3rd gen languages). I guess that a system that embraces MOF/MDA/metadata concepts requires less in-depth expertise. In essence, the expertise is built into the framework, enabling a 'paint-by-number' approach to recurring pattern based problem solving (resources require less training, thus less expensive). I'd love to hear what you think the advantages to a metadata driven approach are. Blog it. Link to this. Click through once. I'll repost referers. posted by jeff | 12:45 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
