Architect or Cobbler?: Playing with Indigo

I've just got back from Reading where I'm attending an Indigo Ascend program, and actually getting some hands on with the technology. It was also good to some old familiar faces, and nice to see so many people with a J2EE background there. So far it looks an interesting technology for connecting services together, which brings me nicely to today's topic - just what is a service? We've just started refining our design courses and we're having the same internal debates that many architects are having. Like what exactly distinguishes service orientation from object orientation? Is a service interface just a fancy extended component interface, a la COM+ and EJB? If you look around for a definition you'll get many different definitions of what a service is, but for me they all share some common features. A service exposes a contract - preferably as interoperably as possible, but many service contracts are not, due to the fact that many developers create the contract from the implementation of the service. Many people equate services with web services, and in this guise the WSDL fulfils the role of contract. A service is autonomous. This means that any service is always available (well, within reason) and is developed, deployed and tested in isolation of other components (contrast this with OO, where typically we can achieve something like autonomy, but the tight coupling between cients and servers means that even if we don't develop them together the teams have to be talking to each other all the time, and they will be developed in similar time frames). The real impact here to my mind, is that once you put a service out there, you end up running several versions concurrently, as the business needs change. I know that versioning is an issue with OO systems as well (just ask anyone who's used XML parsers), however you have much more control typically, you can for instance retire clients when new versions are released, you will seldom have this luxury with truly loosely coupled services. Amazon's ECS (e-commerce services) are a classic example of this. It is currently V4.0, but supports V3.0 clients and looks like it will for some time. I don't care how Amazon achieves this trick, but it does mean my ECS 3 client still works. Services explicitly reveal their endpoints - this is particularly novel. I've been a CORBA and EJB developer for some time (and occasionally dabbled with COM+ as well, just to see how the other half live), and there the mantra has always been location transparency. As someone who has suffered in early EJB implementations with subtle bugs due to app servers trying to optimise some calls out of the RMI stack when beans were co-located, I actually like this. EJB 2.0 acknowledged this problem, and now you have to explicitly indicate local or remote invocation for your EJB. Services, on the other hand are nearly always remote (ignoring for now that rather strange WSE inProc mode), and you need to invoke them using explicit messaging. All of this leads to some rather glaring differences when designing a service oriented contract to developing a component interface. The first difference is that services simply pass data around (there is no behaviour in the parameter model, as you are typically serializing to an XML message), therefore services are much more likely to have coarse grained methods that take data structures as arguments. Another problem is that unlike OO programming I have no (or limited) control over my clients, for instance I may have a service submitOrder(Order order) that is publicly available. Anyone could now call this service, so most services access will be controlled by policy rather than programatically. So in a nutshell, service orientation is different to object orientation, and simply refactoring component interfaces as web services, as the ASMX model promotes, is not the way to go. From what I've seen so far, the designers of Indigo have realised this, and over the next few blogs I'm going to be diving into the guts of Indigo to look at how it promotes service oriented development.

# posted by James @ 8:04 PM 0 comments Comments: Post a Comment

<< Main blog page

about me

links

Blogs I follow

recent posts

archives

feeds

Playing with Indigo

Monday, May 09, 2005


Architect or Cobbler? Good code starts with good design
about me Name: James Winters Home: Swindon links Solid Quality Mentors The Server Side - .NET edition The Server Side - J2EE edition The .NET Architecture Centre Java BluePrints Blogs I follow Darren Burford - Darren's Journal Julie Lerman - Don't be Iffy Danny Simmons - system.data.objects. dev guy recent posts Getting Started archives May 2005 August 2005 September 2005 October 2005 November 2005 December 2005 May 2006 June 2006 November 2006 December 2006 January 2007 November 2007 March 2008 feeds	Playing with Indigo Monday, May 09, 2005 I've just got back from Reading where I'm attending an Indigo Ascend program, and actually getting some hands on with the technology. It was also good to some old familiar faces, and nice to see so many people with a J2EE background there. So far it looks an interesting technology for connecting services together, which brings me nicely to today's topic - just what is a service? We've just started refining our design courses and we're having the same internal debates that many architects are having. Like what exactly distinguishes service orientation from object orientation? Is a service interface just a fancy extended component interface, a la COM+ and EJB? If you look around for a definition you'll get many different definitions of what a service is, but for me they all share some common features. A service exposes a contract - preferably as interoperably as possible, but many service contracts are not, due to the fact that many developers create the contract from the implementation of the service. Many people equate services with web services, and in this guise the WSDL fulfils the role of contract. A service is autonomous. This means that any service is always available (well, within reason) and is developed, deployed and tested in isolation of other components (contrast this with OO, where typically we can achieve something like autonomy, but the tight coupling between cients and servers means that even if we don't develop them together the teams have to be talking to each other all the time, and they will be developed in similar time frames). The real impact here to my mind, is that once you put a service out there, you end up running several versions concurrently, as the business needs change. I know that versioning is an issue with OO systems as well (just ask anyone who's used XML parsers), however you have much more control typically, you can for instance retire clients when new versions are released, you will seldom have this luxury with truly loosely coupled services. Amazon's ECS (e-commerce services) are a classic example of this. It is currently V4.0, but supports V3.0 clients and looks like it will for some time. I don't care how Amazon achieves this trick, but it does mean my ECS 3 client still works. Services explicitly reveal their endpoints - this is particularly novel. I've been a CORBA and EJB developer for some time (and occasionally dabbled with COM+ as well, just to see how the other half live), and there the mantra has always been location transparency. As someone who has suffered in early EJB implementations with subtle bugs due to app servers trying to optimise some calls out of the RMI stack when beans were co-located, I actually like this. EJB 2.0 acknowledged this problem, and now you have to explicitly indicate local or remote invocation for your EJB. Services, on the other hand are nearly always remote (ignoring for now that rather strange WSE inProc mode), and you need to invoke them using explicit messaging. All of this leads to some rather glaring differences when designing a service oriented contract to developing a component interface. The first difference is that services simply pass data around (there is no behaviour in the parameter model, as you are typically serializing to an XML message), therefore services are much more likely to have coarse grained methods that take data structures as arguments. Another problem is that unlike OO programming I have no (or limited) control over my clients, for instance I may have a service submitOrder(Order order) that is publicly available. Anyone could now call this service, so most services access will be controlled by policy rather than programatically. So in a nutshell, service orientation is different to object orientation, and simply refactoring component interfaces as web services, as the ASMX model promotes, is not the way to go. From what I've seen so far, the designers of Indigo have realised this, and over the next few blogs I'm going to be diving into the guts of Indigo to look at how it promotes service oriented development. # posted by James @ 8:04 PM 0 comments Comments: Post a Comment << Main blog page