|
|
| Service Oriented Enterprise |
|
|
Saturday, February 07, 2004 More on Pass-by-Reference Stefan Tilkov made an interesting point, " I believe anytime you make a copy of some data - which is unavoidable if caller and callee don't reside in the same address space - you can't do pass by reference." Here are some things that I've been thinking about: ---- Pass by Value implies the creation of multiple copies of the data and any changes made to one copy do not propagate to the other copies. Pass by Reference implies a single 'master' instance of the data; thus all changes made to one copy apply to all references. ---- Pass by Value implies that the data 'value' is created at the time determined by the sender. Pass by Reference implies the data 'value' is populated at the time determined by the receiver. ---- Pass by Value implies that the copies of the data were a snapshot in time. Thus the data may become stale between accesses. Pass by Reference implies that the data is 'current' - however, it may not reflect the state of the data as intended by the sender. Both Pass by Reference and Pass by Value can use a 'leasing' mechanism to deal with stale information or stale resources. ---- Pass by Value implies that the contents of the message is data. (Out of scope: mobile agents and Jini style proxies) Pass by Reference implies that the contents of the message is either a pointer to data, a pointer to functionality or both. ---- Pass by Value implies that the contents of the message are fully contained within the message, thus you pass *everything* Pass by Reference implies that the contents of the message are not contained within the message and the recipient can choose at runtime which piece of the data they are interested in. ---- Pass by Value can be implemented in a single call. Pass by Reference requires at least 2 calls; the first one sends the pointer, the second call retrieves the data (by value) ---- Pass by Value implies that the message contains the exact information desired by the sender (maintains data integrity) Pass by Reference does not guarantee that the data being passed is that which was desired by the sender. This is due to the potential modifications of the data between 'send time' and 'retrieve time'. This problem can be overcome by using some sort of locking or checksum mechanism. ---- - I like the idea of not passing around 'fat messages' (extra information that the ultimate receive may not be interested in) - In some cases, I like the idea of passing pointers to data. - In some cases, I like the idea of passing XQuery expressions that point at virtual endpoints where the predicate is populated by the ultimate receiver and a lease verifies that the data/resource isn't stale. Here, I'm not sending the data - I'm sending a partial evaluation expression for the data. However, you'll notice that this style of programming is starting to sound like what we did in the client/server days of stuffing all of our messages in our relational database and then passing around SQL statements that referenced the data. Issues here too. Stefan is right in that remotely referenced information eventually becomes a *value*. But the Pass by Reference model has additional attributes that should be considered at design time. It is my opinion that PbV and PbR will both exist in the web services world and should be part of the toolbelt of the service designer. The aforementioned differences should be weighed when deciding between them. posted by jeff | 8:18 AM Friday, February 06, 2004 I'm worried I lived the dot-com life. My consulting customer base was every bad idea from Garden.com to BubbaJunk.com. I saw venture investors who were normally smart people throw their money away. I saw hard working employees work nights and weekends, dreaming for the next big IPO. Well, in Austin it is now apparent that things are beginning to turn around. The first 'major' sign happened last night - the Austin Business Happy Hour returned. And unlike the last 3.5 years - the event was packed. People were optimistic - startups were emerging. Pretty much everyone had jobs and those that didn't have jobs had left on their own. The event was reminiscent of the dot-com days (minus the recruiters). So, why am I worried? I'm worried for two reasons: 1. The startups that I'm seeing emerge look just as stupid as the ones I saw emerge in 1998. 2. The startups aren't going to get funded by VC's. Entrepreneurs may be quick to forget, but the VC's aren't. I don't mean to be a stick in the mud, but business is still tough. Sure, things are picking up - everyone is doing better, but it is no cake-walk. Sometimes I get the feeling that the startups that are forming right now are based purely on the fact that the smart people that went into hiding (took a job with a big company), just can't stand working in the cube from 9 to 5 anymore and feel the need for speed. Well, I hope I'm wrong. I enjoyed partying like it was 1999... posted by jeff | 5:00 PM Wednesday, February 04, 2004 Pass by Reference : Answer #2 As previously posted, I've been looking at options for passing by reference. It has been interesting to see how people interpret this question. The first divide occurs in regard to 'what' is being referenced in the pass: pointers to data or pointers to services (or pointers to service that front-end data). One thing that everyone seems to be agreeing on is that the 'pointer' is the URI. Last night I had a brief discussion with Dave Langworthy of Microsoft. Dave confirmed a couple of things. 1. There is no WS-EndpointReference specification, the portions of that spec that were relevant were rolled into the WS-Addressing specification. 2. I can accomplish what I want by using the endpoint reference functionality. This threw me for a loop, mostly due to my lack of knowledge on this spec. Dave went on to explain that there are two primary pieces of the WS-Addressing specification: 1. The Message Header - This gives the from/to info for the header of the SOAP envelope 2. Endpoint References - This points to resources; these resources could be data, processors or other. Also, the Endpoint Reference is a 'type' which can be used in the body of a soap message. This means that you would define your WSDL 'message part' using an Endpoint Reference as the 'type' of a 'part'. Within the 'EndpointReference' structure, there are a couple items of interest: 1. 'Address' - This is the URI of the data that you want to reference (or the actual endpoint referencing a service that gives you access to the data) 2. 'Reference Properties' - This is the bucket where you add qualifiers to zero-in on the information you are looking for. In my case, it will likely be an XPath expression that points to a specific element in an XML schema. Summary - you can use an endpoint reference as standard type to act as a pointer to a resource. This standardized type can be leveraged inside of your own messages. Sidenotes: - The Address could specify a 'virtual' address that performs further resolution - The Address could point to the URI of 'localhost' enabling pass-by-reference in local mode - I'm not sure if there is a standardized way to drop in an XPath expression in a ReferenceProperty (anything special?) - If the Address is referencing an XML document don't expect locking / synchronization, etc. posted by jeff | 7:09 AM Tuesday, February 03, 2004 Web Services and Grid Here's a nice presentation on web services and grid technologies (WSRF): http://www.globus.org/wsrf/sabbah_wsrf.ppt posted by jeff | 7:56 PM 'Pass by Reference' in web services I've been looking into my options for providing 'pass by reference' capability in web services. I know, I know - PBR is the root of all evil in loose coupling. But it is also the performance enabler for many applications. Thus, the goal is to identify the best mechanism that enables loose coupling while still providing performance. My initial quest took me down a road that I'm calling "Pass By RESTference". I ran the concept by the smart guys on the Yahoo SOA group and it didn't get nuked (which is good in that group). The next issue is, how do you do it? Well, the closest example I've seen is probably this: http://wiki.astrogrid.org/bin/view/Astrogrid/RestStyleWebServices I'm going to chase down a couple other items... it has been rumored that WS-EndpointReference has something to say about this problem. In addition, I'm hearing that the OGSA guys have an alternative answer. More to report later. posted by jeff | 6:16 AM Sunday, February 01, 2004 Analysis of Orchestration Space I know it isn't traditional to post your competitive analysis - but I'm not very traditional. Here is a copy of my internal analysis of the orchestration space (from an OpenStorm perspective). ============================================= Don, You were asking about competition. Here's a breakdown: High-end EAI: (SeeBeyond, Tibco, Vitria, WebMethods.) Big 3 (IBM, BEA, MS) BPEL Pure Plays (Collaxa, FiveSight, Vergil, Choreology) Web Service Networks with BPEL (GrandCentral) Workflow (Dralasoft, Reactor) Pure play BPM (Lombardi, Fuego, Savvion, Intalio) JMS and ESB providers (SpiritSoft, Sonic, Fiorrano) Web Service platform providers (Systinet, CapeClear) The fact is... orchestration is a sweet spot and people are looking at it from many different angles. Here's my take on how it might play out: High-end EAI - These guys are having a hard time competing on cost and putting together a message that doesn't bastardize their current high-end revenue stream. They will likely take a 'wait and see' attitude towards orchestration, putting out an offering, but not really marketing it. It is likely that they will spread some FUD about orchestration, saying it is slow or lacks functionality and that their proprietary offerings are more 'seasoned'. Ultimately they will have to play in the game or will become outdated. The Big 3 (IBM, MS, BEA) have a different story to tell. Their story is "Orchestration is great, but it is only a small piece of the puzzle". They won't try to have the best orchestration offering, just one that integrates into their stack the best. IBM shops will want IBM, MS shops will want MS... These guys will get a significant piece of the pie; they always do - people buy here for peace of mind. BEA may have a bigger challenge; their offering lacks substance and BEA doesn't have the clout that MS or IBM have. BPEL pure plays - perhaps a more interesting category. Collaxa came out with an early lead but then went on to put out 14 or so betas and still haven't knocked it out of the park. Vergil, Choreology and FiveSight are all still a bit early - mostly in stealth. Thus too early to tell. Expect to see these guys either partner, strategic partner or drop into a niche market. Web Service Networks - A couple of months ago Grand Central announced that their web services network would support BPEL. Although I'm not sure, it appears as though they rolled their own implementation of BPEL - which would be odd for an infrastructure provider. The implementation had a significant number of non-standardized extensions which I believe they needed to more fully support their existing network. Maintaining a BPEL engine is a bitch - in the long run, I would expect GC to OEM an engine from somewhere else - unless they are getting out of the ASP market all together. Workflow - Workflow and Web Service Orchestration may seem like a similar problem, but in reality they are very, very different. Some of the vendors that claim features similar (but different) will likely confuse uneducated buyers -but the customers that we want will know the difference. Pure Play BPM - These guys have had every opportunity to break up their monolithic architectures into a component-ized (or service oriented) architecture. As far as I know, none of them have made significant progress down this path. Intalio seems to get it but doesn't seem to be delivering the message. If these guys start delivering a "SO-BPM" story (Service Oriented BPM), watch out - they could be real contenders (of course, they will have to have product to back it up). JMS / ESB - Here there are two categories 1. Sonic, 2. Everyone else - The fact is, Sonic is a marketing machine. I tip my hat to them. These guys not only could sell ice to Eskimos - they do! In the short term, I think they will be the single biggest threat. However, they have some baggage they bring with them (JMS is commoditized, ESB will eventually be a joke) All of the other ESB vendors will have to compete based on product features/functionality/price (think bake-offs against Sonic). Web Service Platforms - Oddly, there are really only 2 platform providers left (Cape Clear and Systinet). Both of the players will need to get an orchestration offering. Their issue will be to knock orchestration out of the park - otherwise they will have to lead with their less expensive and commoditized SOAP stacks - and then try to upsell to a more expensive offering. =============================== If you believe in the 'web services programming model', 'service oriented integration' or 'pervasive integration' then it is only a matter of time before you realize that orchestration is the flagship of this rather complex offering. Protocol offerings should be built into the operating system (and will be). Queues are commoditized... and making 'web service enabled queues' takes about a day of engineering effort. The 80-20 rule on transformation makes out of the box, pipelined XSL offerings attractive. However, debugging a distributed, service oriented, message based, declarative policy based, multi-platform, asynchronous, concurrent, cross-enterprise process is.... "hard". The issue around orchestration will quickly turn to 'total cost of ownership' - the vendor that wins will be the one that allows the enterprise to reduce the cost of maintaining production instances (keeping the service network up, debugging issues, resolving performance problems, maintaining version, etc.) The offerings will have to go beyond orchestration and into 'composite distributed applications'. The expectations that will be placed on our new service oriented virtual machine (the service network) will be significant. As the new programming model emerges, people will be wanting a vendor that isn't a 'spot' technology but rather an enabler of the new model - that's where we come in. posted by jeff | 7:06 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
