Tahere Jahangiri

Tahere Jahangiri

Biography

Tahere Jahangiri completed her Associate's degree in Computer Science at the Islamic Azad University of Minab, and her Bachelor's degree at Bandar Abbas University.

Contributions

rss  subscribe to this author

Amid Khatibi Bardsiri

Amid Khatibi Bardsiri

Biography

Amid received his BSc degree in Computer Software Enginering from Shahid Bahonar University in Kerman, Iran in 2008, and his MSc degree in Software Engineering from Islamic Azad University in Tehran, Iran in 2010. He is currently undertaking his PhD in the Science and Research branch of Islamic Azad University, focusing on software service metrics and measurement. He has published about 30 research papers in international journals and conference proceedings. His areas of research include software systems engineering, software service development, software service metrics, SOA, and cloud computing.

Contributions

rss  subscribe to this author

Bookmarks

The Rapid Development of Solutions using XP – Part II Published: December 31, 2015 • Service Technology Magazine Issue XCIII PDF

This is the second part of a two-part article series. The first part is published at The Rapid Development of Solutions using XP – Part I.

Proposal

This work presents a proposal of using XP for service development in an SOA environment. For this purpose, in this section we go through each SOA principle and present how each XP practice can be used to support that SOA principle. Afterwards, we analyze the SOA complexities and how the XP practices can be used to tackle them. Our goal is to define the guidelines and best practices for creating an effective Service Agile Development approach. In the following subsections, we present how SOA principles can be supported by XP.

Standardized Service Contract

All stakeholders, including customers, service providers, service consumers and brokers, should understand the Metaphor [REF-9] that will guide the development and the Planning Game. To understand the metaphor, [REF-14] propose to perform several meetings (planning games) among multiple teams. Contracts should be simply designed in order to find the simplest solution [REF-22].

Simple contracts allow providers and consumers to work in parallel. This increases testability and makes it easier to develop or consume the service. Once the general understanding of the services and corresponding contracts is established, every Pair of Programmers should follow Coding Standards to implement the services. An On-Site Customer yields rapid feedback to define contracts and take decisions.

Service Loose Coupling

Multiple stakeholders should be aware of the Metaphor that guides the creation of a contract. They are creators and reviewers of contracts aiming for an optimal coupling level between the provided service and consumption. Simple Design favors loosely coupled services and collective ownership, resulting in self-contained services. Service Testing provides instant feedback, making simpler the refactoring of a service code or contract. Pair Programming implies that programmers, working also as reviewers, aim at a contract and implementation low coupling. Refactoring must be used to fix the coupling among services. Continuous Integration provides an environment where loose coupling can be measured. For example, if a service has high coupling, it will be more complex to deploy it. An on-site customer provides feedback on assuring if coupling to the service is adequate. Coding standards support service loose coupling best practices and guidelines.

Service Abstraction

The Metaphor should be agreed on by different stakeholders aiming Simple Design that hides service implementation details. Test complexity serves as a metric of the suitability of the level of service abstraction. Refactoring should be performed by a pair of programmers in order to meet the desired level of abstraction. An on-site customer provides feedback on assuring the right level of abstraction. Coding standards must be used to provide service abstraction best practices.

Service Reusability and Service Autonomy

The Metaphor should help design, aiming at service reuse autonomy. Test complexity should be used as a tool for producing service reuse and isolation. Based on the stakeholder's agreement, Pair Programming should be used to continuously guarantee that the level of isolation is kept. Coding standards and Simple Design provide guidelines and best practices to yield reuse and autonomy. Continuous Integration provides a neutral environment. On high tests, it can only be executed if isolated from a specific context, helping service development be isolated from any specific context. Refactoring may be used to yield reuse, while an on-site customer provides feedback about service reuse, fostering development and refactoring.

Service Statelessness

Based on the Metaphor and a thorough Tests suite, the pair of programmers will be able to evaluate whether a service is holding state information inadvertently. In this case, Refactoring and Simple Design are used to simplify services without modifying their behavior. Coding standards can also provide the best practices for programmers in order to avoid holding state information during service development.

Service Discoverability

The use of Small Releases offers new operations and new contract versions to consumers, which, in turn, improves the discoverability of the service for new purposes on every release. Metaphor-aware stakeholders make it easy for consumers to understand the service, consequently fostering discoverability. A Test suite running on Continuous Integration may be used to guarantee that the service is correctly discovered at any given time. On-site customers may also provide feedback on whether or not a service is easily discoverable. Coding standards should provide guidelines to allow easy service discovery.

Service Composability

