|
|
| Service Oriented Enterprise |
|
|
Saturday, March 20, 2004 The Service Network Today, there are largely three camps when it comes to web service architectures: The SOA guys, The Bus guys and The Protocol Network guys. The SOA guys The SOA guys were the original 'web service' people. They viewed the new paradigm as a ubiquitous service based system that would utilize the architectural pattern known as SOA (Producer, Consumer and Directory). The SOA guys are the people that build UDDI servers and SOAP platforms. They have taken the best of the CORBA world, learned some lessons and reapplied it to a new set of protocols that are accepted by MS and IBM. The SOA guys rarely mention a 'network topology', but their implicit topology is point-to-point (my consumer directly calls your producer). The Bus guys The Bus guys are the people who believe in messaging. Ultimately, messages and services go hand in hand. Some people put more emphasis on the service (SOA guys), while other put more emphasis on the message (Bus guys). The Bus guys also love asynchronous communication - thus, they loves queues or any other store and forward mechanism. Unfortunately, most of the Bus guys come from the JMS world and largely their stuff doesn't interoperate (think ESB). The Bus people usually think that the web services network topology is hub and spoke. The Protocol Network guys The Protocol Network guys are the people who treat web services more like networking protocols. These guys put emphasis on two things: wire protocols and policies. They see everything as a policy on a protocol. These guys love specs like ws-addressing, ws-discovery and ws-policy. The Service Network guys see the network topology as being adaptive based on the state of the network. They rely on routers, load balancers and other devices that have knowledge about the running services to make informed decisions on the fly. The reality of is that most large companies will need a hybrid of all three. They will embrace a standard SOA triangular pattern, but letting a Protocol Network make routing decisions at run-time, with the messages often ending up in queue. I continue to consult to my clients about the convergence of the three paradigms. This convergence is what I call the Service Network. The Service Network is a message-based, service-based and protocol-based computing model. - It leverages the SOA model to decouple producers and consumers and to provide lookup capabilities for self-describing services. - It leverages the Bus model to provide asynchronous communications for long-running processes. - It leverages the Protocol Network to provide runtime decision making about locating and executing a service on the network based on the service network conditions. Another way of looking at these models is: - SOA decouples software units (consumer and producer) - Bus decouples software in time (synchronous = time-coupling) - Protocol Network decouples software from hardware (run a service on some machine) The goal of the service network is to provide all three forms of decoupling. posted by jeff | 11:19 AM WhiteHorse and Virtualization (take 2) Alex Torone the Lead Program Manager for the Microsoft Visual Studio Enterprise Tools Team gave me a gentle kick in the balls regarding my inaccurate posting around WhiteHorse. Here are his clarifications: What the diagram really represents: The LSAD (Logical Systems Architecture Diagram) represents "logical run time hosting environments" (hence the name). Each box represents a "logical server type". Specifically, the large blue boxes represent a configuration of IIS, whereas the endpoints on the large blue boxes represents web sites. We model the entire IIS meta base (in this example). So a user could either supply "desired configuration" in the tool, or they could simply point to a "canonical server" that has the "desired configuration" and harvest those settings. Once the settings have been defined in the LSAD model, the user can then define constraints against the application environment. For example: Suppose my datacenter policy for "front end web servers" require web apps to use forms authentication and impersonation. These constraints will be validated against the application designer (we model all of system.web for example) and can be expressed in this logical design. There are also two additional layers in the SDM model (part of DSI refer to links below) which represents the network layer, and device layer that are more in line with your comments and are slated for a much later tools and platform release. About the Physical DataCenter: Data Centers host many types of applications. Network infrastructure diagrams (we've all seen them) have physical machines, IP address, Vlans, switches, routers, etc. The LSAD is meant to represent abstractions over the physical data center. We want to represent types of server not physical servers. One box on the LSAD does not necessarily equate to a physical server in the data center. In fact, you can create multiple Logical web servers and place then on one physical server with SQL as an example. When we get to actual deployment releases post Whidbey (please refer to the Dynamic Systems Imitative (DSI) links below), we will then provide a logical to physical mapping. This action will populate all of the deployment parameters with they physical URL's of the web server etc. In conclusion, the LSAD is about conveying that information which is important to the developer (such as what kinds of services are available to me, what communications pathways are open, what configuration must I adhere to, what are the boundary conditions that I must be aware of, etc) such that we will increase the probability that their design will actually work when it is physically deployed. The more I dig into the DSI, the more impressed I am. If they can pull it off with design-time integration it will be one heck of a story. Here are some links Alex provided me to reduce my ignorance: http://www.microsoft.com/windowsserversystem/dsi/default.mspx http://msdn.microsoft.com/vstudio/productinfo/enterprise/enterpriseroadmap/default.aspx?pull=/library/en-us/dnvsent/html/vsent_soadover.asp http://msdn.microsoft.com/vstudio/productinfo/enterprise/enterpriseroadmap/whitehorsefaq.aspx http://microsoft.sitestream.com/PDC2003/TLS/TLS345_files/Default.htm http://msdn.microsoft.com/msdntv/ posted by jeff | 6:45 AM Wednesday, March 17, 2004 Book Recommendations It is tough to find good books on subjects like web services. The people that write on the subjects are usually writing about the current state (which is outdated by the time you buy the book) or a future state (which is usually wrong). Generally speaking, I don't buy books on web services - however, I do buy books on areas of convergence. That said, here are my recommendations: 1. Policy Based Network Management - A book by John Strassner, a Fellow at Cisco and thought leader in DEN, writes on the topic of the declarative network. The book covers basic policy models and then explores the DEN-ng policy model as an example. The book will never mention SOAP, web services or anything at the application level. It is up to the reader to draw analogies between Network Policies and Application Policies. For those that are familiar with the WS-Policy specs, you will find significant overlap between WS-Policy and PBNM (Policy Based Network Management). This book should help you understand the importance of declarative policies and their uses in application-level service networks. 2. Grid Computing - A book by Joshy Joseph and Craig Fellenstein, this book is part of the IBM 'On Demand Series'. The book covers the basics of grids, the merging of grids and web services, OGSA, OGSI and the programming model for the Globus GT3 Toolkit. This is a good book for anyone who needs a crash course in grid services. It is a high-level read - not a reference manual. posted by jeff | 6:27 AM Monday, March 15, 2004 Why the Outsourcing Flap Makes Cents Rich Miller, who runs my favorite blog, made a posting near to my heart titled, "Why the Outsourcing Flap Makes No Sense" - where, Rich asks what the flap is all about. The flap is about...well, pissed off people that lost their jobs. I spoke with two different people today who are old friends. They both worked (past tense) at Sabre. The first was a VP of engineering who was laid off and his job was moved to Poland. This guy was a real "do-er" - the kind of guy that made things happen - he'd cut through the BS and get things done. Does he cost more than someone in Poland? Yes. Sucks to be him. He's now remodeling his kitchen and sending resumes out on Monster.com. He gets it - lower wages for Sabre lead to a more competitive product - higher share prices for share holders and lower prices for consumers. He completely gets it - but he's still pissed off. The second person I talked with (a project manager) told me that she was told that she had to let her whole team go because they were to be replaced with people in India. She told her manager that she didn't like the idea but went along. Eventually she was told that her job was moving offshore as well but they gave her the option of being manager of 'offshore procurement'. She did it. Then when the procurement was done she was let go. Now she is reading books on how to day-trade. And yes, she is pissed off. The flap is about people that are great at their job who get let go based purely on cost. They weren't given the opportunity to accept a lower salary - after all, their employer has a mandate to move 25% of product engineering jobs offshore. The flap is about humans who felt disgraced by long-time employers. Maybe the U.S. installed a minimum wage system too early. Maybe we drove up our own cost of living and that drove up our salaries. It is our own fault. I know - yelling about free markets won't change anything. But if my friends at Sabre and all the other companies that have cut U.S. workers want to bitch - I understand. Flap all you want - because that is all you are going to get. posted by jeff | 6:13 PM Objects, Services and Verbs A few years ago, I asked my mentor what the difference was between objects and services. He told me a handful of things, but the one that I really remember was, "objects use a 'noun.verb' notation and services use a 'verb.noun' notation." I asked him why this was a big deal and he told me that in most systems there are less verbs than nouns. His point was that you would end up with less first class citizens in a service oriented world than you would in an object oriented world. Very interesting. He later pointed out that the service citizen would likely treat data as meta-data, making it much more manageable than an object that tries to use polymorphic behavior to apply verbs functionality on nouns. I've become fascinated with service / operation naming. As an example, the WSDL spec uses, "GetLastTradePrice". Immediately I break it down, "Get" "Price" ... what kind of price? "Trade"... which one? "Last"... or perhaps it is: "Trade.Price"?... Hmmm... How about : Trade.Price.get().last(); Object, attribute, getter, ordered set operation - an interesting way to break it down. Now, why did the service people run the whole thing together (GetLastTradePrice)? Good question. Don't I end up with a ton of operations if I run them all together? What if... I didn't run combinations together, but instead identified the command components: (getter/setter) x (an objects enumerated attributes) x (potential set operations)? Should an operation name be one big concatenated string where all the potential combinations are combined at design time? SQL sure didn't do it this way - - they went command language for base manipulations - and then went stored procs with fixed names for one-offs (oh, and declarative rules *triggers* for eventing - here the name didn't matter). Anyway... all I really wanted to do was share some of my favorite verbs: insert, add, update, set, delete, remove, erase, get, select, fetch, subscribe, publish, receive, listen, send, notify, call, invoke, create, destroy, deallocate, dispose, show, view, hide, close, open, drop, restore, resume, suspend, pause, clear, filter, cache, run, start, execute, stop, allocate, new, advance, go, post, do, find, locate, evaluate, jump, visit, goto, exit, break, spawn, join, split, lock, unlock, process, print, transfer, throw, push and pop. It's a pretty good list of verbs. There are some people that REST'd after only finding two or three verbs. But they just like wrapping verbs inside of other verbs :-) That's ok - I don't think they hate verbs. They just like a couple verbs a whole bunch! I like the idea of having an enumerated set of verbs. This isn't the list, though - too much redundancy. Also, some verbs are really just combinations of other verbs. Hmmm... first order verbs. Second order verbs. How many first order verbs does a system need to have a semantic foundation for 'doing' things? And no, I'm not a verb bigot. I love adverbs too! Nouns suck - although I admire those that have the patience to play in the noun space. Adjectives are cool - only in that they are simple ... It is my belief that we are *slowly* moving towards a semantic and service oriented world. Operation names that are concatenated strings of verbs, nouns, adjectives and adverbs worry me. There is a better way. posted by jeff | 7:55 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
