October 2004 - Posts

• SOA Design with Agile methodologies

  Service Oriented Architecture (SOA) and Agile - two of the current "hot topics" in IT.  The interesting thing is that even though they're fundamentally different - one being a set of architectural principles, the other a set of methodology principles, one of the key goals and benefits of both is enabling change. Now, there are clearly differences in the goals (enterprise integration vs. fail early, etc.), but that's beyond the scope of this entry.  What this is about is that these are two sets of principles that are both useful and appropriate in today's technology landscape.  So, a natural situation to arrive at is where you want to transform a company to use both Agile and SOA.  This raises an interesting issue, though... Agile methodologies promote an incremental, iterative approach to development of functionality (including method signatures), with visibility of the impact of change given through test coverage.  Basically, working on the premise that, change is cheap if supported correctly SOA promotes a well defined service interface through contracts - these contracts are aligned against business processes, not implementation details.  The rigidity of the service interface, and its non-technical alignment allows for internal change without impacting consumers of the service.  Changing a service interface is an involved process, though; rather than an outright change, a versioning mechanism is needed due to the immutability of contracts, and therefore a migration process is required.  The visibility of service usage is also very difficult to monitor as it could be external organisations rather than internally controlled systems.  The upshot of these two factors is that change to the interfaces of a service are relatively expensive So, whilst the internal development of services and service-consumers is in-line with Agile, the creation of service interfaces isn't - an incremental, iterative approach to those would cause serious versioning and compatibility problems, especially with remote (3rd party) consumers.  Similarly, imagine you're on the receiving end of another company that has an Agile approach to a service interfaces you're consuming; the contract you're adhering to would shift under your feet continually, introducing additional cost. Thankfully, there is not only a solution to this problem, but it is also one that actually benefits Agile methodologies.  The solution is to make use of the incremental aspects of Agile, without the iterative approach when designing service interfaces.  Basically, the service interfaces should be defined just-in-time; when the first requirement for a certain piece of functionality arises, the definitive implementation of the interface for that particular service method and no more is derived.  The removal of an iterative approach to interface design is important not just for cost reasons - one of the key factors in the success of an SOA is how accurately the service interface mirrors the real world process.  If deriving a clear definition of this interface cannot be done, then it generally means that the underlying process isn't well understood. As for the benefits of this to Agile, it's long been my opinion that the largest problem with such approaches are the introspective facets of them - the virtual disregard for what isn't clearly defined and within the primary context.  Service interfaces act as change boundaries for these introspective "pockets", containing them from unintentional impact on other such "pockets".  This allows iterative approaches to be taken to the component- and object-oriented internals of services, without incurring the cost of repeatedly integrating between potentially external, non-visible systems. Posted Oct 17 2004, 08:56 PM by jsgreenwood with 3 comment(s) Filed under: Architecture, Process

• User Agents - Tomorrow's Technology Today

  For years, there's been talk of tomorrow's technology - user agents, and how they'll make our lives better.  How we'd be able to sit there waiting for information to come to us, with agents going away collecting it, collating it, and presenting it back.  How this would change our lives.  Like many, I've been of the opinion "I'll believe it when I see it" for a long time, and it kind of got written off and pushed to the back of my mind. And then I realised, user agents are here and have been for quite some time.  It's just that the reality's not quite how I (or I guess others) envisaged it to be. From the very first e-mail client, we've had user agents; desktop applications that communicate with remote servers and bring down data ready for when we want it, and notify us of its arrival.  The addition of out-of-office replies, then Rules Wizards, then Junk mail filters are all moving the likes of Outlook in the direction of the archetypal "user agent".  But the presentation is still largely standard desktop client.  Other examples of such applications are the MSN Messenger Hotmail notifier and RSS readers. To me, the two true prerequisites for a real user agent world are: Web services/XML - a common means of requesting, retrieveing, and interpreting data. A client-side infrastructure for displaying this information Whilst the first of these is now available, standardisation of schemas is currently one of the biggest problems.  Even RSS, one of the most widely used standards, has several different versions (0.90, 0.91, 2.0), and competition from the likes of Atom.  What the world really needs is standardised ways of representing everything else - personal information, stock quotes, and so on. A larger problem exists in the client-side infrastructure.  Support for platforms besides Windows aside, there is currently no simple way built into the platform of writing such an agent that "integrates" with the environment and other such agents whilst having adequate usability.  If you look at all the agents so far - E-mail clients, RSS Readers, MSN Messenger, whilst there are attempts to integrate all of these things, it's neither controlled nor elegant.  In the future this, problem will be solved with the Longhorn Sidebar, along with MSN-esque popups.  In the meantime, the closest thing I've seen so far is www.desktopsidebar.com; a true framework for integrating various agents that borrows more than a few ideas from the Longhorn Sidebar.  Supporting Messenger, performance monitors, weather feeds, RSS feeds, the obligatory stock quotes, and so on, as well as being a framework for hosting further agents and giving them a UI with which to interact with the user. So, agent technologies are here, they just crept up on us quietly - evolving over time rather than arriving with a fanfare fitting the amount of hype around them. Posted Oct 14 2004, 08:58 PM by jsgreenwood with 1 comment(s) Filed under: Other

• Tool updates

  Long time since my last post - I've been getting ready for and going on a nice bit of pan-European road racing.  The car was getting a fair bit of stick, so didn't make it the full distance, but that's another one to cross off the list of lifelong ambitions. I've now updated both the NUnit GUI and MSI Command Launcher applications. The former has an extra try-catch around an event handler for showing details of errors, because of some weird boundary condition.  The latter now changes directory to where the executable specified to be run exists, allowing it to use relative paths, etc. if it's a batch file. Download URLs are the same as ever: http://www.altervisitor.com/software/NUnit_GUI_Update_Release001.zip http://www.altervisitor.com/software/MSICommandLauncher.msi   Posted Oct 07 2004, 11:20 PM by jsgreenwood with 1 comment(s) Filed under: .NET