Hi Jan, Well, the main point is that a service is not an object. A service is a verb, not a noun. You might have a collection of verbs in a service, which might be part of the confusion. The one quibble I have with the definition we use in our course material is that I usually prefer to define something in the singular. We have defined a service as a group of functions. I would more usually call one of those functions a service, and the group a group of services. So I agree (assuming that's your point) that this definition is a big ambiguous.
I also think one of the biggest problems we are having, at least with technical folks, in the transition from object orientation to service orientation is that people like to equate the two. One way to highlight the difference is to ask some questions. What would you call and SOA built using a message queueing system? There are many of these in production today. How about services that are implemented using procedure-oriented languages? Whenever we talk about service-enabling the mainframe that is most often what we are talking about - COBOL, C, even PL/I can be used to implement a service. So one way to the answer to your question is to consider the level of abstraction necessary to encompass object orientation, procedure orentation, and store and forward systems. A very basic example of a service is a bank. The bank provides services to its customers: withdraw funds, transfer funds, exchange foreign currency, make a loan payment and so on. These services that the bank offers are modeled the same way in a software service. The software system is designed to process a "transfer funds" request. The software system is not modeled as methods on the "funds" object. Similarly, the service oriented view is "get customer" while the object oriented view is "use the get method on the customer object." As I said, this is often very confusing, especially for people who have grown up with object orientation and are not familiar with other types of software systems since it is hard to think abstractly across different orientations when you are familiar with only one of them. I don't know if that's the case here but I can tell you I run into that a lot. One of the biggest challenges for developers and technical people moving toward service orientation and Web services is to understand the difference between Web services and current distributed computing platforms (they are not the same although we might like them to be since there are many similarities) and to keep both systems in mind. I remember clearly when object orientation came into the picture in the early 90s. I realize it had been around in research for a while before then but it started to be implemented in commercial product around that time. The metaphor was the radio. An object was a thing, like a radio, and objects had methods, or functions, which were like buttons on the radio. So you had to first derive the objects to be used in the system and then model their methods. The objects would also encapsulate the data necessary to execute the methods. A service is not an object. A service is a function. The metaphor is the kind of service that a business provides to its customers, or one department provides to another, and so on. You have to first model the data important to the service so that you know what message to send to it to request its execution. The service is responsible for accepting the message and mapping it into an execution environment, which can be a procedure oriented program, a message queue, or an object. The service may return an reply. But the requester knows nothing more than the format of the message and its destination. It does not know the method or program or queue name - that is a local matter. So another way to describe the difference is that whatever properties are specific to object orientation and not shared by procedure orientation or message queue based systems are not in scope. Hope this helps. Eric Eric --- Jan Algermissen <[EMAIL PROTECTED]> wrote: > 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 > > http://groups.yahoo.com/group/service-orientated-architecture/ > > > [EMAIL PROTECTED] > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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/
