> Archive > Issue LVIII, January 2012 > Agile E-Service Composition
Pouya Fatehi

Pouya Fatehi


Pouya Fatehi is a software designer in Iran Rayaneh Company and is responsible for service architecture of BPM project which names FilerPlus for 5 years. He has a Masters degree in Software Engineering from Science and research Beranch of Islamic Azad university of Tehran. He is specialist in software as service paradigm and has a several research in the field of agile methodologies and SOA.


rss  subscribe to this author

Seyyed Mohsen Hashemi

Seyyed Mohsen Hashemi


Seyyed received his MSc degree in Computer Science from Amirkabir University of Technology (Tehran Polytechnic University) in 2003, and his PhD degree in Computer Science from the Azad University in 2009. Moreover, he is currently a faculty member at the Science and Research branch at Azad University in Tehran. His current research interests include Software Intensive Systems, E-X systems (E-Commerce, E-Government, E-Business, and so on), Global Village Services, Grid Computing, IBM SSME, Business Modeling, Agile Enterprise Architecting through ISRUP, and Globalization Governance through IT/IS Services.


rss  subscribe to this author


Agile E-Service Composition

Published: January 19, 2012 • Service Technology Magazine Issue LVIII PDF

Abstract: Nowadays, application of service-oriented architecture are increasing rapidly; especially since the introduction of distributed electronic services on the web. SOA software has a modular manner and works as a collaboration of independent software components. As a result, the e-service approach is sufficient for software with independent components, each of which may be developed by a different company. Such software components and their cooperation form a composite service. Agile methodologies are the best candidate for developing small software components. Composite services and their building blocks are small pieces of software, making agile methodology a perfect fit for their development. In this paper, we introduce an agile method for service composition, inspired by agile patterns and practices. Therefore, across the agile manifesto, we can develop low cost, high quality composite services quickly using this method.


Trends to inter enterprise communication and creation of on demand-services have made e-services more popular technology. Another reason of e-service popularity is Software-as-a-service (SaaS) model which is a rapidly growing model of software licensing. "SaaS is seen as a possible replacement to traditional software where the buyer obtains a perpetual license and installs and maintains all necessary hardware, software and other technical infrastructure. Under SaaS, the software publisher (seller) runs and maintains all necessary hardware and software and buyers obtain access using the Internet" [REF-1].

A Service is a discoverable software resource which has an advertised service description. The service description is available in a repository, called a registry that can be searched by a potential consumer of the service. Given the service description, a service consumer can bind to and use the service. In the real world, e-services are represented by web services which have different types (grid services, distributed services, etc).

Making advanced features and goals, companies use a combination of several services to develop composite services. The composability feature of a service leads to the low-cost development of high quality services. "The process of integrating existing Web services to achieve higher-level business tasks that cannot be fulfilled by any individual service alone is often referred to as Web service composition" [REF-2].

Based on IBM's approach [REF-3], service composition is the fourth step of SOA modeling. Service Identification, Service Specification, and Service Realization are earlier steps and the last one is Service Implementation. Whereas services are small software components, different software methodologies could be used for developing a composed service.

RUP and similar guides, like the PMBOK, Software Engineering Institute's (SEI's) Capability Maturity Model Integrated (CMMI), or the UK's IT Infrastructure Library (ITIL) standards impose unnecessary process overhead for smaller projects. In contrast agile methodologies allow for fast and tight increments or phases, they cut down overhead and they ensure a close relationship between the developer and customer. Comparing agile methodologies with other methodologies, demonstrates that agile methodologies are more useful for developing services. So in this paper we are trying to represent a new agile methodology for services, especially for composed services.

To explore which agile methods are the most effective for composite service development, we first investigate if any combinative use of agile methods (or, at least, employing more than one agile method) can have an effect on the four outcomes. Based on research that has been done by Parsons, Ryn and Lai [REF-4], using two agile methods is better for productivity than using only one method, and there appears to be no significant further advantage in increasing the number of methods used beyond two. Also Parson, Ryn and Lai [REF-4] expressed that in terms of both quality and productivity that there was a significant difference between the eXtreme Programming/SCRUM combination and all the other pairs of methods. However, there was no significant difference in either cost or satisfaction. This clearly tells us that the eXtreme Programming/SCRUM combination is a good pairing of methods to adopt.

