1. Chair for Communication Technology (ComTec), Faculty of Electrical Engineering / Computer Science Service Creation What’s the issue ?? Keynote @ WAWC’07 Dr. Olaf Drögehorn Lappeenranta, August 16th, 2007

2. © ComTec 2007 Dr. Olaf Droegehorn 2 Vision of ubiquitous computing

3. © ComTec 2007 Dr. Olaf Droegehorn 3 Technologies Markets Users Market players Licenses and regulation Business models Billing and pricing Competition Operator strategies Fight between standards Standardisation bodies Networks Terminals Software tools Content management Security User needs Service delivery Types of services Cost of services Content Ease of use Personalisation Privacy Security Drivers and barriers! Technologies, markets and users

4. © ComTec 2007 Dr. Olaf Droegehorn 4 Devices User interface Capabilities Development platform Network interface Heterogeneous networks xDSL Mobile networks Bluetooth IEEE 802.x Digital TV or radio … Market players Telecom operators Other network operators Broadcasters Content providers Content aggregators Service providers Payment providers Contentmanagement SoftwareAPIs Terminals Payment Security Quality-of-service Networks Personalization Privacy Digitalrights User needs : To communicate To form communities To be informed To be entertained To be efficient To feel secure To feel capable and “in control” To be educated Services: Putting technology to work … Services exist, because they fulfill a need or solve a problem for the end users A good service must be designed for the target users and the context of use - and be user-friendly! How can we make use of present and future networks, terminals and software to address specific user needs? Who are the stakeholders of a service? Content server (database) Mobile phonesPDAsPCs / Internet Digital TV Networks Content provider Content aggregator Network operator Service provider (Mobile) end users Regulator Payment provider Equipment producer Services and networks - the big picture

5. © ComTec 2007 Dr. Olaf Droegehorn 5 The Challenge for the Future of Communication Service (Creation) So, what shall we do, now that we can do everything? Bruce Mau, Author of “S,M,L,XL”

6. © ComTec 2007 Dr. Olaf Droegehorn 6 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

7. © ComTec 2007 Dr. Olaf Droegehorn 7 What is a Service ? An application ? A piece of software ? An outcome of a process ? => There are many definitions (business, economics, technologies, etc.) => Something, that fulfills a need (for help, for fun, for communication) => Is UMTS fulfilling ANY need at all ?? ;)

8. © ComTec 2007 Dr. Olaf Droegehorn 8 Things that can make a service fail There is no need for the service –If nobody uses the service, the whole thing is a failure The user interface doesn’t work –Bad navigation design, bad graphics The service is too slow –Content / bandwidth ratio, application doesn’t respond The service is unreliable –Application crashes! Blank screens, hangs, resets –Data is not up-to-date, e.g. yesterday’s weather –Transactions fail - what happened to my order? The service is insecure –Personal data compromised, money disappears The service isn’t used - boring concept

9. © ComTec 2007 Dr. Olaf Droegehorn 9 Understanding a need Example: Just want to get out …. –Looking for „EXIT“, or similar –Arriving here, you find:

10. © ComTec 2007 Dr. Olaf Droegehorn 10 Service Creation challenges Josef: There are no services, why ? Why is Service Creation so difficult ? –Maybe we are expecting THE service (like the killer-application) –We are NOT developing variations (like product-designers do) –Most services are developed from scratch (Users don‘t recognize elements/widgets, therefore we try to enhance an already available service) –We are not reusing existing codes/technologies/widgets/platforms

11. © ComTec 2007 Dr. Olaf Droegehorn 11 Service Creation, why do we need to talk about it ? User needs are not addressed Software service creation lifecycles are by far too long –Most services are developed from the scratch Service composition is proprietary, at best Ease the life of professional software developers Ease the life of providers/operators Enable „non-professionals“ to create their services => Each and every user should be able to create services

12. © ComTec 2007 Dr. Olaf Droegehorn 12 Why should EVERYBODY do that? Looking to the web: –HTML was for specialists only –Nowadays everybody has a web-page/blog New hype: –User generated content (for the web) –Flickr, LifeBlog, etc. Next trend: –User customized services –Google Mash-Ups

13. © ComTec 2007 Dr. Olaf Droegehorn 13 Why should we do that ? SMS was never meant to be a product/service –By using it, it formed a hype Because people like to separate from each other => The idea is to enable everybody to improve/customize and generate services

14. © ComTec 2007 Dr. Olaf Droegehorn 14 Variations are needed - IKEA (Users like to have the choice)

