Modeling Web Services Variability with Feature Diagrams Silva Robak, Bogdan Franczyk Institute of Computer Science and Management University Zielona Góra ul. Podgorna 50, PL-65-246 Zielona Gora, Poland
[email protected]
Universität Leipzig Wirtschaftswissenschaftliche Fakultät Institut für Software und Systementwicklung Lehrstuhl für Informationsmanagement Marschnerstr. 31 D-04109 Leipzig
[email protected]
Abstract. In the paper the proposal for modeling flexibility of the Web Services with feature diagrams is introduced. Feature diagrams allow presenting the commonality and above all variability of described concept. In the paper the classification of Web Services features from the users' point of view is given. The comparison of Web Services with the orthogonal component concept is also discussed.
1 The Notion of the Web Service 1.1. Properties of Web Services In [Oe01] the definition of the Web Service is given as: “any process that can be integrated into external systems through valid XML documents over Internet protocols”. XML is used to define the payload (i.e. data transferred between processes during execution) of a Web Service. The definition in [Ca01] is more comprehensive and includes all Web Service significant features: “Web Services are modular, self-describing applications that can be published, located and invoked from just about anywhere on the Web or a local network. The provider and the consumer of the XML Web service do not have to worry about operating system, language, environment, or component model used to create or access the XML Web service, as they are based on ubiquitous and open Internet standards, such as XML, HTTP, and SMTP”. Further is stated that XML and
SOAP are the base technologies of Web Services architectures. The Web Services communication technology options are summarized in the Fig. 1., containing the communication architecture subcomponents: Consumer, Transport and the Service. The Consumer denotes the entity utilizing the Web Service, the Service is a provider of the Web Service and the Transport defines the means for the communication of Consumer while interacting with a Service. The communication for Web services specifies two layers (i.e. network and transport) in ISO-OSI reference model. The definition of the Web Service is not uniform, caused by the facts, that proprietary descriptions use their own definition of the Web Service, as summarized in [Je online] with definitions from W3C and WebServices.org and other sources as Intel, IBM, SUN, Microsoft, Hewlett-Packard (HP), Globus Project, Gartner Group. The characteristic features of a Web Service are further that they are: immaterial, transient (i.e. not feasible to stock), position dependent (not viable to transport) and that synchronize producer with consumer immediately [Je02]. The Web Services are much more then just System Integration because they are providing services (not just connecting systems), they are neutral (i.e. not dependent on a special programming paradigm) and the cooperation proceeds in ad hoc manner (as opposite to long lasting cooperation). WS architecture contains at least three roles: Service Provider, Service Requester and Service Broker, with the responsibilities: publishing (Service Provider to Service Broker: WSDL), finding (Service Requester to Service Broker: UDDI) and bind & execute (between the Service Provider and Service Requester: SOAP). The WebServices.org defines Web Service as encapsulated, loosely coupled contracted functions offered via standard protocols. The standard-based communication allow accessing the services independent of hardware, operating system or programming environment, i.e. are programming language-, programming model- and system software neutral as underlined by Globus Project and HP. Gartner Group also emphasizes the aspect of Web Service as loosely coupled software components delivered over Internet standard technologies. The IBM definition underscores just-in-time application integration aspect and the possibility of their dynamically changing by the creation of new Web Service. The Intel definition emphasizes the ability of performing ‘distributed computation’ with the ‘best-matched device for the task’ and the information delivery on a ‘timely basis’ in the form needed by the user. Some definitions refer to the Web Services as ”modular and reusable software components” (Hewlett-Packard), or “ loosely coupled software components” (Gartner Group). Web Services combine the best aspects of component-based development and the Web (Microsoft) and also define a technique for describing software components (Globus Project). So, Web Services just form the orthogonal concept to the components notion including their key features as providing the functionality as black box with described and published interfaces. In the paper the aspects comparing the concepts of Web services and components are the topic of section 1.2. In section the sources for variability contained in Web services are given together with an approach for presenting this variability within the feature diagrams. In section 3 we conclude our work.
1.2 Web Services vs. Components In [Co02] is contained the opinion, that the main problem is not what Web Service are, but how to use them, with setting the goal as easier and more productive reuse of existing assets. The recent trends include: - Larger level of granularity, - Reduced effort required to reuse code, - Increasing breadth of scope (internet and industrial standards), - Increased focus on information (use of XML for the payload), - Transformation between proprietary and industry standards, - Reduced effort required to use of Web Services, - New level of interoperability. Considering this characteristics one can say, that Web Services are the natural consequence in the reuse succession containing classes, components and finally Web Service. The reuse tendency first shifted from objects (i.e. classes) to delivery-and deployment unit of higher granularity i.e. components [Sz98]. Most reduced effort required to use the units and to reuse code is also in case of Web Service. It is caused not only by larger level of granularity of Web Service, but also through the existence of the appropriate services allowing finding and discovering Web Service (UDDI, WSDL). They offer just much more than only standard interfaces. In [Ti01] are some other trends given, supported by Web services being able to be intelligently process, manipulate and aggregate content: - Content becomes more dynamic, - Decreasing costs for bandwidth and storage, - Increasing importance of pervasive computing. The Web Services are also capable to enrich the organization business by among others [Co01]: - Delivering more affluent e-business applications, - Run virtually enterprises with more efficient supply chains, - Grouping products and (software) services. Loosely coupled services may widely support the B2B collaboration. Another difference between the component and Web Service is their service-oriented architecture containing three (main) roles: producer, consumer and broker. An operating agent delivers the service to some clients. The runtime environment (with such features as scalability, reliability, security, etc.) should be based on highperformance application server or message broker. According to [Sz01] the Web Service is a pairing of an operation agent (with it’s infrastructure) with software components rather then with arbitrary software. The extreme dynamic nature of Web-based systems includes the specific fact that their parts will evolve separately. As opposite to Web services the features of a separate software component according to [Sz01] are subsumed in following way: - It provides functionality through well defined standards,
-
It contains a full declaration of its static dependencies, Is equipped with explicit configuration mechanisms (required interfaces as opposed to the more traditional provided interfaces), - Is equipped with version identification. As stated in section 1.1 the Web Services just form the orthogonal concept to the components notion with such common properties as providing the encapsulated functionality as a loosely coupled black boxes with described and published interfaces.
2 Describing Web Services with Feature Diagrams 2.1. Feature diagrams A feature is a visible characteristic of concept (e.g. system, component, etc.), which is used to describe and distinguish different instances of the concept. The feature model indicates the intention of the described concept. The set of instances described by feature model is the extension of the concept. This model is particularly important in situations, where a generic description for a range of diverse systems is needed. In case of Web Services a feature diagram may describe a generic concept, which can be further dynamically, customized do profiles’ consumers. Upon an established base in form of commonalities and the differences specified to this base, a speedy automated creation of Web Service version for a customer would be possible. FODA [Ka90] feature models are the means to describe mandatory, optional, and alternative properties of concepts within a domain. The most significant part of a feature model is a feature diagram that forms a tree (graphical AND/OR hierarchy of features) and captures the relationships among features. A root of the tree represents a concept being described and the remaining nodes denote features and their subfeatures. Direct features of a concept and sub-features (i.e. features having other features as their parents) are distinguished. Direct features of a software system may be mandatory, alternative, or optional with respect to all applications within the domain. A sub-feature may be mandatory, alternative, or optional with respect to only the applications, which also enclose its parent feature. If the parent of the feature is not included in the description of the system, its direct und indirect sub-features are unreachable. Reachable mandatory features must be always included in every system instance an optional feature (denoted by empty circle) may be included or not, and an alternative feature (denoted by empty arc) replaces another features when included. In the GP (Generative Programming) feature diagrams notation [CE00], that seems to be the present most popular feature diagram presentation, there is an additional (compared to FODA) kind of features introduced i.e. or-features (denoted by filled arc) representing multiple choices in the alternative. In the following section the GPfeature diagrams will be used to describe the commonality and variability contained in the Web Services technology and service models.
2.2. Variability of Web Services Web Services may be exposed to a large pool of users, as well mix and match services from other providers to build a variety of applications. The further sources of variability of WS are: - Number of participants (e.g. in an application chain with multiple partners), - Participants’ level of involvement and - Technology and platform chosen. WS application can get very complex, depending e.g. on how many partners integrate their service. The participant’s level of contribution includes the responsibility for presenting the application to end-user or providing the functionality for its piece of the process, not delivering the entire application. One more high-level scenario is also possible i.e. the owner-broker model [Oe91]. Selecting the technology and platform may include following aspects as: - Referencing legacy system - e.g. COM-based, - Goal platform - e.g. MS-Windows 2000, - Utilized development platform- e.g. MS Development Platform for COM+, - Interface middleware - e.g. ASP, - Maintaining data (consumer accounts and session data) – e.g. MS SQL Server. The choice between communication technology protocols: TCP (connection oriented) and UDP (connectionless) will be dependent on the current requirements i.e. TCP tries to ensure delivery at cost to overall performance, while UDP focuses on the highest possible performance. The Web service consumer i.e. direct caller of WS (client in a client-server architecture) provides the widest range of possibilities in functionality. It may be responsible for the presentation to the end user brokering multiple Web services, or simply passing through a Web service call. Furthermore, different consumers on the same Web service may want to use a Web service in completely different ways. One may pass info straight to the client; another may want to use Web service wholly masking his existence (see the subfeature Masked of the Exposure Level in the Presentation Model in Fig. 2). It has to be emphasized, that Web services themselves do not have a presentation layer. In combined logical and communication architecture for a Web services [Oe91] there are following parts included: - Presentation (Consumer) - Integration/Interface (Consumer/Provider) - Business (Provider) - Data (Provider) Presentation layer for a consumer (see Fig. 5) may include the most degree of diversity from an application to application. Web service models reflecting given business goals and priorities, will further vary because of having different features: - Target consumer, - Functions provided by service, - Bundled, or directly consumed service, - Dynamic or static service, etc.
The parts of Web service models i.e. Presentation, Interface and Security (as depicted in feature diagram in Fig. 2-4) containing different possibilities, which have to be instantiated for an individual Web service. In some situations there are multiple instances of the parts in the model possible – e.g. there may be a need to support more than one security model to accommodate different requirements.
3 Conclusion There is a need for building taxonomies for Web Services, because the present Web Services architectures are diverse and proprietary for specific manufactures. In the paper different properties of Web Services, regarded from different points of views were presented. Web Services form the orthogonal concept to the components’ notion including their key features as providing the encapsulated functionality as loosely coupled black boxes with described and published interfaces. The Web Services may be regarded as services for Web as well as components in the complex workflows. In the paper the proposal for modeling flexibility of the Web Services with feature diagrams is introduced. The knowledge contained in a feature diagram may be considered as a configuration knowledge, that can be dynamically customized it with a generator for an individual Web Services profiles’ consumers. For the feature diagrams the notation introduced in GP was used. Moreover, the use of UML based notations for feature diagrams (like introduced in [RFP02]) is recommended. In the future the further investigations for the specific Web Services domains are needed.
References 1. [Co02] Coco, J.: Code Reuse: From Objects to Components to Services. XML-Journal. SYSCON Media, Inc. (2002). www.sys-con.com/xml. 2. [Co01] Coco, J.: Maximizing the Potential of Web Services. XML-Journal. SYS-CON Media, Inc. (2001). www.sys-con.com/xml. 3. [CE00] Czarnecki, K.; Eisenecker U.: Generative Programming Methods, Tools and Applications. – New York, 2000. Addison-Wesley. 4. [Je online] Jeckle, M.: Web Services. Begriffsdefinitionen. www.jeckle.de/webServices 5. [Je02] Jeckle, M.: Web Service-Architecturen. Presentation slides at XML in Action 2002. Potsdam (2002). 6. [Ka90] Kang, K. et. al: Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical Report No. CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, 1990. Pennsylvania 7. [Oe01] Oellermann, W.L, Jr.: Architecting Web Services. Apress. Springer Verlag New York (2001).
8. [RFP02]: Robak, S.; Franczyk, B.; Politowicz K.: Extending UML For Modeling Variabilities For System Families, International Journal of Applied Mathematics and Computer Science, 12(2), 2002. 9 [Sz98] Szyperski, C.: Component Software: Beyond Object-Oriented Programming. – New York, 1998. Addison-Wesley 10. [Sz01] Szyperski, C.: Components and Web Services. Software Development Magazine. August 2001. www.sdmagazine.com. 11. [Ti01] Tidwell, D.: Web services – the Web’s next revolution. ibm.com/developerWorks
Web Services
Communication Technologies
Consumer
Requester
Transport
Protocol
Parser DOM
SAX
UDP
Service
Payload
TCP/IP
Listener
Java Servletes
XML
ASP
Application Ports
FTP (21)
SMTP (25)
HTTP (80)
Responder
JSP
HTTPS (443)
Fig. 1. Web Services Communication Technologies
Web Services Models Presentation Model
Interface Model
Exposure Level
Masked
Isolated
Security Model
Presentation Services
Embedded
Content
Style
Areas
Validation
Delivery
Data oriented
Fig. 2. Web Services Models - Presentation Model
Information oriented
Web Services Models Presentation Model
Security Model
Interface Model
Process (diagrams)
Payload (Definitions) Static
WS Call
Dynamic
WS Workflow
State Management
Efficient Responses
Application Data
Session Data
Dynamic Requests
Presentation Data
Dynamic Responses
Conditional Responses
Fig. 3. Web Services Models- Interface Model
Web Services Models Presentation Model
System Access
Direct
Interface Model
Application Authentication
Security Model
Transport Integrity
Payload Validation
Proxied Mechanisms
Logic Payload Structure
Fig. 4. Web Services Models - Security Model
Payload Data
Web Services Consumer Integration
Presentation
Design Content
Style
CSS
XSL
Specific (Programming Languages)
HTMLCode
Client-side scripts
Other Files Formats
Images
BMP GIF TIF
Fig. 5. Web Services Consumer Logical Sublayers