This result can be seen to make some sense in that eXtreme Programming (XP) is very much oriented towards technology- based practices and programmer activity. In contrast, SCRUM is more focused on agile project management aspects [REF-15]. In addition, SCRUM is explicitly intended as a wrapper around other engineering approaches. Therefore XP and SCRUM can be seen to be complementary from a practical point of view, supporting the claims made by Mar and Schwaber [REF-16].

Accordingly we use a combination of these pair methods to bring agility into our service composition model. Since changing the development process cannot be implemented in a single shot, we define two implementation levels. By defining separate levels in the development process, preparation of the implementation process can be simple like what the Capability Maturity Model (CMM) has done. Also IBM defined a capability maturity model for services (SIMM) [REF-5]. This model consists of seven steps where companies should implement dynamic service compositions to achieve the seventh step. The first level of AM4SC is also useful for describing our model strategy.

Agile Model for Service Composition (AM4SC)

AM4SC can be described by four activities which are derived from SCRUM methodology and six practices which come from the XP method. Mainly these activities are management processes and practices that can increase agility and development quality. The four activities are described as below:

  • Planning process: In this process the functionality domain is described and, with TDD rules, an abstract model for composed services is designed. As a result, expected inputs and outputs are represented. Obviously according to the agile manifesto, the proposed model would not be a complete model but it would start with a simple model and would be finalized with incremental iterations that evolve as the activities continue.
  • Arrangement process: After the planning process, the features list that should be included in the next iteration is prepared. This process is done in periodical sessions. An output, services and features that need to be included in the next iteration (something like backlog in SCRUM) should be reported. Some of the services should be refactored to fulfill the composed service rules.
  • Modeling process: As in the previous steps, the expected input, expected output and requirements list determine the modeling that can be done with any available service modeling tools. This can be done in the simplest case, by using pen and paper.

The test process can be started from here. Across the input, output and design models in the first step, tests can be introduced before implementing composed services. Each service will be considered as a block and their outputs are determined in each specific input.