15. © ComTec 2007 Dr. Olaf Droegehorn 15 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

16. © ComTec 2007 Dr. Olaf Droegehorn 16 „I wish to concentrate on improving my services functionalities, and not anything else...“ The service creation problem for Service developers

17. © ComTec 2007 Dr. Olaf Droegehorn 17 „There must be some simple ways to put all the functionalities together as ready- to-sell services...“ The service creation problem for Service providers

18. © ComTec 2007 Dr. Olaf Droegehorn 18 „Is it possible for me to customize service with functionalities that i wish to have?“ The service creation problem for End-users

19. © ComTec 2007 Dr. Olaf Droegehorn 19 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

20. © ComTec 2007 Dr. Olaf Droegehorn 20 Service Creation Vision A world of services that are… Easy to create, Easy to share, Easy to use, …and still user-centric! …and still user-centric!

21. © ComTec 2007 Dr. Olaf Droegehorn 21 Service Creation Vision (2) Easy to create  –Creation tools and publishing Service taxonomies Reuse of existing services and components Semantic orchestration of components and loosely coupled approach Easy to share  –Generalised client-server architecture « My server in my pocket », « My server at home» Service deployment in just a few clicks Semantic based publishing Easy to use  –Semantic Service discovery Fine grain semantic-based search Interoperability, composability of services

22. © ComTec 2007 Dr. Olaf Droegehorn 22 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

23. © ComTec 2007 Dr. Olaf Droegehorn 23 The classical way to think about services Domain-Specific Software Architectures (DSSA) Build a specific „platform“ for a specific domain

24. © ComTec 2007 Dr. Olaf Droegehorn 24 Domain-Specific Software Architectures (DSSA) DSSA definition –„a context for patterns of problem elements, solution elements, and situations that define mappings between them“ (Software Engineering Institute, 1990) Comprises a couple of crucial artifacts –scenarios –domain dictionary –context and entity/relationship diagrams –data flow, state transition, and object models –functional- and non functional requirements –…–… Problem: DSSA is still driven by technology

25. © ComTec 2007 Dr. Olaf Droegehorn 25 Service Categorization today with regard to DSSA Source: UMTS Forum, http://www.umts-forum.org A typical DSSA just reflects these typical technical enablers

26. © ComTec 2007 Dr. Olaf Droegehorn 26 Domain specific platforms The issues are NOT new The whole middleware hype was targeted to this Build once, use everywhere Why not simply using THE platform ?

27. © ComTec 2007 Dr. Olaf Droegehorn 27 Middleware supports applications Application Middleware Device Middleware provides homogeneous API to applications By providing services that bridge between homogeneous and heterogeneous API To shorten time-to-market for applications To abstract from heterogeneity and allow applications to be executed on future mobile devices

28. © ComTec 2007 Dr. Olaf Droegehorn 28 The original goals of platforms & middleware Masking heterogeneity –networks, end-systems, OSs, programming languages Providing a useful distributed programming model –simplicity with generality CORBA, Java RMI, etc. have been very successful in this... business applications; wrapping of legacy systems...

29. © ComTec 2007 Dr. Olaf Droegehorn 29 The concept of middleware is used more widely Platforms were built for many different domains, like: Applications –eCommerce, 7x24 back-end servers –eScience –real-time, embedded systems –mobile agent systems –peer to peer platforms –mobile computing applications –telecomms/ programmable networking Underlying systems –PCs/ workstations –supercomputers –wireless PDAs –embedded devices –network processors –wireless, sensor, infrared etc. networks

30. © ComTec 2007 Dr. Olaf Droegehorn 30 A victim of its own success? CORBA tries to cope... –add asynch., transactions, fault-tolerance, persistence, components, load balancing, logging, real-time/ embedded/ lightweight CORBA,...  complexity and unmanageability prototypes arise to fill the gaps & to have smaller solutions –asynchronous platforms (pub-sub, eventing, message queueing) (MSMQ, JMS, JavaSpaces,...) –Grid middleware (Legion, Globus, OGSA,...) –web services (SOAP, WSDL, WSFL,...) –mobility middleware (Rover, MOST,...) –mobile agent systems (Tacoma, Aglets,...) –peer-to-peer (JXTA, Jtella,...) –real-time/ multimedia platforms (ReTINA, DIMMA,...) –etc. different assumptions, paradigms, models, implementation environments,...  incompatible platforms, no cooperation, no reusability!

31. © ComTec 2007 Dr. Olaf Droegehorn 31 Result: Many platforms for different disciplines

