--- In service-orientated-architecture@yahoogroups.com, Michael Poulin <[EMAIL PROTECTED]> wrote: > > Alexander, I have several notes just to bridge vocabulary: > > 1. "a service is what a servant do, not what the servant delivers" - I would add "and how". A service using a database with only 2 concurrent connections may pretend to be not more than a 'service-let', right? (like applet) > > 2. About service in a box, how do you classify a plumber coming to your house in a lorry? Do you recognize that te service was delivered to your home by another service (lorry)?
SOA can be viewed as a flat hierarchical client-server model (is this an oxymoron? - possibly) whereby a service can be a client to another service. If the plumber is coming to your house in a lorry, then the plumber can be viewed as a client of the lorry's delivery service. He is also liable to land you with a very hefty bill if he needs a lorry. :) > > 3. "A service is a conceptual representation of a need" - according to OASIS SOA RM, a service is a representation (or means) od capability which totally decoupled from the need. Would it not be more logical to view the service as fulfilling the need in question? Gervas > > 4. "A product is a physical representation of a service" - I have a problem with this. I remember old time when business managers were very skeptical about SW as a product because they could not touch it... > > 5. " but call them Web Service products (because they deliver something > real, i.e. byte streams)" - I need to understand how an interface can deliver anything; an interface can 'move through' but implementation of the interface, i.e. service body, provides. Am I wrong? > > 6. "The Architecture bit is where I design the SOA with these conceptual bits of given *type* and tie them into the actual implementations." TOGAF talks about 4 areas of architecture, you are talking about Technology area only. Talking about SOA, I would concentrate on the "SO" first, then you will see how it its into all architectural areas > > 7. About coding, there may be a lot of recommendations and guidelines. I, personally, usually point to TOGAF: model your task first by separating functionality (business arch.) from user activities (application arch.), from data (information arch. ) from implementation packages like EJB, JMS, JNDI, etc. (technology arch.). If you stay away from OO you will have less chances from making mistakes in SO. > > - Michael > > > > ----- Original Message ---- > From: Alexander Johannesen <[EMAIL PROTECTED]> > To: service-orientated-architecture@yahoogroups.com > Sent: Wednesday, June 11, 2008 10:53:21 AM > Subject: Re: [service-orientated-architecture] Re: Definition of SOA > > > On Tue, Jun 10, 2008 at 21:06, Michael Poulin <[EMAIL PROTECTED] com> wrote: > > Now, from the sick head onto the healthy one, what the h... is a service? > > What is a relationship between services? And we are starting from the scratch. > > :) Boy, this can go on forever. > > My thoughts on all this (and I've waited a while with jumping in here) > is that a service is what a servant do, not what the servant delivers. > There is that old difference between a service and a product, where > the service is something you can't wrap in a box and ship which for me > often works in the way I design system, but I realize that this goes > against many people's idea of what it is (including people I work > with). Here's my definitions, strictly in terms of software systems ; > > - A service is a conceptual representation of a need > - A product is a physical representation of a service > > Let me try to explain how I see and use this. I'm at work and under > tight deadlines, so I'll ramble a bit in haste ; > > I don't use the moniker "Web Service" at all in the traditional sense, > but call them Web Service products (because they deliver something > real, i.e. byte streams). Hence, Service Orientation is the ability to > conceptualize my solution space, free from the constraints of needing > end-points, databases, specific software implementations, systems > design, or any other guiding proclamation. The Architecture bit is > where I design the SOA with these conceptual bits of given *type* and > tie them into the actual implementations. > > SOA for me is the way I think about my problem-space conceptually as > opposed to any implementation specifics. I often try to explain this > by saying that SOA is the big, big mama of DDD (Domain Driven Design). > A lot of software people are aware at least of driving software > implementations by designing it to somehow mimic reality, so if you > have a couple of warehouses in your organization, you're most likely > to design a couple of objects that mimic them, to get to Array > $warehouses[ ] = new Array ( new Warehouse ( "New York" ), new > Warehouse ( "Los Angeles" ) ) ; > > By experience, though, there's a large risk of hard-coding your > structure in your software in such a way as to make it really > expensive to change it, so concepts are sorted into two piles; > generics and specifics. *This* is the Architecture part. Generics are > modeled as a shareable space, and specifics are modeled as > implementation (and handled in the usual ways as implementation are), > having as little specifics as possible. > > SOA for me is ; > 1. Services are needs and parts of the solution-space > 2. Orientation is conceptualizing services and relationships without > technical constraints > 3. Architecture is typifying and modeling the above, preparing and > mapping for implementation by others > > Other times I just say "SOA is to systems design what the Program > Manager is to project management", given you know what a program > manager (http://en.wikipedia .org/wiki/ Program_manager) is. :) > > Mvh, > > Alexander > -- > ------------ --------- --------- --------- --------- --------- - > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > ------------ --------- --------- --------- --- http://shelter. nu/blog/ -------- >