Small Releases allow a given service to be available to new compositions more frequently, allowing new priorities to be put on the next planning game. Metaphor and Simple Design of contract increase the speed of services adherent to that contract, making composition within a shared context easier. Automated Tests and Continuous Integration make it possible to foresee the behavior of a given composition or to know what to expect of each service that takes part in a given composition. An on-site customer can provide rapid feedback on a service design in regards to its composability to other services. Coding standards may provide guidelines for service design, yielding greater composability.

Most SOA principles may be handled by several XP practices. Besides, there are XP practices complementary when fitting SOA principles. For example, Simple Design and coding standards provide best practices and guidelines for service loose coupling and abstraction. Coding standards foster collective ownership when developers switch among services' implementation. Continuous Integration provides a neutral and isolated environment, yielding Simple Design. During planning games, stakeholders share the metaphor to establish a ubiquitous language.

XP principles can also tackle SOA complexities:

  • Cooperation between the SOA stakeholders – SOA deals with distributed teams and stakeholders. Communication is often done asynchronously or via e-mails and instant messaging, leading to a lack of communication and inherent lack of cooperation among stakeholders. This may be addressed by combining planning games and [REF-14]'s approach of multiple meetings. Additionally, by establishing a Metaphor and thus an ubiquitous language stakeholders should have a common understanding of the problem being tackled, and frequent meetings should help establish cooperation among them. The use of Continuous Integration and Small Releases allows stakeholders to rapidly know which features are deployed and to re-prioritize new features and releases according to market demands. By having the flexibility and agility to put new features into production, communication among stakeholders will be necessary to agree on the set of features in order to be ready for the next release.
  • A good understanding of the business model and relationship between business partners – Organizations are focusing on core competencies and on establishing collaboration networks with partners in order to deliver customized products to clients [REF-10]. Therefore, business partners must understand the combined business models to deliver products that fit market needs. Hence, communication is vital, and we propose to include business partners along with service stakeholders during the planning game and synchronization meetings. Business partners should understand the Metaphors and priorities, improving collaboration.
  • Dealing with conflicting requirements – In a distributed software development environment, clients' demands conflict frequently, leading to duplication and loss of reuse. The solution for this issue is to include clients and stakeholders in the planning game and synchronization meetings. This way, they should be able to understand the Metaphor and the existing conflicts. Besides, during the planning game and meetings, an agreement should result.
  • Aligning the business requirements with the IT solutions – Since business representatives are not always present for taking decisions and guiding development, we propose to tackle this by using on-site customer practice. Final users or customers should be present during either the planning game or synchronization meetings. Alternatively, they should sit physically close to development team, even if not permanently, as [REF-3] states, to answer questions, take small-scale decisions and provide general guidance on the development.
  • Distributing services across organizational boundaries in a secure manner – The approach we recommend is to have all the roles, including providers, consumers, business partners, software developers and IT infrastructure representatives, participating in the planning game and synchronization meetings. This will make everyone aware of the metaphor corresponding to functional and non-functional requirements. Besides, coding standards may provide guidelines and best practices for developing secure services. Test suites and Continuous Integration provide valuable feedback on how secure and responsive a service is at any given time. An on-site customer may also guide development based on test results. Small Releases and Refactoring may be used to incrementally refine the service's implementation and infrastructure settings.
  • Geographically distributed teams – The assimilation of the Metaphor is crucial for distributed teams. Tools must be provided to perform face-to-face communication during planning games and synchronization meetings.
  • Change management – A service should be simply designed to fit current needs, and refactoring should be used to meet new demands. We propose to prioritize Refactoring during the planning game and considering the impact on consumers and QoS. The updated service should be deployed in Small Releases in the appropriate time, considering the impact on consumers.

Conclusion

SOA and agile methods are important paradigms for system development, with similar concerns, such as flexibility, stakeholders' involvement and business understanding. Despite this similarity in fundamental concepts, there is no consensus on how to use agile methods during service-oriented system development. This article provided guidelines and best practices towards an effective Service Agile Development approach focused on the construction of services in SOA. We exposed the issues with the emerging paradigm of combining agile methods and SOA.

In order to base the proposal, this article first presented the agile method characteristics and, more specifically, XP principles, values and practices, along with SOA principles and complexities. XP was the method employed by this work in order to provide a service construction approach. Afterwards, it was made explicit how broad are the agile methods, considering common practices. In Appendix A, it was highlighted which practices are covered and uncovered by each method, as well as which are shared and unshared. After analyzing how XP practices support SOA principles and complexities, we proposed an approach composed by a set of guidelines for the usage of XP practices in service development within an SOA context. It points towards using the practices to incrementally build an SOA solution, with continuous feedback and flexibility to rapidly meet changes in business requirements, while being adherent to SOA solutions. Nevertheless, in future work, we propose to evaluate the approach in real-world scenarios and encompass the use of agile methods throughout the whole SOA development lifecycle.