32. © ComTec 2007 Dr. Olaf Droegehorn 32 Ending up in technology silos Source: UMTS Forum, http://www.umts-forum.org A typical DSSA just reflects these typical technical enablers

33. © ComTec 2007 Dr. Olaf Droegehorn 33 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

34. © ComTec 2007 Dr. Olaf Droegehorn 34 A better way to think about services ? Semantic-Driven Software Architectures (SDSA) Design a service without technology in mind

35. © ComTec 2007 Dr. Olaf Droegehorn 35 SDSA: Understand Services beyond Technology 1.No biased interfaces _keyboard/mouse, voice, gestures, touch display 2.No limiting form factors _mobile phone, notebook, desktop, PDA, smart phone 3.No usage constraints, i.e. _Unlimited power supply _Bandwidth abundance _Workflow convenience: no/short login, no hardware break-down, full-fledged transparent security,... 4.No prejudice about network connection (fixed vs. wireless) … but describe precisely the context, services are being used

36. © ComTec 2007 Dr. Olaf Droegehorn 36 Domain-Specific vs. Semantics- Driven Software Architectures DSSASDSA can be an assemblage of software components focuses on describing the problem domain wants to be unambigiousmakes contradictions a valuable design principle usually has a bias on device form factors and interaction paradigms is open to device implementation and interaction design just refers to an unambigious terminology makes usage of the terminology a central feature of service specification attempts to generalize for the purpose of a reference design is specific to understand one specific problem domain

37. © ComTec 2007 Dr. Olaf Droegehorn 37 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

38. © ComTec 2007 Dr. Olaf Droegehorn 38 Activity Theory

39. © ComTec 2007 Dr. Olaf Droegehorn 39 Understanding a service comprises more than workflow specification Rules Icons instead of text Community Assembly assistants IKEA complaints hotline Subject Outcome Object Tools Division of Effort Assemble Explain, not assist From individual activities to Activity Systems

40. © ComTec 2007 Dr. Olaf Droegehorn 40 SMS acts as a mediating artefact of an Activity System Object Division of Effort Subject RulesCommunity Tools Outcome Register for service Pay per text Mobile providers Possible senders/receivers Store and forward text Charge for service Sender Receiver Create & send limited text Receive text Text delivered Text received T9 keyboard Display Activity Systems as a core idea for real- world services (here SMS)

41. © ComTec 2007 Dr. Olaf Droegehorn 41 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

42. © ComTec 2007 Dr. Olaf Droegehorn 42 The Wireless World Research Forum WWRF, founded in 1998 (from WSI & EU-FP5 Project) Working Groups trying to draft future research issues Definition of a reference model of User- centered communication (I-centric) WhitePapers on specific topics

43. © ComTec 2007 Dr. Olaf Droegehorn 43 Terminals Devices and Communication End Systems Service Platform Generic Service Elements for all layers Service Semantic Wired or wireless Networks IP based Communication Subsystem Business Model Networks IP Transport Layer Network Control & Management Layer Service Support Layer Service Execution Layer Application Support Layer Service Bundling Service Control Service Discovery Service Creation Environment Monitoring Service Deployment Conflict Resolution Ambient Awareness Personalization Adaptation User Model & Appl. Scenarios Communication Space (Contexts & Objects) Reference Model for I-Centric Communications

44. © ComTec 2007 Dr. Olaf Droegehorn 44 WhitePaper on Service Creation A WhitePaper to highlight open issues, existing technologies & approaches –Technology driven service design vs. Technology agnostic approaches –Existing Software Development Environments (IDEs) –Business models for Service Creation Identified need for: –Harmonization of tools & semantics –Technology agnostic/independent way of serivce design/description –Common semantics –Common understanding of technology enablers (like OSA/Parlay, ParlayX, IMS, etc.)

45. © ComTec 2007 Dr. Olaf Droegehorn 45 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

46. © ComTec 2007 Dr. Olaf Droegehorn 46 Semantic Service Discovery Technology agnostic Everyone can define own services „Draw a service“ - Simplified service creation process One idea for service creation

47. © ComTec 2007 Dr. Olaf Droegehorn 47 The S4ALL approach Rule „Draw a service“ - Simplified service creation process

48. © ComTec 2007 Dr. Olaf Droegehorn 48 Rule Business Rules Rule Evaluator State Services Action Services

49. © ComTec 2007 Dr. Olaf Droegehorn 49 Service Building Blocks (SBB) State SBB: Read status to enable reacting on state changes. Also from Context Providers, which enablers to easily create context aware mobile services Action SBB: Trigger actions on services at mobile device, in the home environment, in the Internet Rules connect State SBBs and Action SBBs