Figure 1 – Composite Service Modeling.

  • Implementation Process: At this step the platform of independent models for composite services that are offered in the previous steps are mapped to platforms of specific models. The result is a composite service that provides the desired functionality. In the last step, this result was released and delivered as an iteration to customers.

  • This life cycle will be continued until customers’ feedback is obtained and their new requirements are given, then composite services are incrementally completed in next iterations.

    Figure 2 – AM4SC Activities.

    Practices bring more agility to AM4SC. These practices are based on XP practices and make our model more adaptive to the agile manifesto as follows:

    • Collaborative programming: Developed services may be implemented in different platforms and with different technologies by several development teams. Although the service description is available through UDDI and with Web Service Description Language (WSDL), developers of services can share their experiences for modeling and implementing composite services more easily at a low cost.
    • Iterative and Incremental development: Requirements should be categorized so main features developed in first iterations that refactor other features can be inserted into composite service incrementally.
    • Online customers: Composite service customers are also called service requesters . Their feedbacks will be used to increase quality and acceptance of developed services. Also distributing beta versions on the web delivers more feedback.
    • Continues integration: In each iteration, whole service models should be integrated to implement composite services; this makes our model more reliable.
    • Reusability through design: This is a fundamental agile practice that involves actively ensuring that a piece of functionality is implemented in a single place. We use these techniques to make sure that services which are used in composite services, implement functionality once. Also the same techniques could be used to bring better functionality and to cover more requirements through fewer services. Design reviews can be used to remove duplicate logic across existing services. In order to increase the potential of reusing the services, it must be ensured that a service does not have a channel, technology platform or transport specific logic which is coupled with its domain logic [REF-5].
    • Service model refactoring: After each periodic release, service models should be changed to achieve new features and requirements while ensuring that logics of model sections remain unchanged. This practice is useful for decreasing the cost and time needed to apply changes that consumer expects. Therefore, based on customer requests, which may be received in WSBPEL or another format, a translator get it to a known service model whereby the model will be refactored to satisfy the requested features.
    Figure 3 – Collaboration of AM4SC Agents.

    Second Level of AM4SC: Agile Model for E-Service Composition

    Today, service developers use SaaS for distributing their services to the web. To use this method through service development, the AM4SC method should use a dynamic method for developing composed services. For reaching this goal, we defined an automated model for AM4SC that not only has the same agility features of first level but also brings the capability of developing composed services in runtime and on demand.

    The execution of AM4SC starts with pair element of request and request priorities defined by a service requester. After modeling and developing composed services, despite a unit test acceptance, a new version of the services can be delivered to the customer. In AM4SC second level, six agents collaborate together to achieve model goals as follows:

    First, an agent called feature selector selects features by pairs that the service requester sent as an input. Additionally based on meet-in-the-middle architecture, the customer’s requests should be categorized across the developer’s policies and their priorities which are provided by the requester. Therefore in this agent, customer’s requests or feedback priorities, paired with company policy variables, are used for selecting features that will be developed during the next iteration to decrease the risks of development. Output of this agent is also a useful tool for accessing progress of the development process.

    Second, the agent named unit test maker, searches among reference models for defined problem domains that are described by the service requester requirements. This agent acts as a TDD practice to increase the quality of the developed service. Unit tests generated by this agent are used as artifacts to describe requirements of the problem.

    Then an automated refactor/modeler agent creates requests for binding a required service based on the selected features and artifacts that are defined by the unit test maker agent. The request should be first translated to WSDL format then requests can be sent to a service broker agent to search the UDDI registry for requested services along with delivering the binding information of services to an automated modeler agent. Then the automated modeler use an automated modeling method for the model composed service using the binding information. Then the model can simply be converted to BPL or BPEL format to begin the creation process of the service that will be started by the next agent.

    Another task that can be done by this agent is model refactoring when unit tests fail or, in next iteration of service development cycles, add more features in the composed service. Refactoring is one of main principles of DRY practice that is responsible for locating opportunities for eliminating duplication among services. Therefore refactoring agents can also be used to increase the reusability of composed services.

    At the next step, an agent named Service Creator binds services and creates the necessary relationships designed in a service model between the input and outputs of services described by BPEL.

    Tester agents test composed services with the created unit tests and survey the results. If the tests pass, the composed service delivers them to the service requester, otherwise if one or more tests fail, the model with failed unit tests is delivered to an automated modeler for refactoring, where changes are made to the model to satisfy all unit tests. If unit tests pass we can ensure that all planned features have been covered.

    At the end of each iteration, after designed unit tests passed, an integrated composed service can be delivered to a service requester. Customers’ feedback and recommendations can be used to improve the productivity and usability of composed services in the next iteration of developing composed service.

    Comparison of AM4SC with Other Service Composition Methods

    In this part we consider how to compare AM4SC to other service composition methods from the agility and main service composition features perspective. Some of these methods (like SOMA, OASIS, etc) are not specifically designed for service composition but cover service composition as a part of SOA modeling.

    Table 1 represents these comparisons. Some features (4, 6, 11, 9, 10, 12, and 19) cover the productivity and reliability of composed services while some others are for decreasing risk of production. We describe how these features are supported by AM4SC.

    Table 1 – Comparison of AM4SC with Other Composition Methods.
    (Click here for large image)

    1. Service composition: In the comparison we take look at other SOA methodology to ensure that we are supporting their features. Although some of these methods don’t include composition process, we must ensure they support all other service development features.

    2. Meet-in-the-middle methodology: Features that would be generated during the next iteration should be selected by a features selector agent based on user priorities and company policies that decrease risks.

    3. Participation of customers: Customers’ feedback and priorities contribute to low risk reliable software. AM4SC infrastructure is an on demand development method that composes services to satisfy customer requirements. Customers also send their request priorities to the service development process that is used for selecting next iteration features to be developed.

    4. Repetitive production: By periodical and repetitive production, service stability and quality is guaranteed.

    5. Categorizing requirement: Development can be started from a simple model and completed in several iterations. This will ensure how the main feature should be developed and makes considerations about other features.

    6. Managing creation process: AM4SC is derived from the SCRUM methodology process and can be managed in a similar manner.

    7, 12. Fast release/simple design: Development of composite services starts with some base features, and the final product can be completed incrementally. This kind of development causes fast product delivery.

    8. Optimal usage of available resource: One of the agile manifesto rules is optimal usage of human resources for developing software at low cost. The six agents are responsible for the five activities described, which are the minimum required activities that should be used to cover both SCRUM and XP methodology.

    10. Reusability/Refactoring: Refractor agents are responsible for redesigning composite service models without logical change in service features as described before. A composed service may use as a component of another composed service; so reusability of services through design should be considered. Based on Narayan’s research [REF.5], user stories and refactoring are two main practices that can be caused to increase reusability of services.

    11. Continues integration: In each iteration, whole composite services can be integrated for delivering a fresh version to customer. Several periodic iterations can increase the quality of service and reliability by decreasing side effects of newly inserted features.

    13. Flexibility: In each iteration, new features should be added based on customers’ feedback and requests. So a composed service can be so flexible that it could take a look at all features based described priorities.

    14. Periodical release: In each period we can have a fresh version of a composed service and consumers can choose the best one that fits his or her requirements.

    15. Dynamic composition support: Using agents that automatically perform service composition tasks can enable on demand composition and as a result, composed services can be described in runtime.

    16. Availability of techniques: Since all agents’ duties and practices can be derived from agile methods, these techniques can be available and tested before.

    17. Modeling capability: Modeling that can be done by an automated modeler which can increase readability for both customers and developers.

    18. Quality assurance: Test driven developments that can be done by unit test makers and unit tester agent are considered best practice that can satisfy the quality assurance of development.

    Figure 4 – AM4SC Sequence Diagram.
    (Click here for large image)


    [REF-1] G Vidyanand Choudhary, “Software-as-a-service: Implications for Investment in Software Development” Proceedings of the 40th Annual Hawaii International Conference on System Sciences (HICSS'07) © 2007 IEEE

    [REF-2] W. Liu et al.: E-Service Composition Tools from a Lifecycle Perspective, Studies in Computational Intelligence (SCI) 37,125- 146
    © Springer-Verlag Berlin Heidelberg 2007

    [REF-3]   J.Amsden, “Modeling SOA: Part 4. Service composition” in

    [REF-4]   Parsons, D., Ryu, H., and Lai, R., “The Impact of Methods and Techniques on Outcomes from Agile Software Development Projects” 2007, in IFIP International Federation for Information Processing, Volume 235, Organizational Dynamics of Technology-Based Innovation: Diversifying the Research Agenda, eds.McMaster, T., Wastell, D., Femeley, E., and DeGross, J. (Boston: Springer), pp. 235-249.

    [REF-5]   V .Narayanan, “Modern SOA Methodology and SOA Adoption Using Agile Practices” Published: September 15, 2010 (SOA Magazine Issue XLIII: September 2010)

    [REF-6] A.Arsanjani, Service-oriented modeling and architecture How to identify, specify, and realize services for your SOA , IBM developer works, 2004

    [REF-7] U.Homann, J,Tobey, From Capabilities to Services: Moving from a Business Architecture to an IT Implementation, Microsoft Corporation, April 2006


    [REF-9] David E. Millard · Y.Howard · N.Abbas · Hugh C. Davis · Lester Gilbert ·Gary B. Wills · Robert J. Walters, Pragmatic web service design: An agile approach with the service responsibility and interaction design method, © Springer-Verlag 2009

    [REF-10] Jing-fan Tang, 2006, A Service Composibality Model to Support Dynamic Cooperation of Cross-Enterprise Services, in IFIP International Federation for Information Processing, Volume 220, Information Technology for Balanced Manufacturing Systems, ed. Shen, W., (Boston; Springer)

    [REF-11] Minhong Wang , William K. Cheung2, Jiming Liu , Xiaofeng Xie and Zongwei Luo , S. Dustdar, J.L. Fiadeiro, and A. Sheth (Eds.), E-Service/Process Composition Through Multi-agent Constraint Management,© Springer-Verlag Berlin Heidelberg 2006

    [REF-12] V.Torres ,V.Pelechano, R.Quintero, Model Centric Approach of Web Services Composition, © 2007 Birkh¨auser Verlag Basel/Switzerland

    [REF-13] T.Ghafarian, M.Kahani, Semantic Web Service Composition Based on Ant Colony Optimization Method, 978-1-4244-4615-5/09, ©2009 IEEE

    [REF-14] D.Rosenberg, M.Stephens, M.Collins-Cope, Agile Development with ICONIX Process:People, Process, and Pragmatism, ISBN 1-59059-464-9, 2005

    [REF-15] Abrahamsson, P., Salo, O., Ronkainen, J., and Warsta, J. Agile Software Development Methods:Review and Analysis, Oulu, Finland: VTT Publications, 2002.

    [REF-16] Mar, K., and Schwaber, K. "Scrum with XP,", March 22, 2002 (available online at article provided courtesy of Prentice-Hall)