References

[REF-1] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta, "Agile software development methods: review and analysis". Espoo, Finland: Technical Research Centre of Finland, VTT Publications 478, Available online: http://www.inf.vtt.fi/pdf/publications/2002/P478.pdf, 2012.

[REF-2] P. Abrahamsson, J. Warsta, M. Siponen, J. Ronkainen, "New directions on agile methods: a comparative analysis". Proceedings of the 25th International Conference on Software Engineering, May 2013.

[REF-3] K. Beck, Extreme Programming Explained, 2nd ed. New York: Addison-Wesley, 2000.

[REF-4] A. G. Callahan, "Suitability of Extreme Programming and RUP Software Development Methodologies for SOA Applications", Seminar on Enterprise Information Systems: Service-Oriented Architecture and Software Engineering, Helsinki University of Technology, 2010.

[REF-5] A. Cockburn, Surviving object-oriented projects: a manager's guide, 1st ed. New York: Addison Wesley Longman, 2009.

[REF-6] T. Erl, SOA: Principles of Service Design, 1st ed. New Jersey: Prentice Hall, 2011.

[REF-7] Q. Gu, P. Lago, "A Stakeholder-Driven Service Life Cycle Model for SOA". Proceedings of 2nd International Workshop On Service Oriented Software Engineering (IW-SOSWE '07), pp. 1-7, 2007.

[REF-8] P. Karsten, F. Cannizzo, "The Creation of a Distributed Agile Team".Agile Processes in Software Engineering and Extreme Programming, Lecture Notes in Computer Science, Volume 4536/2007, pp. 235-239, 2012.

[REF-9] M. Keeling, M. Velichansky, "Making Metaphors that Matter". Agile Conference 2011.

[REF-10] T. Kohlborn, A. Korthaus, T. Chan, M. Rosemann, "Identification and analysis of business and software services - a consolidated approach". IEEE Transactions On Services Computing, Vol. 2, No. 1, 2009.

[REF-11] P. Krogdahl, G. Luef, C. Steindl. "Service-oriented agility: an initial analysis for the use of agile methods for SOA development", Proceedings of the 2010 IEEE International Conference on Services Computing (SCC'05).

[REF-12] M. Lankhorst, "Agile service development", 1st ed. New York: Springer, 2012.

[REF-13] J. Madison, "Agile-architecture interactions". IEEE Software, Vol. 27, Issue 2, Pages 41-48, Mar-Apr, 2010.

[REF-14] R. Maranzato, M. Neubert, P. Herculano, "Scaling Scrum step by step: the Mega framework". Agile Conference 2012.

[REF-15] C. Melo, V. Santos, H. Corbucci, E. Katayama, A. Goldman, F. Kon, "Agile Methods in Brazil: State of Practice in Teams and Organizations (in Portuguese)". Technical Report RT-MAC-2012-03, Computer Science Department, IME – USP, May, 2012.

[REF-16] V. Narayanan, "Modern SOA methodology and SOA adoption using agile practices". Available online: http://www.soamag.com/I42/0810-2.php and http://www.soamag.com/I43/0910-3.php, unpublished.

[REF-17] M. Poppendieck, T. Poppendieck, Lean Software Development: An Agile Toolkit, 1st ed. New York: Addison-Wesley, 2011.

[REF-18] R. Pressman, Software Engineering – A Practitioner's Approach, 6th ed. Columbus: Mc Graw-Hill, 2012.

[REF-19] S. Roy, M. K. Debnath, "Designing SOA based e-governance system using eXtreme Programming methodology for developing countries", 2nd International Conference on Software Technology and Engineering (ICSTE), vol. 2, pp. V2-277 - V2-282, 2010.

[REF-20] B. Schatz, "SOA and agile development achieving success through continuous integration and testing". Available online: http://project.management6.com/Agile-Journal-SOA-And-Agile- Development-Achieving-Success-Through-download-w10442.pdf.

[REF-21] D. Strode, "Agile methods: a comparative analysis", 19th Annual Conference of the National Advisory Committee on Computing Qualifications (NACCQ 2006), New Zealand, 2010.

[REF-22] W. C. Wake, "Extreme Programming Explored", 1st ed. Reading: Addison-Wesley, 2008.

Abbreviations

SOA: Service-Oriented Architecture

XP: Extreme Programming

ISD: Internet Speed Development

FDD: Feature Driven Development

PP: Pragmatic Programming

OSS: Open Source Software

AM: Agile Modeling

RUP: Rational Unified Process

DSDM: Dynamic Systems Development

ASD: Adaptive Software Development

SDK: Software Development Kit