|
|
| Service Oriented Enterprise |
|
|
Friday, May 09, 2003 Service Oriented Aspects - or - Aspect Oriented Services I had a great conversation yesterday with one of the IBM guys. He was very excited about aspect oriented programming, while I was promoting the service-oriented model. As we got deeper into the conversation, we realized that the concept of aspects were very applicable in the service oriented world. In the SOA, we "apply" new functionality or "aspects" to a service via one of several mechanisms. For talking purposes, let's use the "logging" example. That is, an aspect that can be applied across a set of objects (or services) that log all the calls. There are several ways that we can add functionality. Perhaps the most straight forward in the service oriented world is by using the pipe & filter. Here we simply pipe the output of our primary service into a new service (like logging) - and we've created a discrete, assembly line approach to adding functionality. The down side is that the each participant in the pipe chain must be explicitly called and the programmer is exposed to a significant amount of raw details that they may wish to avoid. A second method for performing this feat is to create a "tightly coupled web service" - here we just hard code the stuff right into the web service. So service 1 is hardcoded to call service 2 (logging). Perhaps not the best idea, but likely the most common means in the first go-round of creating web services. A third method is to describe the functionality at the protocol layer. Take WS-ReliableMessaging, this information gets baked into the stream and now both participants know that they should "apply" extra functionality to make it work. This is a great way to force the adoption of functionality with minimal impact on the programmer, but is really targeted at scenarios where 2 or more participants must engage in a conversation and have a minimal agreement. Dropping too many "aspects" into the protocol will create fat and rigid protocols that are hard to debug. A fourth method for addind functionality to a service is to create a "composite web service". Here we have one web service front-end several services. A great example is using BPEL4WS. This allows you to call a single service and a script of services that it turns around and calls for you. BPEL is designed to be loosely coupled, where new services can easily be added. The neat thing is from the outside, a BPEL looks like web service - and it is. The BPEL method is a great way to create loosely coupled service composition, but it does it by standard flow-control mechanisms. Thus it takes on a loose coupled version of the pipe & filter model. What I am looking for is the 5th way - and as far as I know, it doesn't exist (yet). I'm picturing a WSDL model that understands pre & post conditional apsects. Here the WSDL can have declarative aspects attached to it. The closest thing I've seen is "XL", see: http://xl.in.tum.de/publ/www2002.html I'm not sure that this is the right way to do declarative, aspect based constructs for a service oriented world, but it sure the hell advances the thinking. posted by jeff | 7:47 AM Thursday, May 08, 2003 Implementation strategies for WS-ReliableMessaging IBM has published a nice article on usage of WS-ReliableMessaging, see: http://www-106.ibm.com/developerworks/webservices/library/ws-rmimp/ posted by jeff | 7:35 PM Sun Joins OASIS' BPEL Committee See: http://www.eweek.com/article2/0,3959,1061476,00.asp In an unexpected move, Sun Microsystems Inc. said it will join the Organization for the Advancement of Structured Information Standards' (OASIS') Web Services Business Process Execution Language technical committee. A Sun spokesman told eWEEK that Sun will be joining the WSBPEL technical committee and will be in attendance at the first face-to-face meeting of the group, slated for May 16. "Absolutely, Sun will be joining," the spokesman said. "We will be there at the first meeting on May 16. No rep named yet but we will have one by then." The move indicates something of a turnabout for Sun, which is supporting an alternative specification to handle Web services orchestration, known as WS-Choreography. That standard, also supported by Oracle Corp. and others, is being developed under the World Wide Web Consortium (W3C). posted by jeff | 10:13 AM Tuesday, May 06, 2003 UDDI v2 becomes OASIS Standard! From OASIS, "OASIS is pleased to announce that the UDDI v2 specification has been approved as an OASIS Standard. The UDDI Spec TC is to be congratulated on the work they have done in developing this specification." posted by jeff | 5:38 PM Sunday, May 04, 2003 World Wide Grid (WWG) - A Challenge! I'm going to put my marketing hat on for a minute.... It occurred to me that we techies have failed to create a name for the web service based Internet. You know, that thing that is service oriented, message driven, self-describing, standards-based, loosely coupled - yet structured? Roughly, it is the universal services network sitting on top of the Internet and the wireless Internet shooting XML specified messages around according to specifications driven by the non-profits and the computing giants. For a while people called it, Web II or Web V2 - but those have faded away. Today, I propose "World Wide Grid" or "WWG" as the name for the aforementioned network. "Huh?", you say...still don't get it?? OK, one more attempt, it is the combination of the WS-I Basic Profile (SOAP, UDDI, WSDL, XML Schema) + the new WS-I Security Profile + an addressing & routing scheme (WS-Routing, WS-Addressing) + a reliable messaging scheme (WS-Reliability) and a transaction scheme (WS-Coordination and WS-Transaction). These protocols will be complemented by a series of protocols that will be optional. The optional protocols will be utilized in a "Must-Understand" scenario between conversing parties. This will include everything from billing, provisioning and SLA's, to logging. But why the WWG? Doesn't "grid" sound too much like a high-performance, distributed computing grid, like the efforts at Globus? Maybe - but before too long the "low-performance" and "high-performance" grids will have a significant amount of overlap and may likely become one grid. What about the OGSA efforts? That's easy - many people (like IBM marketing) tend to use grid to mean "run-time dynamic allocation of resources (CPU, Disk, Memory, Network) - this is clearly part of a grid - the part that many companies will promote to customers as having a near term advantage (cost savings through server consolidation), but it only touches on the real opportunity of creating a secure, messaging network where anyone in the world can participate. Call me old fashioned, but what many call grids are not much more than advanced versions of MPI - - and this in my opinion is missing the boat. Back to marketing - I imagine the T.V. commercial where Bill Gates, Tim Berners Lee, Larry Ellison, Scott McNealy and Sam Palmisano stand up together and tell the world that they are backing, creating and selling the next web, the WWG. They go on to explain that it will connect every business, enable extended supply chains and create efficiencies that have only been dreamt about... I then imagine the NASDAQ once again being a popular place to make investments. Web services are a network. And the network needs a name. I know that many people read my blog - and many of you blog as well. So here is my challenge - support me in creating a new name for this next generation network -- OR -- make a better (or different) recommendation. Blog it and let's revisit. posted by jeff | 9:49 AM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
