Eric, > > Definition of service > --------------------- > > A service is a package of closely related standardized > functions, which are called repeatedly in a similar > fashion, and should therefore be implemented by a > dedicated facility, which can be specialized to > perform them.
What is a 'standardized function'? How is the definition of 'service' any different from the general notion of 'component'? IOW, when do I know that something is indeed a 'service' instead of just a component in the general sense? (Pretty important since the definition of SOA seems to be entirely based on this) > > Definition of SOA > ----------------- > > The architectural style of an application is called > service-oriented if it meets the following criteria: > > It is not monolithic; common blocks of functionality > are broken out of the applications and are instead > provided by services > -- A significant part of the overall functionality is > implemented by services, which exist otherwise > independent of the application > > Design elements for an SOA are: > -- Components: services (can be composites), > consumers, providers > -- Connector type: (remote) service invocations > > Configuration rules for an SOA are: > -- No strict layering (service implementations can use > other services) > -- No centralized control entity > -- Services are designed for shared use, and for use > that may not even have been anticipated at design time > Sorry, but IMHO, all of the above are very vague (except for 'No centralized control entity'[1] maybe). The problem I have with this is that given your definition of SOA I am completely unable to derive any expectations I can make about the properties of a system that 'is SOA'. Nor am I able to verify that a system that claims to be SOA indeed is. To further discussion (not start wars) I claim that There is no difference between a well designed distributed object oriented system and a SOA-style system. They share exactly the same characteristics regarding performance, evolvability, manageability and possible reuse of components. <duck/> Jan [1] Though I wonder if that is really possible, since AFAIK distributed systems usually need some sort of (eventually) centralized name lookup service and from a manageability POV, there should be some centralized form of 'credentials' management (e.g. NIS, LDAP) so they need not be spread across all nodes of a given system. BUT: Any DS expert please correct me! > Definition of service orientation > --------------------------------- > > Service-Orientation is an organizational principle > -- A set of principles for building large systems > -- It is not tied to any particular technology > > Examples: > -- Common “horizontal” services: > Logging, authentication/single-sign-on, systems > management, Directory lookup of services, event > notification > -- “Vertical” services, specific to your business > domain: > Product feature search service, Address management, > Order Status Tracking Service, Truck/trailer tracking > service > > As in organizations, there is always more than one way > to structure a large system > > The most important question: How to decompose? > -- What is the guiding abstraction mechanism? > -- Why would one favor one decomposition for another? > > > and so on... > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > > > Yahoo! Groups Links > > > > > > > ________________________________________________________________________ _______________ Jan Algermissen, Consultant & Programmer http://jalgermissen.com Tugboat Consulting, 'Applying Web technology to enterprise IT' http://www.tugboat.de Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
