This paper introduces a new user-centric service- oriented architecture (UCSOA) that allows end users to compose applications. UCSOA is an extension of.
UCSOA: User-Centric Service-Oriented Architecture Mark Chang, Jackson He, W.T. Tsai*, Bingnan Xiao*, Yinong Chen* Intel Incorporation, USA *Arizona State University, Tempe, AZ 85287-8809, USA Abstract This paper introduces a new user-centric serviceoriented architecture (UCSOA) that allows end users to compose applications. UCSOA is an extension of consumer-centric service-oriented architecture (CCSOA), which is an extension of conventional SOA. The conventional SOA is producer-centric because service providers publish their services and service consumers must search available services to compose their applications. CCSOA is different as it allows consumers publish their needs including workflows and services, and let producers to produce services to meet the requirements. Based on CCSOA, UCSOA provides support for end users. An application builder is an engineer who has both domain and programming knowledge, while an end user has little knowledge on programming and thus UCSOA needs to allow nontechnical persons to compose their applications. This paper presents the concepts, architecture, enabling techniques, and illustrative examples.
1. Introduction Service-Oriented Computing (SOC) including service-oriented architecture (SOA) and Web Services (WS) emerges as a new computing paradigm. Major computing corporations and government agencies are adopting this paradigm. The idea that a program as a service that can be discovered, matched, composed, executed, verified, and monitored at runtime forms the new paradigm. In SOA, service providers register the services at a service broker and the service consumers (application builders) search and discover required services through the broker. Once a required service is found, the service consumer can bind the service into its application. Service collaboration is essential in SOA because a complex service is normally composed of several services. Consumer-Centric SOA (CCSOA) [16] is an architecture designed to support collaboration-oriented service composition. In addition to publishing service
specifications in SOA, workflows and application collaboration specifications are also published in CCSOA for discovery, matching, and subscription. The CCSOA is different from the conventional SOA framework [2][13], in which service providers develop and publish their services, and service consumers (application builders) are responsible to discover the right services published as well as use the services in their applications. This is essentially a producercentric. Specifically, the majority of the current support in SOA is for producers, e.g., the service broker will list registered services, the specification techniques and standards are designed so that service providers may produce the right software for a given specification. There is no corresponding broker for consumers, nor is the corresponding application specification publisher. In CCSOA, consumers publish their application requirements together with associated service specifications including the workflow. Once these are published as application templates, any service provider can submit their software or services to meet the application requirements. This way of computing is consumer-centric because now the service providers will look for application needs from service customers. Even though CCSOA provides a framework for service consumers, there is rarely any support for end users who have little programming background and who are the ultimate customers of services. UserCentric SOA (UCSOA) is a new framework to support end users. Most of the current SOA focuses are centered on providing platform independent services for developers and / or application builders. With web technologies becoming ubiquitous and serviceorientation technologies maturing, a new breed of usercentric services is emerging, e.g., Web 2.0 [11]. The era of user-orientation is dawning on us. Future computing environment and development methodologies will pay more attention to end users and design services directly for them. UCSOA assumes the following facts: • Numerous application services will be made readily available to end users. Examples of such
The research reported here is supported in part by the NSF under Grant Number 03-26606 (ITR).
IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 © 2006
services include calendars service, weather service, and appointmentBooks service. • End users have limited computer knowledge, and they can use web browsers to read news online and use sample applications on the web. Yet they certainly may not have sufficient training in composing applications. • Each end user has his/her own background and interests, and will need different applications accessible from the web browser. Web 2.0 can be considered an important step towards user-oriented computing [11] as it emphasizes on user interaction and data syndication. Some notable Web 2.0 principles include: • Software as operational services: Software will not only be treated as services but also the values of software remain only if it is maintained on a daily basis. • Users treated as co-developers: As software is being constantly updated, user feedback and evaluation will be continuous that users are essentially co-developers of the software. Specifically, new features will be tested by end users at limited sites, and if they are used and liked by users, they will be deployed to all the sites. • Harnessing collective intelligence: Data and services can be created in a collaborative manner via the web. • Lightweight user interface and programming models: Develop software services that are loosely coupled with the rest of applications so that they are easy for reuse and support data syndication. These principles encourage user interaction and allow software services to be used and evaluated by end users. While they also support software reuse by using lightweight programming models, programming is still done by programmers. This paper introduces UCSOA to support end-user oriented application development. Table 1 compares SOA, CCSOA, and UCSOA. Figure 1 illustrates the current situation in which the end users struggle to find services that meet their needs. Enterprise Service Providers
With the advances of SOA specification technologies, it is possible to incorporate the needs of end users into the service specification so that end users can know what service to use and how to use them.
2. SOA Evolution Several generations of SOA techniques have been developed in the last few years [16]: • Initial stage or input/output stage; • Process description stage; • Service collaboration specification stage; and • Consumer-centric specification stage. UCSOA introduces a new service specification stage to the SOA specification evolution, i.e., a usercentric specification stage. In previous stages, application builders are engineers who have programming knowledge and expertise. On the other hand, end users may not have programming expertise, but they know what functions the software must have and how it should be used. In this user-centric specification stage, techniques are needed to support end-users with little programming knowledge to specify applications and services they want to use. The remainder of the paper will focus on the user-centric service specification.
3. UCSOA Framework 3.1 UCSOA Hierarchy The overall UCSOA architecture is a four-layered architecture as shown in Figure 2:
How to use the Services ?
Where to find Services ? Publish Publish my needs and get services directly ?
Broker Public/Private Networks Public Service Providers
Figure 2: UCSOA Architecture End Users
Publish
Re-Package w/ GUI
Discover & Subscribe
Programmers
Figure 1: Needs of User-Oriented Services
IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 © 2006
• Conventional SOA Layer: This layer provides conventional SOA services such as publishing, discovery, and broker services. • CCSOA Layer: CCSOA publishes not only service specifications, but also application templates and collaboration patterns. In CCSOA, all kinds of
solutions are provided for both end users and service providers. • COI (Community of Interests) layer: This is a layer where common solutions related to a specific domain are stored and classified.
Descriptions to be published
Publishing
Discovery and Matching
Composition
Brokers
• End user profiling Layer: Each individual end user has his /her own preferences and behaviors, and thus will result in different applications.
Table 1: Comparison of SOA, CCSOA, and UCSOA SOA CCSOA UCSOA Service descriptions include In addition to input/output and In addition to the method calls, parameters internal process specification, specifications in SOA and (input and output), and service description also includes CCSOA, users can specify internal process specification how a typical customer can use this what types of services they in WSDL or OWL-S. service in various applications or want, service quality missions. It also includes use cases criteria, personal profile and and collaboration patterns. interests, and workflow for service collaboration. Service descriptions in Service descriptions and In addition to publishing service directories such as application templates in the services, collections of UDDI or ebXML. application builders’ directory. related applications are published in Community of Interests (COI) directory. Service consumers Service providers discover the Application builder and (application builders) match services in need and match them service providers discover their services needs with with what they have and what they the needs of end users and existing services in WSDL or can offer. Furthermore, they can provider solutions, OWL-S in the service test their services using the use including application directories or service cases and the collaboration patterns template and services to repositories. given in the application template. match the end users' needs. Use available services to In addition to service composition, End users can compose their compose new services or CCSOA offers to use application user interfaces using dragapplications. Composition is templates to facilitate application and-drop tools and mostly manual at this time, composition. application builders must even though several match or compose their approaches are being pursued interfaces to meet the end for automated composition. users' requirements. Allow service providers to In addition to publishing and In addition to the tasks done publish service description matching services, a broker also by a CCSOA broker, a and, and allow application allows application builders to UCSOA broker allows end builders to perform various publish their service requirements users to publish their search to locate the most and application templates. Store application requirements. suitable services for their not only service descriptions, but applications. also collaboration descriptions and use cases.
Figure 3: A UCSOA Operation Sequence
IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 © 2006
UCSOA provides a framework for end-useroriented service specification, registration, discovery, matching, verification, validation, and composition. An operational sequence in UCSOA is shown in Figure 3. The numbers in the diagram shows a scenario of how an end user uses UCSOA: 1. An end user (solution builder) describes a solution specification which includes information on workflow specification, COI specification, and policies.
2. The solution specification is submitted to a UCSOA service broker. If an existing solution specification associated with registered application is available, the broker will return the application to the end user. Otherwise, the solution specification will be published in the solution specification registry. 3. A service provider subscribed to the solution specification registry is informed the availability of a new solution specification. The service provider can request to support this solution specification. 4. The ontology and standard taxonomy in the COI specification help automatic matching between the solution specification and registered application specification from the service provider. 5. Once the service broker matches the solution specification in its registry with the application specification from service provider, it returns the solution specification details to the service provider. 6. The service provider customizes its service or application according to the detailed solution specification and submits it to the broker. 7. Once an application matches the solution specification is available, the service broker will notify the user (solution builder) that an application is available. 8. Using the binding information from the service broker, the end user can test and evaluate the application based on the solution specification. 9. If the application passes the solution acceptance test, the end user can accept the application, which will make the application to be bound into the end user's solution specification. Once the end user's application is completed, new services can still arrive. For example, as a software service will be maintained and updated on a daily basis according to the principles of Web 2.0, a new service with better performance, functionality, user interface, lower cost may be available after the application is completed. The users can still take advantage of these new services by going through the evaluation process again from time to time. In this way, the cost of owning the application keeps on going down and performance going up as new services become available.
3.2 Publishing Solution Specification in COI In a COI, solutions will be published and classified. An end user can publish, search, and discover a solution specification in a COI. If the related
IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 © 2006
application is available, the user can simply use it. If the solution specification is not available, but a similar template solution is available, the user can customize the template solution. If nothing similar is available, the user can outline a solution specification, publish the specification, and ask service providers to supply the services or applications needed. The entire process can be assisted by the COI supporting services, either manually or automatically. For example, searching an application in a COI can be supported by a powerful search engine that can find the needed application even though the user supplies only a few keywords and/or attributes. Currently, many websites already provide this kind of facilities powered by, for example Google and Yahoo. Composing a solution template can be assisted by drag-and-drop GUI and associated tools so that an end user can compose simple solutions. If an end user wants to specify a specific application, the COI may provide similar specification as a reference to guide the end user to input the proper application specification.
4. Key Techniques in UCSOA 4.1 Communities of Interest (COI) A COI [10] is a place where interested parties can get related information, and each party can contribute to the discussion and share information with each other. In this way, an end user can receive information he/she needs and participate in the dynamic service composition. A COI can provide the following additional services: • Membership management; • Policy specification; • Situation awareness; • Dynamic reconfiguration; • Service mining; and • Data classification. In UCSOA, common applications together with associated services will be represented in solution specifications, and these solution specifications can be stored in ontology so that both users and service providers can search, navigate, and discover applications and their associated services. Applications can be grouped into various COIs according to various trades or professions. The applications and data in COIs can be constantly upgraded and updated. A sports COI example is shown in Figure 4. Basketball COI may contain various applications associated with professional basketball and college basketball so that both users and service providers of basketball can have easy access. When an end user wants to build a new basketball related application,
he/she first submits the request to the COI register to look up appropriate COI that best fits his/her needs. There are different solution specifications stored for a COI and these solution specifications are linked to the application templates registered in CCSOA. End users communicate with COIs only to get the applications they need, and they do not need to know the application details in CCSOA. The solution specifications stored in the COI layer are also ranked according to different criteria, such as: • Ranked by the number of usages; • Ranked by metrics such as reliability, security, fault-tolerance, and performance; • Ranked by user feedback and evaluation; and • Ranked by service availability.
Figure 4: Sport COI Example
4.2 User Personal Profile Specification User personal profile specification provides information of user identification information as well as the preferences on using different services. User personal profile includes following information: • User identity information; • User general profile; • Recent activities records; • User interests information; • User preference information; and • User solution specification. User personal profiles provide user information to the UCSOA framework to better serve the users’ specific needs. With user personal profiles specified for an end user, the UCSOA framework knows what the areas of interest and what preferences are for this end user. Thus, the UCSOA framework can always return most related information to this end user according to the areas of interest and service preference information collected from the user’s personal profile. Different users have different preferences and different behaviors. As a result, even in the same application domain, different users may request different applications. Furthermore, user’s personal profile can be updated after he/she requests and uses a new application. The information will be collected as feedbacks for service providers to improve the services.
IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 © 2006
4.3 Discovery and Matching In addition to the service discovery and matching in conventional SOA and application template discovery and matching in CCSOA, UCSOA also has discovery and matching for COIs and user customized solution specifications. UCSOA discovery and matching is a two-steps process based on COI ontology and collaboration ontology. COI ontology defines an ontology for creating different COIs including domain categorization information. Collaboration ontology is similar to service ontology except the information is about service collaboration rather than service. When a user submits a solution specification request to the UCSOA, the area of interest specification will be matched to the domain categorization information of different COIs based on the COI ontology specification first. After a matching COI is identified, the UCSOA framework will match user specified solution specification to the solution specification stored in that COI. The user defined solution specification will be matched to the solution specifications defined based on the collaboration ontology in the COI layer. Only if the solution specification matches both the COI and collaboration specification of an existing solution specification stored in the COI layer of UCSOA, the applications associated with this solution specification will be returned to the user as he/she requested.
4.4 Verification and Validation in UCSOA Before a service provider or application builder can register an application to support a solution specification published by a user (solution builder), the application needs to be verified and validated by the service broker against the service acceptance criteria. Basically, this evaluates the application against the policies that end user specified in the solution specification. Each UCSOA service broker has a Service Verification and Validation Agent (SVVA) that can verify and validate applications and services. When one service provider or application builder wants to subscribe to a solution specification, the SVVA retrieves the test cases provided by the solution builder or other parties from the repository. Then it needs to perform unit testing on the service being registered. In addition to the testing for functional validation, test agent may need to perform other property-specific testing according to different requirements from the end user (solution builder). Once the unit testing and
property-specific testing are done, a test agent needs to perform the interoperability testing to validate the collaboration capabilities of this service against the policies specified in the user solution specification. Only if the subscribing application passes all the tests, it can be linked to the solution specification. The service providers are still going to maintain those registered services and keep updating their services after the registration. Whenever changes are made to the services, regression testing needs to be performed to validate the revised services. .
4.5 Push-Driven Service Evolution In UCSOA, when a service implementation is accepted to be an acceptable member of a solution specification, the UCSOA infrastructure can maintain the link between the solution specification and the implementations. Because multiple implementations can serve the same specification, the UCSOA infrastructure maintains this one-to-many links from the solution specification to multiple implementations. Similarly, a service implementation may be able to contribute to multiple applications, and the UCSOA infrastructure can also maintain this one-to-many links from a service implementation to applications. If there is a new version or new updates to the service implementations that a solution is linked to, the pushdriven service publication or data syndication can be used to push the new updates to the user solution. The updates are pushed from the bottom layer of the UCSOA framework through CCSOA and COI layers to the end user applications.
4.6 Rapid Application Generation in UCSOA With UCSOA, if sufficient number of COIs, applications, and their associated services are available, together with associated SOSE (ServiceOriented System Engineering) [15] tools, it is possible for an end user to create a large application rapidly. The process for composing a simple application which involved one COI can be outlined as follows: 1. The user submits his/her interest and solution specification to the COIs register to look for an existing COI application that fits the interest; 2. If a COI has existing application template fits the needs of user’s solution specification, the user can simply use the application template to request services in the CCSOA; 3. If an application template largely fits but some customization is needed, the user needs to customize the application template for the new applications;
IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 © 2006
4. The newly submitted services by service providers will be evaluated by the COI/broker using SOSE techniques including simulation, model checking, C&C checking, and testing; 5. As only a few implementations in each application template will be needed, the COI layer can save the implementations in its repository; 6. Once all the service implementations for a new application are available, the new application can be evaluated using SOSE technologies rapidly before deployment. It is possible that an end user needs to compose an application using applications from more than one COIs. The user can first compose applications from individual COIs, and then combine these applications into the final application. The final application will have an overall workflow to specify the coordination of individual applications. The process for composing a complex application can be outlined as follows: 1. List all required simple applications needed for the complex application; 2. For each simple application in the list, compose the application following the previous composition process including evaluation; 3. Specify the overall workflow of the complex application, and link the simple applications to the overall workflow; 4. Once the verified simple applications are linked together to compose the complex application, the new application can be evaluated using SOSE technologies before deployment.
5. UCSOA Example This section uses an online sports trip planning application as an example to illustrate the complex user solution fulfillment in UCSOA. An NBA (National Basketball Association) fans club wants to set up an online trip plan application for registered club members to buy team souvenirs and/or plan their trips to watch away games. The leader of the fans club has no background of programming but she decides to use existing online services to build a new application for this club. With this application, club members can shop online to buy souvenirs such as player jerseys or other accessories of the team they support. They can also use this application to book air tickets, reserve hotels, reserve rental cars, and book game tickets. The overall workflow of this online fans club trip planning application is shown in Figure 5.
Figure 5: Travel Planning Workflow
She starts from searching for online shopping services to be included into the application. To be more specific, she wants to search for an online NBA souvenir shopping service. Thus, she composes an online shopping application as described below: First, she registers in the UCSOA framework and fills in her user identity information such as user ID and password. She also needs to provide her general profile to the registration service such as name, address, and telephone number. For a new user, the recent activities record is initiated as empty and this will be updated after she uses the services. For areas of interest, she fills in NBA and Souvenir as her interest preference. Also, she specifies some policies as her personalized user solution so that the services will always return the merchandise with lowest prices first. She submits her interest profile to the COI server as shown in Figure 6.
application template. By browsing the returned COI description, she chooses one online shopping application template for her use, as shown in Figure 7. The COI server submits an application request to the CCSOA layer with the selected online shopping application template. Since there are many existing online shopping applications for the selected application template registered in the CCSOA layer application registry, she can select a vendor according to the policies she specified in the solution specification. For this example, she may specify the following policies as her vendor selection criteria: • Lowest total price; • Reputation of service provider; • Secure authentication; • Graphic catalog browsing capability; • Merchandise availability; • Payment method; and • Shipping speed. As a result, the online shopping service showing in Figure 8 will be returned to the user for purchasing NBA souvenirs.
Figure 8: Final Online Shopping Service Figure 6: User Submits Request to COI Server
The COI framework queries its registry to look for a COI according to the information submitted by the user. Since the areas of interest are NBA and Souvenir, the COI server returns the Souvenir COI to the user.
After the online shopping application is available, she continues to compose a travel planning application. Following the similar process introduced above, she finds a travel package application in the COI and this application provides a series of services including air ticket reservation, hotel reservation, rental car reservation, and activity ticket booking. The travel planning application as shown in Figure 9 will be returned to the user.
Figure 7: Online Shopping Application Template
There are many different application templates defined in the Souvenir COI including online shopping
IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 © 2006
Figure 9: Final Travel Planning Service
Once these two online applications are composed, the UCSOA framework will evaluate the application using SOSE verification and validation technologies including testing, model checking and simulation. If the applications pass the evaluation, the simple applications will be linked to the overall workflow specification as shown in Figure 5 for the complex travel plan application for a NBA fans club. Then the complex application will be evaluated by the UCSOA framework to verify these two applications can collaborate with each other. Finally, the complex application will be deployed for the NBA fans club to serve the club members. Furthermore, user’s selection of this online shopping application and travel planning application will be recorded in her personal service preference. The activities of using these services will be monitored and updated in the user personal profile. These data will be collected as feedbacks to the online shopping service and travel planning service for service improvement.
5. Summary This paper presented, compared, and contrasted the concept, architecture, and techniques of SOA, CCSOA, and UCSOA. An example is used to illustrate the new UCSOA concepts. This paper also presented techniques that support the new architecture, including user profile description, discovery and matching techniques, verification and validation of the specifications and implementations, and rapid and dynamic application generation through automated code generation. Among the key concepts in UCSOA, COI can greatly improve the service categorization and classification for easy service matching. User's personal profile can facilitate the user-specific customization of the applications. Thus, the quality of applications can be greatly improved in UCSOA.
6. References [1] DARPA: OWL-S: www.daml.org/services/owl-s/ [2] IBM Developer Works, Service Component Architecture, http://www-128.ibm.com/developerworks/ library/specification/ws-sca/ [3] IBM Developer works, Service Data Objects, http://www-128.ibm.com/developerworks/webservices/ library/specification/ws-sdo/ [4] Intel: Service-Oriented Enterprise, The Technology Path
IEEE International Conference on e-Business Engineering (ICEBE'06) 0-7695-2645-4/06 $20.00 © 2006
to Business Transformation. http://www.intel.com/ business/bss/technologies/soe/soe_backgrounder.pdf [5] N. Kavantzas, D. Burdett, T. Fletcher, Y. Lafon, “Web Services Choreography Description Language (WS-CDL)”, Version 1.0, W3C Working Draft 17 December 2004. http://www.w3.org/TR/ws-cdl-10/. [6] F. Leymann, Web Services Flow Language, Version 1.0, May 2001. http://www-306.ibm.com/software/ solutions/webservices/pdf/WSFL.pdf [7] OASIS: ebSOA proposal: http://www.oasis-open.org/ committees/ebsoa [8] OASIS: Business Process Execution Language for Web Services (BPEL4WS), 2003. http:// xml.coverpages.org/bpel4ws.html [9] Object Management Group, Unified Modeling Language (UML), version 2.0. http:// www.omg.org/technology/documents/formal/uml.htm. [10] Object Management Group, Meta Object Facility (MOF) 2.0 Core Specification. http://www.omg.org/docs/ptc/04-10-15.pdf. [11] T. O’Reilly, “What is Web 2.0: Design Patterns and Business Models for the Next Generation of Software”, Sept. 2005, available at http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/3 0/what-is-web-20.html?page=1. [12] R. Paul and W.T. Tsai, “A Real-Time Community-ofInterest Framework for Command-and-Control Applications”, 9th International Command and Control Research and Technology Symposium (ICCRTS), 2004. [13] M. P. Singh and M. N. Huhns, Service-Oriented Computing, John Wiley & Sons, 2005. [14] W.T. Tsai, R. A. Paul, B. Xiao, Z. Cao, Y. Chen, "PSML-S: A Process Specification and Modeling Language for Service Oriented Computing", The 9th IASTED International Conference on Software Engineering and Applications (SEA), Phoenix, November 2005, pp. 160-167. [15] W.T. Tsai, "Service-Oriented System Engineering: A New Paradigm," Proc. of IEEE International Workshop on Service-Oriented System Engineering (SOSE), Beijing October 2005, pp. 3 - 8. [16] W.T. Tsai, B. Xiao, R. A. Paul, Y. Chen, “ConsumerCentric Service-Oriented Architecture: A New Approach”, Proc. of IEEE 2006 International Workshop on Collaborative Computing, Integration, and Assurance (WCCIA), April 2006, pp. 175-180.
[17] O. Zimmermann, Sven Milinski, M. Craes, F. Oellermann, "Second Generation Web Services-Oriented Architecture in Production in the Finance Industry", OOPSLA’04, Oct. Vancouver, 2004
