[service-orientated-architecture] Definitions for SOA

[Gervas Douglas \(gmail\)]

Very interesting debate you have just had about the definition of Services and Applications.  It is not that surprising that unanimity was not reached - it very rarely is in these discussions.  I seem to remember that a call for the definition of SOA produced as many definitions as contributors, and so it was with Web Services as well.   It is not always clear how these paradigms/architectures are born, but I suspect that initially it is as a fairly vague, broad concept which seems to make intutitive sense after a couple of drinks.  The technology is then developed to make the implementation a reality - this helps to produce a more precise definition in terms of technology.  For example, in the early days of WS the question was often asked, "What are Web Services?", to which the answer was sometimes, "SOAP, UDDI and WSDL".  The resulting exasperation was then usually answered with the excuse that it was kind of difficult to describe precisely except in terms of agreed protocols.   Obviously SOA, being an architecture/set of design principles/paradigm/etc., does not lend itself to such a restricted definition.  It seems that we cannot agree easily on definitions of SOA or its fundamentals - why?  I suspect that the reason is simply because it is too early in the game, although we probably share a vague common grasp of the concept.  As implementations and technologies evolve to a useful and discernible state, so the definitions will become clearer.   In the meatime may I suggest we take a different tack?  What is useful and desirable about SOA?  How can we derive strategic benefits from it?  Keith stated a number of desirables relating to distributed application architecture.  No one would argue with those points.  However I would take issue with him about the central importance of reusabillity: modularity and reusability are central to SOA structures.  Why? Well I find it useful to look up the stack towards the business needs.  I don't think anyone would dispute the need for IT systems to become increasingly agile to meet changing business requirements.  Business requirements are becoming more mercurial and the ability to respond in an agile way is seen as more important, if only because businessmen read articles and collateral telling them that this is now their right.   So, let us look above a SOA infrastructure and examine how we are going to implement robust, scalable, agile systems with the minimum delay and cost.  Let us look at Composite Apps, BPM et al. [Please suggest similar relevant factors based on your experience]  May I suggest that keeping in mind these higher needs will help keep us fixed on what is relevant for SOA more usefully than worrying about definitions at this stage?   Gervas YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.