Hello, The following two articles also discuss the different meanings of the word "service", and might be relevant in this context. http://www.cs.vu.nl/~ziv/Assets/papers/2004_ICEC04_service_def.pdf http://www.hpl.hp.com/techreports/2004/HPL-2004-215.pdf Regards, Titi.
Gervas Douglas wrote: >The Subtleties of Service Convergence ZapFlash > >By Jason Bloomberg >Document ID: ZAPFLASH-20051128 | Document Type: ZapFlash > >The word service is one of those general terms that have many >different meanings depending on the context. In different >situations, service is what you get in a restaurant or gas station, >what you're in when you join the army, or what you endure in church. >Web Services, of course, have come to mean something more specific, >namely software services that consist of standards-based interfaces >to IT functionality that one computer system exposes to another. >What, then, is a "software service"? We can define a software >service as any functionality that one computer provides to another, >but this meaning is quite broad. After all, we could be talking >about AOL or email, and we'd still be covered under this loose >definition of service. >It makes sense, therefore, to delineate the various types of >software services, so that we can all make sure we're speaking the >same language. In this ZapFlash we're going to discuss shades of >meaning for the term "software service," not simply as an exercise, >but because there is a convergence taking place in the marketplace >today among the various types of software services. This convergence >promises to be disruptive in many ways, and will flesh out the >principles of Service Orientation beyond the still-emerging world of >Service-Oriented Architecture (SOA). > >Four Kinds of Software Service >First, let's peel back the onion of software services a bit, and >clarify the different types of services: > > > >Software-as-a-service -- IT capabilities that customers can access >as hosted software functionality via thin client interfaces, rather >than by installing applications on their local machines or networks. >The concept of software-as-a-service combines the technology model >for accessing distributed functionality with a business model that >includes charging for that functionality. Good examples of software- >as-a-service are Salesforce.com or the application service provider >(ASP) business model that first emerged in the late 1990s. > >Customer-facing services -- capabilities vendors provide to >customers on an ongoing basis, sometimes with a corresponding >ongoing revenue stream. Such customer-facing services include free >and premium online services such as Yahoo! Mail or AOL. > >IT services -- capabilities that an IT organization provides to its >users. Examples of IT services include corporate email and print >services. > >Loosely coupled Services -- contracted interfaces to software >functionality and data that independent software consumers can >access. The loose coupling depends upon a software architecture >oriented toward such Services, in other words, SOA. These are the >Services -- often Web Services, but not necessarily -- that ZapThink >focuses on. We always capitalize this meaning of the word "Service" >to distinguish them from all the other meanings of the >word "service." >Areas of Service Convergence >You're probably already thinking that there's some overlap among the >types of service we described above. After all, we could easily >consider Yahoo! Mail to be software-as-a-service, and some IT >services (like portals, for example) might also fall into that >category. When loosely coupled Services get stirred into the mix, >however, the story focuses more on convergence than on the various >meanings of a general term. Here are some examples of how loosely >coupled Services lead to the convergence of the different types of >service: > > >Software-as-a-service offered as loosely coupled Web Services -- >instead of requiring thin client interfaces, a wide range of >different types of consumers can now access software functionality >offered over the Internet as remotely hosted, standards-based, >loosely coupled Services, including emerging Rich Internet >Application (RIA) solutions, desktop software applications such as >Microsoft Office, and automated business process flows. When the >provider of such Services leverages SOA to provide loose coupling, >it can offer multiple versions of Services by exposing different >Service contracts, and even route Service requests to the >appropriate Service at runtime. > >"Headless," discoverable IT services -- typical IT services have >rigid, proprietary interfaces. For example, companies typically >implement print services by configuring computers with the >appropriate software, and then provision users to access the >appropriate printers. If printers exposed loosely coupled Service >interfaces to any interested party on the corporate network, >however, then any authorized service consumer could go out on the >network and look for them, learn about them, and access them. They >would then be "headless" in the sense that the print service >wouldn't need its own user interface. Instead, the consumer would >provide whatever UI was appropriate. Such print services were part >of the original vision behind Jini, by the way -- only now, this >vision doesn't require a particular language or runtime environment. > >The rise of the Service marketplace -- originally, AOL's offering >consisted entirely of rich content via a proprietary interface. >Next, they added a Web interface with some Web-based content. Now, >what if AOL or MSN featured Web Services as simply as they currently >offer rich content? Furthermore, what if any desktop application you >were running were able to consume relevant Services from such an >online customer-facing service? For example, AOL could provide >content via a Service that you might consume with a spreadsheet or >other application. Just as the Internet and World Wide Web enabled >the broad distribution of both free content as well as innumerable >business models based on premium content, Service convergence will >lead to an explosion of loosely coupled Services that customers can >consume on a free, licensed, subscription, or per-transaction basis. >The more that companies expose Services for customer use, the more >that companies will want to create such Services. Such a market is >already growing, and approaching what we call the Web Services >tipping point as available Services increasingly compete with one >another for business. >Consequences of Service Convergence >As SOA enables the convergence of software-as-a-service business >models, customer-facing services, and IT services into broadly >applicable, loosely coupled Services, the disruptive nature of this >convergence will lead to many changes, both within IT as well as to >the businesses that leverage such Services. Here are some of the >consequences that Service convergence will have within IT in >particular: > > >Convergence of SOA management and other forms of management -- in >one corner we have IT service management (ITSM) and business service >management (BSM), and in the other corner we have SOA management. >ITSM is now reasonably mature, as companies currently have the tools >and best practices to effectively manage IT services. BSM is less >mature, partly because both enterprises and vendors still struggle >with aligning business needs with IT capabilities. Meanwhile, SOA >management, the logical evolution of Web Services management, helps >companies manage their SOA implementations. As the different types >of services converge, however, SOA management will subsume both ITSM >and BSM, breathing new life into BSM by more closely tying business >needs with IT resources. > >The rise of the RIA -- RIAs leverage approaches like Asynchronous >_JavaScript and XML (AJAX) and Flash to get the best of both >graphical user interface (GUI) worlds -- thick client capabilities >with thin client maintainability. While the most obvious benefit of >RIAs is their rich GUI capabilities, far more exciting to us is >their ability to be flexible, modular Service consumers. Think >portlets on steroids -- instead of trying to combine access to >diverse enterprise applications using traditional, rigid portal >technologies, RIAs provide the technology for building a new class >of Service-oriented consumer to a wide variety of converged >Services, leveraging the loose coupling of SOA. > >The evolution of the traditional desktop application -- taking the >combination of RIAs and the converged world of Services to the next >logical step, the days of a desktop application as an isolated, >unchanging, and discrete piece of software are numbered. It will no >longer matter which parts of the application are local, and which >are remote via software-as-a-service. Whether pieces of the app are >browser-based or browserless RIAs will also become irrelevant, and >even the features shipped with the product on day one will simply be >the starting point for what the product can offer the user over >time. Users will essentially be able to assemble applications as >they require out of abstracted Services that may either be local or >remote. So, welcome to the new, Service-oriented desktop application >of the future! >The ZapThink Take >There is already substantial buzz in the marketplace about the >convergence of the various kinds of service into a single, SOA- >supported ecosystem of software-based Services. This convergence >promises to be disruptive, both within IT as well as in the business >world. If the companies that choose to build their businesses on >converged Services get this convergence right -- in particular, by >basing it on SOA -- then they will truly have a bull by its horns. >If they drop the ball on the underlying architecture, however, then >the benefits of service convergence detailed above will still be >largely out of reach. > >Unfortunately, there is a substantial danger that this convergence >of service types might not happen at all. After all, leveraging the >power of SOA to achieve such convergence is disruptive in the sense >that businesses will themselves transform, and many will fail simply >trying to get their own architecture house in order. Therefore, such >convergence represents already signs of advancement for companies >deploying SOA solutions with and outside their organizations. As >Service convergence takes place, the real action will be how this >convergence impacts relationships between companies, and between >organizations and consumers. The buzz will likely not center on SOA >specifically, but SOA will necessarily be in the background making >the convergence work. In order for companies to realize value that's >more than simply the next version of AOL or MSN with a smattering of >disconnected services or the next version of a desktop-installed >enterprise print service app, companies must leverage the power that >SOA offers in order to make true service convergence, in all its >definitions of the word, a reality. > > > > > > > > > > >Yahoo! Groups Links > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Get fast access to your favorite Yahoo! Groups. Make Yahoo! your home page http://us.click.yahoo.com/dpRU5A/wUILAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
