Figure 1. Various service technologies collaborate to form industrial-strength services
SOA [Service Oriented Architecture] and service-orientation have laid the foundation for a variety of emergent service technology innovations, while the original building blocks of SOA and service-orientation continue to evolve by embracing fundamental service technologies, concepts and practices. These new technology innovations do not replace service-orientation; they use it as their basis. Service-orientation continues to evolve towards a factory approach, towards industrializing integrated platforms, such as BI, Master Data Management (MDM), mobile front-ends, BPM, adaptive processes, Big Data and Cloud Computing - all of which add architectural layers upon SOA-based infrastructure. All of these technologies can interface via standardized data and functions, published as service contracts, in order to avoid redundancy - that's service-orientation [3]. Advance software modularity focuses on the novel requirements of modularizing and uniting software schemes on desires and architecture plans such as [1][2]. Aspect oriented requirements engineering, Requirements and architecture design techniques for software product line engineering; Requirements engineering for service-oriented systems[12]. This paper basically deals with requirements engineering for service-oriented systems, needs for SOA, SOA practices in the mobile age, industrial SOA toolkit, it's maturity as well as SOA & user interfaces.
Modularity is the degree to which a system's modules may be detached and recombined. In software design, modularity refers to a logical splitting based on related functions, implementation considerations, data links, or other criteria that allows multifaceted software to be adaptable for the purpose of execution and maintenance. Main development task in SOAs are to create applications by joining building blocks provided by amenities, and service arrangement may themselves become services and recuse vice composition. Service composition should use functional requirements, quality of service parameters, use P2P conversational interactions and exploit multi-party interactions.
SOA Software helps businesses to quicken their digital stations with APIs, drive partner implementation, monetize digital assets, study their data and business as well as track the performance of Agile team. SOA Software also extends the value of APIs deep within the enterprise, helping companies build next generation applications and datacenters.
SOA greatly advance arrangement between the business and information technology communities. Utilization of the method, meta-model and references will lead to the additional implementation of SOA as an architectural style.
There are basically two different methodologies to implement SOA in any organization. Rational Unified Process(RUP) and Extreme Programming(XP).
RUP is a more traditional, heavyweight technology that is mostly used for large and complex projects. It mostly focuses on requirement gathering, use of UML for system design as well as encourages the creation of full prototype of project.
While XP is a more lightweight, agile one that is best suited for Internet-based development, It mostly focuses on short iterations, pair programming and test of system.
Third methodology of SOA is mixture of RUP and XP i.e Service Oriented Unified Process (SOUP). It deals with breakdown of software development process into two phases. It uses RUP to build SOA and XP to maintain it.
Recently, many enterprises have focused on increasing their business flexibility and achieving cross-enterprise collaboration to remain competitive in the market, and to meet their business objectives [10]. Enterprises are especially challenged by constant changes in the business environment and changes in the supporting Information Technology (IT) infrastructures that hinder the overall success of enterprises (van Sinderen, 2008) [14]. Furthermore, most enterprises still rely on so called legacy system- software developed over the previous decades using 3GL programming languages like COBOL, RGP, PL/I, C, C++. Despite the well-known disadvantages such as being inflexible and hard to maintain, legacy systems are still vitally important to the enterprises as they support complex core business processes; they cannot simply be removed as they implement and store critical business logic. Unsurprisingly, the knowledge contained in these systems is of high value to an enterprise. On the other hand, proper documentation, skilled manpower, and resources to evolve these legacy systems are scarce. Therefore, momentum is growing to evolve and reuse those legacy systems within new technological environments—Service- Oriented Architecture (SOA) being the most promising one (Bisbal, Lawless, Wu, & Grimson, 1999[15]; Lewis, Morris, O'Brien, Smith, & Wrage, 2005)[16].
SOA has emerged as an architectural style that enables the reuse of existing legacy assets within a new paradigm that facilitates loose coupling, abstraction of underlying logic, flexibility, reusability and discoverability (Papazoglou, 2008) [17] . The evolution from legacy to SOA can be beneficial from both economical and technical perspectives. From an economical perspective, legacy to SOA evolution fosters change management including intra-organizational changes, and changes in enterprises (Khadka, Sapkota, Pires, Sinderen, & Jansen, 2011 [18]; Papazoglou, Traverso, Dustdar, & Leymann, 2007) [19]. From a technical perspective, seamless enterprise collaboration through service composition (Khadka & Sapkota, 2010) [20] and reduction in maintenance cost are claimed as long term benefits (Papazoglou, et al., 2007 [19]; Schelp & Aier, 2009) [21]. Motivated by these benefits, there has been significant research in legacy to SOA evolution. However, there is no systematic overview of legacy to SOA evolution, particularly focusing on the techniques, methods and approaches used to evolve legacy systems to a SOA environment. In the systematic literature review conducted by Razavian (Razavian & Lago, 2010) [22], an overview of SOA migration families is reported. It focuses on classifying the SOA migration approaches into eight distinct families. The classification is inspired by the reengineering horseshoe method (Bergey, Smith, Weiderman, & Woods, 1999) [23] rather than giving a historical overview of SOA migration methods. Also, a brief overview of legacy to SOA evolution is reported by Almonaies (Almonaies, Cordy, & Dean, 2010) [24] that divides the legacy to SOA evolution approaches into four categories: replacement, redevelopment, wrapping and migration.
Closed world environments were impractical due to dynamic, open environments becoming the standard, and all requirements cannot be discovered upfront & many unforeseen stakeholders emerge. Thus it requires support for change in incremental, agile & prototype based approaches, in recompilation and redeployment of modular design as well as information hiding, encapsulation in new languages. The system needs to change when the context changes i.e. some of its parts can disappear or some new parts can be found. Thus we need to re-organize itself at run-time [5].
The key differences between open world environment and closed world environment are that services are owned by other people or other organizations and contractual arrangement between service consumer and provider. One remaining assumption is that we can own the software modules and components ourselves.
Services become key actors in open-world systems due to resources made available on a network as services with which our software can interact remotely to obtain a goal, with loosely coupled modules and accessed on demand. Services are self-describing, open components that support rapid, low cost composition of distributed applications.
Applying reliable best practices to mobile applications takes more than SOA. With guidance on new approaches, mobile applications can be faster and more secure. A new development in the API market, backend as a Service, offer developers a whole new dimension of opportunity—cloud services to build the mobile applications of the future. Mobility, mobile broadband and mobile applications are transforming the Internet and the way people communicate and use information. For developers, the mobile application represents an enormous, lucrative new market. From a business perspective, each of the mobile platforms has its own benefits and limitations. Each also has its technical framework—its own APIs. Mobile development platform APIs generally fall into two categories: platform APIs related to the mobile device's own operating system and middleware, and service APIs related to the access of Web-hosted material.
The new opportunity in APIs is BaaS, an extension to the service API model. The goal of BaaS is to convert common and useful elements of mobile application logic—storage, identity management, social network integration, photo enhancing—into Representational State Transfer (REST) Web services that the application invokes as needed, making these services “back ends” to mobile apps. As a concept, BaaS is similar to Software as a Service (SaaS) and Platform as a Service (PaaS); it offers functionality as a Web service. With SaaS, what's offered is an application or application component. Salesforce.com's CRM is a good example. PaaS offers a collection of services designed to present a complete virtual operating system; Microsoft's Windows Azure is the best-known PaaS example. BaaS is somewhere in between; it offers PaaS-like features, but not as a complete programming platform. Like SaaS, those features might perform business functions oriented to vertical markets or functionalities that can be used across industries. In all cases, though, BaaS aims to enhance mobile development.
The app revolution spawned by the iPhone and other smart devices has proved that mobile broadband has a profound impact on how people access and use online resources. So it's logical to ask how mobile broadband will affect application development in general and SOAs in particular.
The reason to focus on SOA as a target of mobile impact is this: Mobile users are highly compartmentalized in their online usage. While traditional-computer users go to a Web browser to find something, mobile users want to use an app. Structurally, such an app is a link between an onscreen icon, some optional local processing and a URL. In many cases there's a 1:1 mapping between apps and online services, and it's this kind of componentization of services that SOA targets.
We can now combine these building blocks into a modern toolkit that fulfills each key business objective a company with loosely coupled services. Figure 1 maps the potential areas of technology innovation with the layers of SOA. This results in an "industrial SOA toolkit", in which tools like an Enterprise Service Bus (ESB) are used "internally" and included under the overall heading of "SOA" [4].
Figure 1. Various service technologies collaborate to form industrial-strength services
Figure 2 illustrates the simplicity of combining services within applications that results from standardized design and structures being used as the framework for interfaces and exchanged data. As service developers and designers, how can we successfully fulfill factory requirements and achieve the essential characteristic of industrialized SOA while remaining compliant with standards on the service contract level [13]?
Figure 2. SOA standard within applications result in compatibility
Thinking in terms of contracts has been found to be requisite for granular sourcing strategies that virtualize underlying implementations. Contracts also function as a common language between business units and IT teams, across cloud computing technologies, and for future proof and agile enterprises in general. [7]
One of the most important characteristics of the industrialization approach is a domain –wide standardization of inter faces or "service-level agreements." This agreement is a contract into which a service enters with its users, and is the prerequisite for BASs that are incorporated as function components for processes and portals. Considerable integration effort isn't required, and SLA compliance can be evaluated through enterprise asset management (EAM) or business process management (BPM) dashboards.
It is conceivable for specifications to be centrally determined on an SOA dashboard as an option for establishing the standards throughout an enterprise or organization. SOA governance tasks check and verify their use and compliance with the applicable specifications. These governance tasks require substantial effort to remain compliant with the specifications of standardized interfaces, which must be fulfilled for each service. Figure 3 illustrates the model-driven generation of service contracts which can be implemented to reduce this effort and allow service developers to focus their attention on service implementation instead.
Figure 3. Model-driven generators assist standardization
In the simplest scenario, a user's interaction with a business process consists of initiating the process and awaiting the result. However, processes very rarely run completely automatically, meaning human intervention in a process cycle is an important requirement [9]. The WS-Human Task specification can fulfill this requirement in the SOA environment. A standardized API that is defined for a workflow service can be used to fill a mailbox with tasks. If the process automation language BPEL is used, the BPEL4People specification defines how this mailbox functionality can be used directly in the process cycle by means of the WS-Human Task. Of course, this is possible from BPMN, too.
For example, if manual approval or the input of additional data is needed during a process cycle, the process can determine the correct actor and deposit the task in their mailbox via the task service. The Human Task service provides a Web service API for this functionality. The users receive the entries in their mailbox and process the pending tasks sequentially, while the process resumes its work in the background.
Figure 4 illustrates the most basic example of interaction between a user-interface and a process. Data is gathered via a series of Web pages and transferred into a process as input parameters. The process call, which can be considered identical to a service call, is designed for synchronous response behavior in order to evaluate the result and return directly to the waiting page. This pattern is frequently encountered in practice but is not the method of choice in an SOA. What is the issue with this architecture variant?
Figure 4. The standard basic approach that collects all of the data, triggers the process, and awaits the results
The answer appears straightforward if you consider the reasons why SOA was chosen as an architecture principle for process implementation. SOA promises a high level of flexibility, and the process offers rapid implementation of change requests. What happens when flexibility is crucial and the process has to be changed, so that the result can only be returned after a delay of a time period X instead of immediately?
As a new requirement, for example, a time-intensive activity that contains a user interaction via mailbox is being added. The implementation "breaks" the user interface, as the system was working synchronously and the delayed response has now caused blocking (or timing out for Web applications).
In practice, the call for synchronous interaction with services violates the principle of loose coupling. "Rapid a synchronicity" may be able to fulfill the requirements and replace synchronicity successfully [8]. We have noticed very little difference between the response times of synchronous versus rapid asynchronous service calls, as bottlenecks are typically caused by network latency. [6]
Figure 5 illustrates the mailbox approach, which is implemented similarly in all process and workflow cycle environments. The process determines the actor, which can be a person or role, and deposits a task in their task list. The process then waits until the actor removes the task from their mailbox and returns it as processed. Any type of complex data can be transported, and some environment permit the embedding of entire screen areas for data entry for display to the user.
Figure 5. A work list application (mailbox) for long-running processes
In many cases, a clear benefit can be achieved by using the mailbox approach. Process knowledge can be extracted from individual employees and hardwired applications and made explicit in the form of processes. The operation of several complex applications can then be extensively standardized using a higher-level process control. Opportunities for monitoring individual process instances are also created, allowing transparency within the company to be increased significantly.
As distributed computing systems increase in complexity, it becomes more difficult to design test plans that effectively test the entire system. And while Service- Oriented Architecture (SOA) applications have been around for quite some time, effective testing for these applications is still a challenge.
This informative resource offers eight key lessons on preventing common SOA testing pitfalls and how to Mitigate some unavoidable challenges. These lessons cover:
Service-oriented architectures are more accepted by the IT industry. It is modularized approach for building and deploying services across the extended enterprise. However, practical implementation of these architectures requires careful planning. Interested industry must first make sure that they're geared up to implement and support them in the long-term.
By implementing SOA, companies can proactively address a range of challenges that they'll encounter along the way. Each enterprise will face a unique set of challenges; corresponding approaches for solving those challenges will vary, as well. The impact of the challenges — both during and after the implementation—also depends on the context of the given enterprise.