50. © ComTec 2007 Dr. Olaf Droegehorn 50 Time Afternoon Location LasVegas Start Presentation & Icomp_2007.ppt Business Rule Example

51. © ComTec 2007 Dr. Olaf Droegehorn 51 WI-Platform Business Rule Evaluator MoodTime Game Time State ServiceBB Mood State ServiceBB Game Action ServiceBB Rule Evaluator Business Rule Example (2)

52. © ComTec 2007 Dr. Olaf Droegehorn 52 Contains following components Rule Evaluator (Info.) Collector Service Triggering Rules State info. (from service) Output Action Service(s) Rule Reasoner Rule Repository Rule Evaluation

53. © ComTec 2007 Dr. Olaf Droegehorn 53 Selection of the Business Rules approach Model-Driven-Architecture (MDA) approach for service design: Create a graphical model of the service Business rule engine approach very common for connecting bigger building blocks. Enables straightforward data flow design. Make it easy for the service developers, not giving the power of a programming language Especially for Web service connection (state and action service building blocks provide Web service interfaces) this approach fits perfectly The ease and power of the approach depends on the provided service building blocks. They have to enforce the „Service- oriented architecture“ approach

54. © ComTec 2007 Dr. Olaf Droegehorn 54 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

55. © ComTec 2007 Dr. Olaf Droegehorn 55 Semantic Service Delivery Platform SDF Semantic Descriptions SemSDP IDE Extension Service Creation Workbench deploys publishes SCE Semantic Descriptions SEE Semantic Service Discovery Business Rules Execution Service Building Block Execution Engine Triggers Service Delivery Platform

56. © ComTec 2007 Dr. Olaf Droegehorn 56 Service Creation Workbench Scenario shown: Play video on user’s mobile device when he/she passes a certain location

57. © ComTec 2007 Dr. Olaf Droegehorn 57 Rules, Facts, and … State SBB Converter Action SBB Atom

58. © ComTec 2007 Dr. Olaf Droegehorn 58 The S4All Environment Service Creation Workbench Service Discovery WizardRule EditingDeployment GUI SEE InterfaceRule editor GUIRepository SearchSyntax/Semantic Discovery State Service Building Blocks Business Rules Action Service Building Blocks State/Context Sources Actions Service Execution Environment Execution EnvironmentDeployment InterfaceSubscription Management User SubscriptionsBusiness Rule EngineCRUD Services state request evaluationtriggering discover CRUD Repository Building Blocks Rules

59. © ComTec 2007 Dr. Olaf Droegehorn 59 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

60. © ComTec 2007 Dr. Olaf Droegehorn 60 Evaluation (1) The SCW makes creation of new services very intuitive => enabling the combination of state information from user’s environment (“context”) with action triggering Our exemplary scenarios show that using the S4ALL tools significantly improves the process for developers to create mobile services Service building blocks can be reused Service logic is easy to grasp through its graphical representation Service logic can easily be updated Deployment requires “one-click”

61. © ComTec 2007 Dr. Olaf Droegehorn 61 Evaluation (2) The tools need a suitable SEE Rule Evaluation is a common task and is very well supported The approach can be used by operators as well as End- Users A larger test-case will be done in a European Project (IST- SPICE) A set buidling blocks will be provided soon, for a specific SEE (WI-P) as open source

62. © ComTec 2007 Dr. Olaf Droegehorn 62 Outline The problem of service (creation) What might people want (depends on the role) The vision of Service Creation The old way of service creation A new way of service creation Activity Theory WWRF WhitePaper on Service Creation An example how to do user-driven Service Creation The Service Creation Workbench Findings from the example Conclusion

63. © ComTec 2007 Dr. Olaf Droegehorn 63 Conclusion (1) Services are not really there Service design/creation is technology driven Many solutions don‘t serve a need –Develop some solution and try to sell it as a service (MMS) A lot of people were looking for THE service Software-Development tools are out there, but how to build a service with them? No harmonization in tools and semantics No service design, but technology push

64. © ComTec 2007 Dr. Olaf Droegehorn 64 Conclusion (2) An easier process for rapid service creation is needed Easy service composition / customization is needed (to build variations) Tools need to be harmonized to use existing enablers (let‘s use IMS meaningfully) Business opportunities need to be exploited => Find more in the WWRF-WhitePaper

65. Chair for Communication Technology (ComTec), Faculty of Electrical Engineering / Computer Science Thank you ! droegehorn@uni-kassel.de