As I mentioned before, I'm still not so sure about all of the things that get the Web 2.0 tag applied to them. Is it a technology (seems not)? Is it an architecture (seems not)? But maybe it is a name for a transition that occurred a few years back in the way we use and interact with the WWW. From what I've seen and heard so far, it just seems to be a name for another era in our ongoing evolution of the Web. And as far as that goes, I'm happy to use a tag.
However, as reported, Orielly has decided to trademark Web 2.0. Since it would appear he invented the term, there's nothing wrong with him wanting to protect it. Unfortunately I think they're a little late off the mark on this one. If you believe everything that's been written (and I have no reason to not do so), then the name came up in 2004. Since then it has taken off like wildfire in many circles (I've been reviewing papers for a number of conferences and workshops over the past 2 months and the term has come up on several occasions). It would seem to me that the cat's out of the bag on this one and it's far too late to come along and put a trademark on it. Alright, maybe this was always the intention but it's just taken a little longer than expected. But I'd still say it's too late. But then I'm no lawyer and I'm sure this will go in their favour. (Side note: it's a good job that another Tim didn't trademark the Web.)
So going back to what I said at the start of this entry: I think having some classification for this point in time of the Web's evolution is a good thing. If we can't use Web 2.0 for fear of getting Cease-and-Desist orders, then I propose we coin another term. The best one I've come up with so far is Web-NG, which I freely give to the world ;-) No fear that I'm going to retract that and try and trademark it. If anyone can think of a better name, then let me know. The name is secondary: the fact that it's free for use for all time is the most important thing.
Wednesday, May 31, 2006
Friday, May 26, 2006
Monday, May 22, 2006
SOA 2.0 ignorance
The viral nature of gossip has taken hold of SOA 2.0 and run with it. There are more and more articles coming out every day, or so it seems.
My question is this: why do we need the term? OK, if you're an analyst firm looking to stand out from the crowd I can understand throwing a lot of new buzzwords at a wall and seeing which ones stick! But for the rest of us living in the real world, it has no meaning at all. Despite all the hype, I think we're all agreed on what SOA means: it's an architectural approach to building loosely coupled applications. Companies have been "doing SOA" for many years, even before the term was coined, using technologies as diverse as CORBA and JMS. Think of it as a pattern, or an architectural approach in the same was as distributed object-oriented systems. It has its place in any good architects toolbelt and we're finally coming to grips with it as an industry.
Then WHAM! Along comes SOA 2.0! How? Why? WTF?! I also expected more of Oracle on this one! Giving an architectural approach a version number is crazy: it makes no sense at all! Only in software would we even consider such a thing. Can you imagine going back in pre-history: is a hut also to be known as Cave 2.0? Would a house be Cave 3.0 or Hut 2.0? Where would the St Paul's Basilica come in the grand scheme of things?! If something is truly an architectural advance over its predecessors, then it should be named uniquely for a start. Caves, huts, houses, high-rise buildings all share some commonality, but they have different architectural approaches too. To call the Empire State Building an upgraded cave is to do it an injustice (at the very least)!
Steve says it's about a combination of EDA and SOA. I hate that distinction because I think that either EDA is a specific implementation of SOA or it's simply another way of reasoning about your SOA system. Gartner then say that the difference is that SOA 1.0 (yuch!) was about client-server interactions and SOA 2.0 is about events. Apart from seeing my previous comment concerning EDA, where does it say that SOA is all about clients and servers? For a start, that implies synchronous interactions, which SOA certainly doesn't require. Secondly, I know of many SOA deployments that work on an asynchronous peer-to-peer level. Hey, maybe those guys are doing SOA 3.0?!
But in all seriousness, it seems to me that people are confusing implementation with architecture. Where does it say that SOA has to be client-server driven? That's a fairly arbitrary (aka poor) way on which to base architectural differences: by any strict definition of interaction styles, something is always a client (sender) and something is always a server (receiver), but those roles can be transient and change between invocations. That's the case in most distributed systems, not just SOA based. In the early days of distributed systems it was common to have entities that were pure clients: that's less of the case these days. Take a look at some event-driven systems: they have clients and servers too!
Furthermore, is it then really necessary to confuse the issue by adding implementation semantics within the architectural approach (i.e., events)? Why not give it its own acronym, something like that captures events, the fact that they drive things and that it's an architectural methodology? Hmmm, that would then be EDA and I'm sure some analysts coined that term a long time ago, but it didn't really capture the public imagination like some other three-letter acronyms.
You know, a more cynical person might think that the only reason for SOA 2.0 is to ride on the back of all the Web 2.0 hype that's going round at the moment. But our industry doesn't work that way, now does it?
So stay clear of SOA 2.0. If you really want to talk about SOA and EDA then do so as separate entities in their own right, or coin a new term (any suggestions?) EDSOA?
My question is this: why do we need the term? OK, if you're an analyst firm looking to stand out from the crowd I can understand throwing a lot of new buzzwords at a wall and seeing which ones stick! But for the rest of us living in the real world, it has no meaning at all. Despite all the hype, I think we're all agreed on what SOA means: it's an architectural approach to building loosely coupled applications. Companies have been "doing SOA" for many years, even before the term was coined, using technologies as diverse as CORBA and JMS. Think of it as a pattern, or an architectural approach in the same was as distributed object-oriented systems. It has its place in any good architects toolbelt and we're finally coming to grips with it as an industry.
Then WHAM! Along comes SOA 2.0! How? Why? WTF?! I also expected more of Oracle on this one! Giving an architectural approach a version number is crazy: it makes no sense at all! Only in software would we even consider such a thing. Can you imagine going back in pre-history: is a hut also to be known as Cave 2.0? Would a house be Cave 3.0 or Hut 2.0? Where would the St Paul's Basilica come in the grand scheme of things?! If something is truly an architectural advance over its predecessors, then it should be named uniquely for a start. Caves, huts, houses, high-rise buildings all share some commonality, but they have different architectural approaches too. To call the Empire State Building an upgraded cave is to do it an injustice (at the very least)!
Steve says it's about a combination of EDA and SOA. I hate that distinction because I think that either EDA is a specific implementation of SOA or it's simply another way of reasoning about your SOA system. Gartner then say that the difference is that SOA 1.0 (yuch!) was about client-server interactions and SOA 2.0 is about events. Apart from seeing my previous comment concerning EDA, where does it say that SOA is all about clients and servers? For a start, that implies synchronous interactions, which SOA certainly doesn't require. Secondly, I know of many SOA deployments that work on an asynchronous peer-to-peer level. Hey, maybe those guys are doing SOA 3.0?!
But in all seriousness, it seems to me that people are confusing implementation with architecture. Where does it say that SOA has to be client-server driven? That's a fairly arbitrary (aka poor) way on which to base architectural differences: by any strict definition of interaction styles, something is always a client (sender) and something is always a server (receiver), but those roles can be transient and change between invocations. That's the case in most distributed systems, not just SOA based. In the early days of distributed systems it was common to have entities that were pure clients: that's less of the case these days. Take a look at some event-driven systems: they have clients and servers too!
Furthermore, is it then really necessary to confuse the issue by adding implementation semantics within the architectural approach (i.e., events)? Why not give it its own acronym, something like that captures events, the fact that they drive things and that it's an architectural methodology? Hmmm, that would then be EDA and I'm sure some analysts coined that term a long time ago, but it didn't really capture the public imagination like some other three-letter acronyms.
You know, a more cynical person might think that the only reason for SOA 2.0 is to ride on the back of all the Web 2.0 hype that's going round at the moment. But our industry doesn't work that way, now does it?
So stay clear of SOA 2.0. If you really want to talk about SOA and EDA then do so as separate entities in their own right, or coin a new term (any suggestions?) EDSOA?
Friday, May 19, 2006
NoThoughtWorks?
Savas has a few things on this paper from ThoughtWorks. I wonder if Jim wants to step in ;-) I'm on my way back from JavaOne so haven't had a chance to read it yet. However, my first question would be: What's wrong with the interoperability we've been achieving successfully with Web Services? Seems like we're doing a good enough job so far!
I need how much space?
Maybe someone can explain this to me? Why do I need 15Gig disk space for Vista? No wonder we're being told to wait for a few years!
Thursday, May 18, 2006
Schweet!!
I saw a black MacBook yesterday when I called into the local Apple shop here in San Fransciso. All I can say is: drool!!!!
Tuesday, May 16, 2006
Infoq launches
Floyd Marinescu, who was the driving force behind TSS has launched his new site Infoq and asked me to publicise it. Take a look. There's an interesting article there that should you pay particular attention to ;-).
Saturday, May 13, 2006
Another busy week ahead
I'm about to leave for JavaOne, where it's going to be an extremely busy week. On Tuesday I'm on a panel session called What's Happening With SOA in Open Source?, where I'll say a few things about JBossESB, there's another JSR Spec Lead Dinner on the evening, followed by the BOF on transactional Web Services that I'm giving with Kevin. On Wednesday I'm giving a number of interviews, plus a press round table event (on standards and Java), before attending the JCP Community Awards event on behalf of JBoss.
In there somewhere I also want to go to a few sessions (as well as the JBoss Party!) It turns out that Greg's in town too, so there will definitely be a catch-up session involved there. I've also just found out that my friend and ex-Arjuna colleague Arnaud will be coming this year, so I hope to see him too.
In there somewhere I also want to go to a few sessions (as well as the JBoss Party!) It turns out that Greg's in town too, so there will definitely be a catch-up session involved there. I've also just found out that my friend and ex-Arjuna colleague Arnaud will be coming this year, so I hope to see him too.
Friday, May 12, 2006
At long last
It's only taken us 9 years (if you include the original OMG work), but finally ...
The Expert Group for JSR-000095 J2EE Activity Service for Extended
Transactions has completed its work and published the Final Release of the
specification.
The Final Release of the specification is available from the Java
Community Process Web site at:
http://jcp.org/en/jsr/stage?listBy=final
and also from the JSR 95 detail page:
http://jcp.org/en/jsr/detail?id=95
The Expert Group for JSR-000095 J2EE Activity Service for Extended
Transactions has completed its work and published the Final Release of the
specification.
The Final Release of the specification is available from the Java
Community Process Web site at:
http://jcp.org/en/jsr/stage?listBy=final
and also from the JSR 95 detail page:
http://jcp.org/en/jsr/detail?id=95
Wednesday, May 10, 2006
Wednesday, May 03, 2006
Complexity theory
I just gave an invited presentation on Web Services at School of Computer Science at Manchester University. I covered basic and advanced Web Services, Web 2.0, REST and Semantic Web (cramming to get all of this into an hour). The audience appeared interested and I got some good follow-up questions. But as you might imagine, it was tricky to get everything in to the allocated time slot.
However, one thing that became apparent to me over the past few days as I wrote the presentation was how difficult it is to actually cover *just* Web Services in an hour! I remember giving talks on Web Services back in 2002/2003 when there was really just SOAP, WSDL and a smattering of UDDI: that's an hour, depending on how much detail you want to go into around SOA. In the intervening years we've standardised on more aspects of the WS architecture and complexity has risen. Now don't get me wrong: I'm not saying that we could avoid the complexity or that it's a bad thing. I've worked on a range of distributed systems architectures over the years and there really is no such thing as a free lunch: if you need advanced facilities such as session management, transactions, security and fault-tolerance then you've got to pay for them somewhere, and pushing things "behind the service endpoint" only works to a point.
Web Services started out as simple (often compared to the complexity of CORBA), but have inevitably gotten more complex as we try to do more and more with them. In some ways, the closest analogy I can come up with is Java: it started out as being "better" than C++ because it was so much simpler - none of those waste-of-space features such as multiple inheritance, pass-by-reference or templates and none of the huge libraries that you never needed (I'm joking here, because I always felt the need for such features). But look at it today: we've now got templates and the JDK is 60Meg! A simple Hello World application takes many Meg to execute!
However, one question I posed during my presentation was: Can it be simpler? What about the WWW? Technically it hasn't changed much and yet we're now working in a Web 2.0 world (I don't like the term, but I agree with the categorisation). The REST approach is often mentioned as more natural for services on the Web than Web Services (evolution rather than revolution), so what about that as the foundation on which to build a simpler and better Web service (small 's') architecture? As you may have gathered, I think the answer is no. That's not to say that I don't think some aspects of a pure REST-ful approach wouldn't be simpler (e.g., URI's have been pretty successful for the WWW, so we may not need something like WS-A), but other aspects may be more complicated (e.g., transactions - my first foray into transactions on the Web started out effectively REST-based I think and it was difficult to do in those days so it ended up quite different). However, the approach does intrigue me enough that, should I ever find any spare time, I'd like to flesh out how a REST service architecture might match up to its Web Services cousin. Anyone wanting to help, just drop me a line.
But back to Web Services! The death of Simple Web Services was signaled as soon as we wanted to do more complicated things with it. We shouldn't ignore that fact and continue as though we were still working in 2002. The S in SOA doesn't stand for, or imply, Simplicity. Whether you're talking services, objects or procedures, complex things such as transactions require complex solutions. This shouldn't come as a surprise to anyone who's been working in distributed systems over the past 20+ years.
However, one thing that became apparent to me over the past few days as I wrote the presentation was how difficult it is to actually cover *just* Web Services in an hour! I remember giving talks on Web Services back in 2002/2003 when there was really just SOAP, WSDL and a smattering of UDDI: that's an hour, depending on how much detail you want to go into around SOA. In the intervening years we've standardised on more aspects of the WS architecture and complexity has risen. Now don't get me wrong: I'm not saying that we could avoid the complexity or that it's a bad thing. I've worked on a range of distributed systems architectures over the years and there really is no such thing as a free lunch: if you need advanced facilities such as session management, transactions, security and fault-tolerance then you've got to pay for them somewhere, and pushing things "behind the service endpoint" only works to a point.
Web Services started out as simple (often compared to the complexity of CORBA), but have inevitably gotten more complex as we try to do more and more with them. In some ways, the closest analogy I can come up with is Java: it started out as being "better" than C++ because it was so much simpler - none of those waste-of-space features such as multiple inheritance, pass-by-reference or templates and none of the huge libraries that you never needed (I'm joking here, because I always felt the need for such features). But look at it today: we've now got templates and the JDK is 60Meg! A simple Hello World application takes many Meg to execute!
However, one question I posed during my presentation was: Can it be simpler? What about the WWW? Technically it hasn't changed much and yet we're now working in a Web 2.0 world (I don't like the term, but I agree with the categorisation). The REST approach is often mentioned as more natural for services on the Web than Web Services (evolution rather than revolution), so what about that as the foundation on which to build a simpler and better Web service (small 's') architecture? As you may have gathered, I think the answer is no. That's not to say that I don't think some aspects of a pure REST-ful approach wouldn't be simpler (e.g., URI's have been pretty successful for the WWW, so we may not need something like WS-A), but other aspects may be more complicated (e.g., transactions - my first foray into transactions on the Web started out effectively REST-based I think and it was difficult to do in those days so it ended up quite different). However, the approach does intrigue me enough that, should I ever find any spare time, I'd like to flesh out how a REST service architecture might match up to its Web Services cousin. Anyone wanting to help, just drop me a line.
But back to Web Services! The death of Simple Web Services was signaled as soon as we wanted to do more complicated things with it. We shouldn't ignore that fact and continue as though we were still working in 2002. The S in SOA doesn't stand for, or imply, Simplicity. Whether you're talking services, objects or procedures, complex things such as transactions require complex solutions. This shouldn't come as a surprise to anyone who's been working in distributed systems over the past 20+ years.
Monday, May 01, 2006
Web Services, interoperability and portability
I've been meaning to write this entry for a couple of weeks, but just haven't had the time. The original impetus for this came about because of a recent client engagement that reminded me of previous similar interactions. At the heart of the problem lies the difference between interoperability and portability, a discussion that isn't new by any means, and neither is it a Microsoft versus everyone else argument: J2EE and CORBA both suffer too.
Where the recent confusion arises is around the hype associated with Web Services: too often people will say things like (and I'm paraphrasing) "Web Services are meant to be interoperable, allowing you to talk to other vendor implementations and hence removing vendor lockin." Now everyone working in this sector of the industry knows (I hope) what this actually means: product A from vendor 1 can interact with product B from vendor 2 because the on-the-wire representation is defined within some set of standards with which both products comply. Unfortunately what the customer/end-user tends to hear is subtly different: "blah blah blah the same application can run on different vendor deployments blah blah blah." and when you come to educate them on the difference (e.g., Web Service standards don't talk about implementation language bindings, there's still scope for proprietary extensions within standards
and there's still no agreed Web Services architecture), they either look at you as though you'd just arrived from Mars or that you've taken their favourite toy away!
In no cases I've been involved with has the customer decided to ditch the move to Web Services (though some have seen Microsoft as a better route to achieving portability and interoperability, simply because the landscape isn't so fragmented - but there are other downsides to consider!), but they've asked the question "why?". Unfortunately that's not the right question either: it should be "how?". There are a number of steps that would need to be taken, one of which could be to go down the OMG route of a single organisation defining all language bindings and everyone agreeing to use them (Java almost has it). But I don't think that's going to happen (and in some respects I think it shouldn't): there's simply never going to be enough technical or political reasons to do so.
Ultimately I think this is an education problem. We need to make sure we clearly define what we mean by interoperability and portability (straighforward to do, you would think) and try not to gloss over the differences. Interoperability is extremely important as far as Web Services are concerned (at the moment I'd say it is the single most important aspect) and correctly discussed, customers will agree.
Where the recent confusion arises is around the hype associated with Web Services: too often people will say things like (and I'm paraphrasing) "Web Services are meant to be interoperable, allowing you to talk to other vendor implementations and hence removing vendor lockin." Now everyone working in this sector of the industry knows (I hope) what this actually means: product A from vendor 1 can interact with product B from vendor 2 because the on-the-wire representation is defined within some set of standards with which both products comply. Unfortunately what the customer/end-user tends to hear is subtly different: "blah blah blah the same application can run on different vendor deployments blah blah blah." and when you come to educate them on the difference (e.g., Web Service standards don't talk about implementation language bindings, there's still scope for proprietary extensions within standards
and there's still no agreed Web Services architecture), they either look at you as though you'd just arrived from Mars or that you've taken their favourite toy away!
In no cases I've been involved with has the customer decided to ditch the move to Web Services (though some have seen Microsoft as a better route to achieving portability and interoperability, simply because the landscape isn't so fragmented - but there are other downsides to consider!), but they've asked the question "why?". Unfortunately that's not the right question either: it should be "how?". There are a number of steps that would need to be taken, one of which could be to go down the OMG route of a single organisation defining all language bindings and everyone agreeing to use them (Java almost has it). But I don't think that's going to happen (and in some respects I think it shouldn't): there's simply never going to be enough technical or political reasons to do so.
Ultimately I think this is an education problem. We need to make sure we clearly define what we mean by interoperability and portability (straighforward to do, you would think) and try not to gloss over the differences. Interoperability is extremely important as far as Web Services are concerned (at the moment I'd say it is the single most important aspect) and correctly discussed, customers will agree.
Subscribe to:
Posts (Atom)