A comparison framework for service-oriented software engineering ...

The current issue and full text archive of this journal is available at www.emeraldinsight.com/1744-0084.htm

A comparison framework for service-oriented software engineering approaches Issues and solutions Youcef Baghdadi Sultan Qaboos University, Muscat, Oman

SOSE approaches

279 Received 7 March 2013 Revised 7 June 2013 Accepted 10 June 2013

Abstract Purpose – Many service-oriented software engineering (SOSE) methods from industry and academia claim their compliance with SOA and SO, but there is a lack of framework to assess the existing methods or to provide new ones. First, the paper questions: (Q1) to what extent an approach would consider the three aspect: service, composition, and management to deliver software solutions that are conformed to SO and SOA principles; (Q2) to what extent an approach would consider the aggregates of a method, including representation techniques, assisting tools, and inspection techniques to assess the delivered solution (service and composition), in addition to the process; and (Q3) to what extent an approach would consider the alignment of business and IT through the application of model-driven development by using standards such as model-driven architecture. Then, the paper compares four generic approaches: top-down, bottom-up, green-field, and meet-in-the-middle, within a framework, to highlight their strengths and weaknesses. Finally, the paper aims to propose a business-oriented approach that focuses on the value a business can add to its customers, whereby the value must be specified in a contract to be largely re-used. Design/methodology/approach – This work develops a framework as an abstract model for SOSE generic methods. Then, it uses the framework as an analytical study to compare the generic methods and come up with research issues and a new method for SOSE. Findings – A set of guidelines that a SOSE method develops should consider when selecting or developing a new method. Research limitations/implications – Comparison of existing SOSE methods within the findings of the proposed framework. The paper has theoretical implications as the open issues provide a research roadmap towards the realization of SOA in accordance with a maturity model. Practical implications – This has practical implications as it: provides a better understanding of the approaches, as they are ambiguously used by the existing methods; and assists developers in deciding an approach having the necessary knowledge related to its process, strengths and weaknesses. Originality/value – None of the existing comparison framework has raised the level of abstraction up to generic methods such as top-down, green-filed, meet-in-the-middle and bottom-up. Keywords Advanced web applications, E-business models and architectures, Emerging interoperability standards, Internet quality of service, Service orientation, Service oriented software engineering, Comparison framework, Methods, Delivery approaches, SOA Paper type Conceptual paper

1. Introduction Service oriented architecture (SOA) is an architectural style to build business (Cummins, 2009) and technology solutions[1] (Bianco et al., 2007; Chung and Chao, 2007; Davies et al., 2008; Erl, 2009), namely software, as a composition of loosely

International Journal of Web Information Systems Vol. 9 No. 4, 2013 pp. 279-316 q Emerald Group Publishing Limited 1744-0084 DOI 10.1108/IJWIS-03-2013-0006

IJWIS 9,4

280

coupled, interoperable, distributed pieces of logic that have separated concerns and are provided as services. Service orientation (SO) is a new paradigm that shapes a service with a set of design principles such as self-description, self-containment, autonomy, abstraction, standard contract, sharing, and discoverability (Erl, 2009) in order to comply with SOA principles. This paradigm is an evolution of the object-orientation and component-based engineering to enforce service loose coupling and interoperability (Bean, 2010), in addition to the principles of separation of concerns and information hiding (Dijsktra, 1968; Parnas, 1972). SO aims at developing software solutions as basic and composite services (with respect to an architecture style that is SOA) that run on a distributed computing that is service oriented computing (SOC) (Erl, 2009; Papazoglou et al., 2008). This kind of solutions requires a new engineering approach; we refer to as SOSE. It concerns with engineering of services, compositions, and their management (Papazoglou, 2008). The service engineering concerns with basic service identification (SID), design, implementation, test, and deployment. The composition engineering concerns with mechanisms such as orchestration used to compose basic services into executable software solutions such as service-based applications supporting business processes, or choreography used to represent message exchanges between multiple business processes. The management and administration concern with the service (Casati et al., 2003; Papazoglou et al., 2011) and the inspection of the quality of the solution (Bianco et al., 2007). SOSE has entailed, as expected, provision of new methods, processes, delivery strategies, representation techniques (models), and tools for services, compositions, and management. Indeed, many SOSE methods from both academia and industry have been developed (Gu and Lago, 2011). These methods claim a delivery strategy from diverse alternatives, namely: top-down, bottom-up, meet-in-the-middle, or green-field (Brittenham, 2001; Papazoglou and van den Heuvel, 2006; Chen and He, 2010). Yet, there seem to be a confusion surrounding these strategies, as they seem to be ambiguous (Papazoglou and van den Heuvel, 2006) not only for the developers using these methods, but also for the creators of the methods. This is mainly due to a lack of: . a deep understanding of the process each strategy undergoes, including its input, output, and constraints; and . an assessment of the strengths and weaknesses of each strategy with respect to SO, SOA, and the context of their usage and development. This work concerns with these delivery strategies, we refer to as approaches that the existing (or to develop) methods use, specifically their description, specification, and comparison in order to come up with a better understanding of these strategies, the issues inherent in their use in SOA development, and their potential improvement. This will assist the analysts and developers in deciding the right strategy with respect to their SOA context and objectives. Indeed, it is important to plan when deciding how to realize (or provision) services by carefully examining the diversity of realization alternatives (strategies) and make the right choice (Papazoglou and van den Heuvel, 2006). This work first specifies these four approaches in terms: process, input, output, and constraints. Then, it questions:

Q1. To what extent an approach would consider the three aspect: service, composition, and management to deliver software solutions that are conform to SO and SOA principles. Q2. To what extent an approach would consider the aggregates of a method, including representation techniques (to express the solution at different levels of abstraction), assisting tools, and inspection techniques to assess the delivered solution (service and composition), in addition to the process. Q3. To what extent an approach would consider the alignment of business and IT through the application of model-driven development (MDD) by using standards such as model driven architecture (MDA) To answer these questions, we propose a comparison[2] framework that considers the following critical perspectives for SOSE methods based on SOA that would align IT with business: (1) SO design principles, and SOA principles, drivers, and maturity. (2) Aggregates of methods, including process, representation techniques (models, formalisms, and languages), tools (e.g. comprehensive CASE tools or limited such as generation, wrapper, composition tools, or registry finder tools), inspection techniques, and risks and tradeoffs to be considered in evaluating the software solution delivered by the approach. (3) Alignment of IT with business, which requires abstraction/refinement modeling and transformation rules, to systematically move from requirements to solution, as they are expressed with business and technology related artifacts, we refer to as business-oriented building blocks (BoBs) and technology-oriented building blocks (ToBs). An approach should represent different perspectives, views, and levels of abstraction of the solution with business and IT artifacts. To build the framework, first we describe and refine these perspectives in order to translate them into criteria. Then, we map these criteria to our main questions Q1-Q3 in order to provide each criterion with an attribute. Finally, we give the possible values to each attribute in accordance with the type and nature of each criterion. The framework first compares the four approaches with respect to above-mentioned criteria to show and discuss to what extent each of the approaches complies with each of the perspectives. Then, it highlights issues that need further research in order to come up with: . a newer or improved approach that not only would consider the three aspects of SOSE, but also perceive services and compositions as business values, i.e. services and compositions are realized and provided as economic value; or . a decision-making model that guides developers to use the right approach, according to their SOA context, specifics, and objectives. Finally, the findings are used to sketch out a layered architecture that would guide a compressive approach and readily map to standards such as MDA with respect to MDD that promotes alignment.

SOSE approaches

281

IJWIS 9,4

The remainder of the paper is organized as follows: Section 2 introduces a case example. Section 3 describes the four approaches and illustrates them with particular methods from academia and industry. Section 4 develops the framework within which we compare the approaches. Section 5 summarizes the comparison and states open issues that need further research. Section 6 sketches out a newer value-oriented approach. Section 7 presents some related work. Finally, a conclusion section presents further development.

282 2. Case example The case shows elements that we will use for illustration. It shows two businesses: the business “YB” and one of its partners “NB” along with some of their business and technical building blocks. Table I shows one business process (BP), one business event (BE), and some business objects (BOs) and business functions (BFs). These are BOBs. Table II shows some ToBs at design time (e.g. UML class diagram, UML use cases (UC), E-R, or industry standard interfaces), or run-time (e.g. legacy applications (LA), stored procedures, Java beans, EJB, or any class). For instance, the BP “order entry” requires different BOs such as “customer”, “order”, “item” that provide the necessary data and functions such “get quotation”, “check balance”, “check availability”, “fill order”, “pick order”, “pack order”, “ship goods”, “track shipment”, “bill order”, and “pay order”. That is data and BFs are encapsulated into BOs and provided as services (SVs) to the BPs. The ToBs implement the BoBs in the information system (IS). It is worth noting that these building blocks constitute enterprise assets that can be re-reused as services. 3. Types of approaches: generic methods Traditional software development approaches have been generally categorized into top-down or bottom-up (including reverse engineering). These types of approaches have been extended to green-field and meet-in-the middle, respectively, to cope with

Table I. Some BoBs of the business “YB” and its partner “NB”

Table II. Some ToBs of “YB” and “NB”

“YB” enterprise BOs

Event

BP

Customer order ...

Order entry ...

Customer Items Orders Invoices

UML UC

Design level UML classes or Standard E-R entity types interfaces

Check availability Check solvability

Customers Items Orders Invoice

I_get quotation I_purchase order I_track shipment I_tax calculation

SVs: activities/data Track shipment Tax calculation Check availability Check solvability

DB schema Set of SQL tables

“NB” enterprise: partner BOs SVs: activities/data Stock Bill ...

Ship order Bill order Get quotation ...

Implementation level Component and interface (any piece of code) Java bean, class Java interface, PL/SQL packages Interface description language (IDL) Legacy application

service development, as the traditional approaches cannot be blindly applied to web services and SOA (Papazoglou and van den Heuvel, 2006). These approaches describe the following aspects of service delivery strategy: . How web services are constructed, deployed, managed, and used. . How web service contracts are registered/retrieved into/from registries. . How existing packaged and LA are integrated into the service environment. This section first introduces common, basic concepts used by the approaches. Then, it introduces their specifics in terms of process, input, output, and constraints. Each step of the process is illustrated by using the case example described in Section 2. 3.1 The basic concepts To avoid confusion surrounding the approaches, the detailed description of the basic concepts, from both business and technology perspectives, is of paramount importance to understand how each of the four approaches works exactly. These are: . service (web service in this context); . service contract (abstract part and concrete/implementation part); . template; . business logic; . legacy application; . tools such as wrappers and generators; . service composition, including orchestration and choreography mechanisms; . technology architecture, namely platform; . SOA roles: provider, service, and registry; and . service life cycle (design, implementation, test, deploy, run, and manage). 3.1.1 Service. By service, we mean web service, it is a piece of code that has a URL and is accessible via internet protocol (e.g. SOAP over HTTP). For instances, “get quotation”, “ship good”, “invoice order”, or “track shipment” may be provided as services. 3.1.2 Service contract. Service contract is a machine-processable description of the service interface description. It exhibits the semantics of its functional (e.g. capabilities), non-functional (e.g. quality of service), the message description (or schema), and policy and agreement requirements. We distinguish the abstract part (e.g. what is the purpose of the service and its capabilities) from the concrete part (e.g. how and where can the service be accessed). This distinction is very important as an abstract part may be: . realized differently (e.g. location and protocol); . designed from scratch (by the provider); . reused from and existing industry standard (e.g. “i_get quotation”), or existing package (e.g. IDL/java/UML interface, abstract class, Oracle package); or . developed/generated and deployed separately from the concrete part. For instance, many services may implement the abstract part of the interface “i_get quotation” (describing one operation: “get quotation”, the message in “item id” and the

SOSE approaches

283

IJWIS 9,4

284

message out “price”), each service has its own location (where) and access and communication protocol (how). In addition, the same abstract part could exist as a local Java/UML interface or as an industry standard interface as shown in Table II. 3.1.3 Template. A template of the abstract part is a skeleton that contains a proprietary interface, including only the operations names along with their parameters. It is used, for instance, to map an existing interface such as IDL to a proprietary interface such as Java interface or Cþ þ abstract class. It also helps in designing a web service given a contract abstract part. In the context of web services technology, the contact is expressed in a service description language (e.g. WSDL) as shown in Table III. The abstract part is sometimes referred to as service interface, whereas the concrete part is referred to as service implementation definition as in Brittenham (2001). The contract is realized by a software agent implementing its business logic. 3.1.4 Business logic. The business logic implements the service contract. It may be an existing piece of software (legacy application) or a new application to develop/generate by using a tool. Table I shows many business activities that would map into services (e.g. “fill order”, “track shipment”, “bill”, “check availability”, or “check solvability”). It is worth noting that sometimes, the term service is meant to be exactly the business logic (i.e. business logic provided as a service). 3.1.5 Legacy application. A legacy application is an existing piece of code running under a proprietary platform. We are interested in those applications (business logic) that may be redeveloped, migrated, or wrapped to work in web service environment. 3.1.6 Tool. A tool is an automated tool that assists in the development process. In the web service context, it may be a WSDL editor, a WSDL generator, a registry-publishing tool, a wrapping tool, or a service generator such as Apache Axis engine and Java2WSDL that Java class that implements a service. 3.1.7 Service composition: orchestration and choreography mechanisms. Web services are developed to be reused in composing more coarse-grained web services or BPs (e.g. “order entry”), whereby a BP is a set of coordinated activities. The BP can be intra- or inter-organizational. Each composition has a style that may be an orchestration or choreography. An orchestration refers to an executable BP. It describes how web services invoke each other, under the control of one service. In the orchestration style, the BP is controlled and executed by one of the business parties involved in the process (e.g. “YB enterprise” in Table I). Choreography is associated with the message exchanges between multiple BPs (e.g. “YB enterprise” and “NB

Service Service contract

Table III. Service and service contract

Concepts

IT-example

Business example

Web service WSDL: abstract part or service interface descriptor WSDL: concrete part of service implementation descriptor

Component-moduleapplication IDL, Java interface, UML interface, abstract class, Oracle package URL of the service (URL þ port) Protocol to communicate with the service

“Ship goods”, “bill order”, “get quotation” Any contract along with service level agreement

enterprise”). In web services technology, business process execution language (BPEL) represents orchestration and web service choreography description language (WS-CDL) represents choreography. A BPEL is executable, whereas WS-CDL is just a description of collaboration between partners such as “YB” and “NB”. 3.1.8 Technology architecture (platform). The technology architecture refers to: . the platform that hosts the services, i.e. the web service server or application server under which runs the business logic that implements the service (e.g. EJB); and . the architecture of the IS that hosts the LA and the BOs.

SOSE approaches

285

3.1.9 SOA roles: service provider, consumer, and registry. In SOA architecture, there are three roles: service provider, requestor, and registry. We can define these roles from business, technology, and development perspectives as shown in Table IV. Figure 1 shows an instance of SOA, where the customer BO is provided as service. 3.1.10 Service development life cycle. Service life cycle means the activities that should be performed in a development process for service and service contract to reach at least the initial level of a SOA maturity model. These activities are: design, implementation, test, deploy, run, and manage. It is worth noting that a web service can be developed as: . new web service from scratch (new web service); Provider Business perspective Architecture perspective

Request

Owns the service

Registry

Business that needs the service Platform that hosts the service, Application or web service i.e. the server or application that invokes the service server that hosts the components that implements the service (e.g. EJB) Develops the service Uses the service

Development perspective

Registry

Public or private registry such as UDDI Develops the registry

Table IV. Roles in SOA from business, technology, and development perspectives

Service Provider Publish Contract (WSDL)

Registry: UDDI Find (Service Contract)

Owns the registry

Service Contract: WSDL • Check Solvability • ...

Check Solvability: WSDL SOAP Request of Customer Service (Check Solvability)

Application/Service: Order Entry

Customer: Web Service

SOAP Response (Y/N) Application Server

Service Consumer IS

Figure 1. SOA instantiated with web service: “customer” is exposed as a service

IJWIS 9,4

. .

by transforming an existing application into web service; or by composing a new service out of the existing service.

Similarly, a service contract may be developed from scratch (new service contract), or from an existing local or standard interface.

286

3.2 Approaches defined With respect to SOA and web service, the delivery approach, i.e. the engineering strategy depends on: . whether the service exists or not, i.e. whether the business logic that implements the service (e.g. class/component, or legacy application, or any piece of code) exists or not; and . whether the service contract exists or not, i.e. whether the specification of the abstract part exists (either locally or somewhere as standard interface) or not. When we combine these alternatives, we end up with four approaches (engineering strategies) to first develop services (Brittenham, 2001; Papazoglou and van den Heuvel, 2006), then compose them. These are top-down, bottom-up, green-field, and meet-in-the-middle approaches. It is worth noting that the green-field extends the top-down approach, whereas the meet-in-middle extends the bottom-up, as specified in the next section. Figure 2 summarizes the input/process/output of each approach ((a) top-down; (b) bottom-up; (c) green-field; and (d) meet-in-the middle). 3.2.1 Top-down approach: service contract exists and the web service is new (to develop). In a top-down approach, we need to develop new service from an existing contract (abstract part). A service contract (e.g. Java interface, Cþ þ abstract class, a UML interface, or an industry standard interface) is first located. Next, it is re-used (by creating a template of it, using IDL or a proprietary interface). Then, a development tool (preferably a CASE tool) is used to assist in designing, implementing and testing the business logic that implements the web service (based on the template). Finally the web service is deployed within a platform; and the concrete part of the contract is generated and published (the abstract part already exists). The following next steps describe the process of this approach as shown in Figure 2(a): S1.

Find the abstract part, i.e. find the interface locally (local private registry or the IS), or from an industry registry. The service abstract part (e.g. “i_get quotation”) is already published.

S2.

Generate a service abstract part template (a proprietary interface describing only the set of operations name and parameters) that must be implemented by the web service to be compliant with the service abstract part. For instance, map “i_get quotation” into proprietary interface such as Java interface.

S3.

Design, implement, and test the new web service by using the service abstract part template. This consists of designing, implementing (coding), and testing (i.e. all the operations of the abstract part work correctly) the application that represents the web service.

S4.

Deploy the run time code for the web service within the platform (e.g. a web service specific server or an application server).

SOSE approaches Legend Service Contract

Process

Template

Component

Input/output

Flow

Registry/IS

287

Legend for Figure 2 WSDL

Web Service: (Business Logic)

Template

Registry

Servers

Service Contract

Start Start

S2: Generate Service Contract (Abstract Part) Template

S1: Find Service Contract (Abstract Part)

S3: Design/Implement/ Test Web Service

S4: Deploy Web Service

S5: Complete Service Contract

Stop Stop

(a) Top-down: process of developing a new web service from an existing interface Service Contract

WSDL Registry

IS Business logic Servers

Start Start

S1: Find Business Logic

S3: Deploy Business Logic as Web Service

S2: Generate Service Contract (Abstract Part)


S5: Publish Service Contract

Stop Stop

(b) Bottom-up: process of generating a service contract from an existing logic New Service Contract

Web service: Business logic

WSDL

Registry

Servers

Start Start

S1: Design/ Implement/Test Web service

S2: Define/Generate new Web Service Contract

S3: Deploy Web Service

WSDL



Stop Stop

(c) Green-field: process of developing a new service from scratch Template IS/Registry

WSDL

Wrapper

Registry Servers

Service Contract

Start Start

S1: Find Service Contract (Abstract Part)

WSDL

S2: Generate (Abstract Part) Template

S3: Develop Web Service Wrapper~ Design & Implementation

S4: Deploy Wrapper



(d) Meet-in-the-Middle: process of wrapping existing logic and interface into web service

Stop Stop

Figure 2. Four processes to develop web service and its contract

IJWIS 9,4

288

S5.

Complete the service contract concrete part by adding “where” the web service has been deployed and can be invoked, and “how” to access it (technical aspect of the WSDL).

3.2.2 Bottom-up approach: service exists and the service contract is new (to develop). In the bottom-up approach, we need to develop and publish a new service contract for existing, implemented business logic (e.g. Java/Cþ þ class, and EJB, or any back-end legacy application). First, the business logic is located in the IS. Then, the service contract is generated by using a generation tool. This results in exposing the LA as web services. This may require a guidance for wrapping techniques (Al Belushi and Baghdadi, 2007; Lewis et al., 2008), especially when the legacy is hard to decompose. The following next steps describe the process of this approach as shown in Figure 2(b): S1.

Find the business logic from the IS (e.g. legacy application implementing “check availability”).

S2.

Generate the service contract abstract part (e.g. the set of operations and parameters) that would be implemented by this business logic so that the service conforms to the service abstract part.

S3.

Deploy the business logic within the platform (e.g. a web service specific server or an application server). If the logic is not deployable, then deploy a wrapper of it.

S4.

Complete the service contract concrete part by adding “where” the web service is deployed and can be invoked, and “how” to access it (technical aspect of the WSDL).

S5.

Publish the service contract.

In practice, both abstract and concrete parts are generated together in WSDL by using a WSDL generator, which would not allow the provider to manage different implementations (“how”, “where”) of the same service. 3.2.3 Green-field: both service and service contract are new. The green-field approach extends the top-down approach if there is a need to create a new web service contract for new service to be developed from scratch (e.g. new functional requirements, where the solution would be a service). The web service is first developed. Then, the service provider generates the web service contract (abstract and concrete part) from the deployed web service. This type of web service contract is created from scratch for the different functions such as “track shipment”, “check availability”, or “check solvability”. The following next steps describe the process of this approach as shown in Figure 2(c): S1.

Design, implement, and test the new web service. This consists in designing, implementing (coding), and testing (i.e. all of the operations of the abstract part work correctly) the application that represents the web service. For instance, develop the “track shipment” application from scratch by using the CASE tool and programming language at hand.

S2.

Define a new service contract abstract part (it can be generated from the implementation of the web service, where it must match the business logic.

S3.

Deploy the run time code for the web service within the platform (e.g. a web service specific server or an application server).

S4.


S5.

Publish the service contract (abstract and concrete parts) within a public or private registry.

3.2.4 Meet-in-the-middle: both service and service contract exist. The meet-in-the-middle extends the bottom-up approach, where both the service contract and the application that will be used for the web service exist. The meet-in-the-middle main task is to map the existing application interface to that defined in the web service contract (already defined as a requirement for instance). This can be done by creating a wrapper for the application that uses the service interface definition, and contains an implementation that maps the service interface into the existing application interface. The following next steps describe the process of this approach as shown in Figure 2(d): S1.

Find the abstract part, i.e. find the interface locally (local private registry or the IS) or from an industry specification registry. The service abstract part is already published.

S2.

Generate the service implementation interface template (a skeleton made up of a set of operations and parameters) that must be implemented by the web service to be compliant with the service contract.

S3.

Develop the web service wrapper by using the service implementation template, which entails a design and implementation of the web service wrapper. The web service wrapper will map the web service contract into the existing application interface.

S4.

Deploy the wrapper. The service interface is already published by another entity.

S5.


S6.

Publish the service contract (abstract and concrete parts) within a public or private registry.

The tasks of a web service wrapper are: . listing to the SOAP message of the clients willing to invoke a legacy application; . prepare the message to send to the legacy application according to the protocol used by legacy application (e.g. remote method invocation); and . invoke the legacy application with its proprietary protocol (e.g. remote method invocation).

SOSE approaches

289

IJWIS 9,4

290

3.3 Illustration of the approaches by existing methods To illustrate the approaches with existing methods, we have selected seven, including the most popular, from both academia and industry. We first present a brief description of each method. Then, we summarize in Table V some common characteristics such as process, SID, design, and construction, highlighting the approach they use. 3.3.1 Method descriptions. We briefly describe the methods focusing on the approach they use: M1. Service-oriented modeling and architecture (SOMA) (Arsanjani et al., 2008) consists of seven phases starting from business modeling (BM) and transformation to solution management. The SID phase comprises of a top down domain analysis and a bottom up existing system analysis. M2. Service oriented analysis and design method (Erl, 2009) is a 12-step to derive service candidates by analyzing business requirements analysis and existing systems, decomposing BP model in a top-down approach. M3. Web services development life-cycle methodology (SDLC) (Papazoglou and van den Heuvel, 2006) consists of eight phases that cover the service development life cycle, namely planning, analysis, design, construction, testing, provisioning, deployment, execution and monitoring of both services and service-based applications. It uses a gap analysis to reach a meet-in-the-middle delivery. M4. Service-oriented architecture framework (SOAF) (Erradi et al., 2006) uses two types of BP models: to-be modeling: a top-down business-oriented approach describing the candidate solution, and as-is modeling: a bottom-up approach describing current business processes and the existing systems. M5. Sensoria (Wirsing et al., 2007) follows an MDD engineering and creates models in UML2. It presents low-level interface details and service descriptions, claiming a meet-in-the-middle approach. M6. SoSR (Chung et al., 2007) is a service-oriented software reengineering method for modernizing legacy systems. It claims a bottom-up approach by consolidation of best practices. M7. Kim and Doh (2007) method utilizes UC to define and identify services. Use case analysis is used, in a kind of top-down approach, to identify cohesive functionalities within the boundary of a system. 3.3.2 Common characteristics to the illustrating methods. Although we present these methods for illustration to show how they use the aforementioned approaches, it is worth summarizing common characteristics to show to what extent the delivery strategy or approach (column 2) is in accordance with the other characteristics such as process, service and service contract identification, design, and construction as shown in Table V. Delivery strategy (approaches). Most of the methods claim one of the approaches as a delivery strategy top-down, bottom-up, or meet-in-the-middle, depending on the amount of analysis of the business domain and the modernization of existing LA.

Kim’s

SOSR

Sensoria

SOAF

SDLC

Erl’s

SOMA

Characteristics methods

PA, SID, BM, SDS PA, SID, BM, SDS, SCO, SP, BP and LA SMO PA, SID, BM, SDS, SCO AD and LA BM, SDS, SCO, SP, SMO PA, SID, BM, SCO, SP PA, SDS, SID, BM

Top-down

Meet-in-themiddle Meet-in-themiddle

Meet-in-themiddle

Bottom-up

Top-down

UC

LA

AD and LA

BP and LA

PA, SID, BM, SDS, SCO, SP, AD and LA SMO, SMM

Meet-in-themiddle

Identification

Process

Strategy

Service candidate

Support model

Service candidates and support models

Service candidates and support models Service candidates and support models Service candidates and support models

Construction Input Output

WSDL

WSDL

XML schema WSDL policies

XML schema, WSDL, policies XML schema WSDL policies

Both (reengineering, wrapping and migration) Reengineering, wrapping and migration Modernization and reengineering “ –” “–”

Both (wrapping)

WSDL and policies Both (reengineering, wrapping and migration) WSDL and policies “ –” “–”

Contract design Output

Service candidates and support models

Input

SOSE approaches

291

Table V. Approaches as claimed and used in different methods

IJWIS 9,4

292

Process. To show the extent to which service engineering lifecycle activities are described within the context of SOSE methods (Kohlborn et al., 2009). We have extended the scale of the process to: panning activities (PA), SID, BM, service design and specification (SDS), service construction (SC), i.e. implementation and testing, service publication (SP), service monitoring (SMO), and service management (SM). Service identification. This includes the type of input for identification phase, i.e. artifacts considered as input to SID (Gu and Lago, 2010) such as BP, application domain (AD), LA , or UC. Service contract design. The type of input includes identified candidate services or supporting models such as MDD. In addition, “ –” is used when the method does not include design phase. The type of output includes XML schema, WSDL, policy, or any other documents. In addition, “– ” is used when the method does not include design phase. Service construction. From scratch, by modernization of the LA or both of them, depending on the results of identification phase. 3.4 Discussion Each of the methods claims the use of at least one approach as delivery strategy. The top-down strategy is closely tied to existing business processes and functions, from which required services are identified and implemented using web services. The bottom-up strategy is the opposite in that it focuses on existing legacy systems, and services are identified and developed on an as-needed basis. The meet-in-the middle strategy attempts to reach a balance between business analysis and integration of services technologies. Yet, the characteristics in columns 3, 5-8 show the following: (1) The methods do not strictly follow the claimed delivery approach, i.e. each of the steps (when applicable): . service contract design or re-use (specifically industry standard interface in business); . strict separation of the parts of a contract (“what”, “how”, and “where”) that is intended to promote loose coupling, reuse (with the possibility to implement the same interface differently); . web service design, implementation, and test; . re-use from LA; . web service (or wrapper) deployment; and . registry of the service contract. (2) The methods do not explicit each role in SOA. Their respective process concentrates on the provider of the service, while the consumers and the registry not only have a role but also constrain SOA. (3) None of the methods uses a green-field approach, where both web service and service contact are developed from scratch, as it is not distinguished from top-down. While the separation of specification from implementation allows web services to be realized in these different delivery strategies, these strategies seem to ambiguous (Papazoglou and van den Heuvel, 2006). This is due mainly to the lack of a deep

understanding of each of the approaches, including their strengths, weaknesses, and context of use. Therefore, a comparison is required to show the issues that need to be tackled to improve these approaches, after having specified them, which will have an impact in: . Assisting the developers (creators) of the methods in using a service and composition delivery strategy to guide their development process, which constitutes the core of a SOSE method that leads to the realization of least the initial level of SOA maturity, i.e. the integration and composition. . Supporting the analysts and developers in deciding the appropriate approach to deliver services and compositions, then strictly following the process of the decided approach.

SOSE approaches

293

4. Comparison framework The proposed comparison framework is composed of a set of 17 criteria that are derived from the most relevant perspectives of SOSE: . SO; . SOA, to which we add; . the aggregates of any software engineering method; and . the alignment of the IT with business. This results in a sound set of criteria. The framework is mainly meant to discuss to what extent an approach complies with each of the perspective. To build the framework, first we describe and refine these perspectives in order to translate them into criteria. Next, we map these criteria to our main questions Q1-Q3 (above-mentioned in the introduction) in order to provide them with attribute as shown in the process of Figure 3 (a circle represents input/output, a rectangle represents a process, and an arrow represents a flow). Then, we provide a set of possible values to each attribute in accordance with the type and nature of each criterion. The next Section 4.1 describes the perspectives, whereas Section 4.2 details the framework. 4.1 Perspective description SO, SOA, the aggregates of a software engineering method, and the alignment of the IT with business constitute the main perspectives that yield a sound set of criteria for the comparison. We refine their description in order to come up with the criteria, their attributes and a set of possible values for each attribute. 4.1.1 SOA. OASIS (2006) defines SOA as: [. . .] a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover,

Perspectives: SO, SOA, Method Aggregates, and Alignment

Questions: Q1, Q2, and Q3 Refinement

Criteria

Mapping

Attributes with {Values}

Figure 3. Process to build the framework

IJWIS 9,4

294

interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

SOA architectural style. SOA is made up of components, connectors and constraints. Components are basic services and auxiliary services. Basic services are service consumer and service provider. Auxiliary services are enterprise service bus (ESB) to mediate the interactions, and service directory (or registry). Connectors are either synchronous/asynchronous calls using SOAP and HTTP, or a messaging infrastructure (Bianco et al., 2007). An approach should consider all the roles and components of SOA to be considered as “SOA styled”: Criterion 1. “SOA style”, attribute: “styled”, values: {Yes; No}. The attribute “SOA Styled” applies for both roles and auxiliary services such as ESB. SOA Principles . Loose coupling: services are independent from each other. When service S1 needs some functionality from another service S2, this need is separated from its realization. . Interoperability eliminates any technology specificity and constraints that may limit the ability of services to collaborate. Criterion 2. “SOA principles”, attribute: “promoted”, values: {Yes; No}. The attribute “promoted” applies for both principles. SOA drivers. SOA has several drivers, including integration with legacy systems, modernization of obsolete systems for many reasons, changing business partnerships (e.g. with suppliers and partners), and merging with new organizations. SOA is seemingly ideal for these situations (Bianco et al., 2007): Criterion 3. “SOA drivers”, attribute: “driven”, values: {integration; modernization; acquisition; merging} SOA maturity model. Capability maturity model integration (CMMI) (ESI, 2010) has defined five levels: L1 – “initial”, L2 – “managed”, L3 – “defined”, L4 – “quantitatively measured” and L5 – “optimizing”. An enterprise achieves a maturity level when it has substantially achieved the capabilities identified by this level. Most of SOA maturity models such as SIMM of IBM (Arsanjani and Holley, 2005), or Wipro (Inaganti and Aravamudan, 2007) build on CMMI. For instance, Welke et al. (2011) model provides SOA maturity model that considers SOA views and benefits at each of the five levels, namely reuse, standardization of data, BP redesign, flexibility and agility, and autonomic system (Welke et al., 2011). We use these levels as values for the attribute “level” as follows: Criterion 4. “SOA maturity”, attribute: “level”, values: {L1; L2; L3; L4; L5}. 4.1.2 Service orientation. SO is defined in Erl et al. (2008) as “a design paradigm comprised of a set of design principles, whereby a design principle is an accepted industry practice”. To conform to SO and to be a piece of composition, a service should exhibit some desirable properties that enforce the loose coupling and interoperability (in addition to the principles of separation of concerns and information hiding). These

desirable properties are: (P1) self-containment, (P2) autonomy, (P3) abstraction, (P4) Sstandard contract, (P5) stateless, (P6) sharing and reuse, and (P7) discoverability:

SOSE approaches

Criterion 5. “SO design principles”, attribute: “principled”, values: {Yes; No} 4.1.3 SOSE method aggregates. Developing a method for SOSE depends on many parameters, including the main building blocks, the state of art, the organization practices and skills, and the nature of the problems to be solved, to cite a few. These parameters vary from method to method, which explains the existence in the market of number of methods around the same computing paradigm (and even the same nature of problems). Yet, most of the methods should have a sound set of invariant aggregates that we can represent in a model (meta-method), where each distinct instantiation of the model produces a method. These aggregates are: Process. The process is set of coordinated engineering activities that produce a product (solution and documentation). A solution has distinct views with respect to the levels of abstraction/refinement and with respect to different types of stakeholders. Each view is either a level of abstraction/refinement or a facet of the solution. The process may be rigid or flexible, whereas the views and documentation (if any) concern with service, the composition, or both them: Criterion 6. “Process”, attribute: “flexibility”, values: {rigid; flexible}. Criterion 7. “Views of the solution”, attribute: “faceted”, values: {none; service; composition; both}. Criterion 8. “Solution documented”, attribute: “documented”, values: {none; partial; full}. Representation techniques. The representation techniques are models, formalisms, or languages, along with notations and diagrams, used to represent and express the views in order to reduce their complexity. This concerns with modeling of (if any) of the artifact service, composition, or both them: Criterion 9. “Modeled artifact”, attribute: “level”, values: {none; service; composition; both}. Tools. The tools are comprehensive CASE, tools, or limited to generation, composition, and wrappers that assist the production of the views. Criterion 10. “Assisted by tools”, attribute: “coverage”, values: {none; limited; comprehensive}. Inspection techniques. An inspection technique assesses and evaluates the quality of each view of the solution with quality attributes. Modifiability, performance, availability, security, reliability, interoperability, and testability are important quality attributes to consider when using a service oriented approach (Bianco et al., 2007). The evaluation concerns with both service (internal design) and composition. It uses various quality attribute requirements. It may be basic, simple, or advanced based on the questions of the scenarios used and the involved stakeholders: Criterion 11. “Quality attributes defined”, attribute: “level”, values: {none; service; composition; both}.

295

IJWIS 9,4

296

Criterion 12. “Solution inspected”, attribute: “scenario”, values: {none, basic, simple, advanced}. 4.1.4 Alignment of IT with business: building blocks. To align IT with business, a method should consider how to move systematically from business requirements to IT solution. That is, what are the representation techniques the method embodies to model different views of solution? This is possible when the building blocks, core elements upon which a solutions are built, are not only considered at different levels of abstraction, but also are abstracting/refining each other. A method should considers how business-oriented and technology-related building blocks are represented with models and how to transform models by refinement (e.g. top-down, green-field or forward engineering) or reversely by abstraction (e.g. bottom-up or reverse engineering), in a kind of MDD. Requirements. Requirements explore the needs of different stakeholders. They may be formal, semi-formal or informal. The formal specification promotes MDD: Criterion 13. “Requirements”, attribute: “formalized”, values: {formal; semi-formal; informal}. Business-oriented building blocks. BoBs are building blocks used at higher abstraction levels by the stakeholders. Indeed, building blocks identified at a higher level of abstraction allow creation of reusable, well documented and independent of technology/platform solutions. The purpose is to align IT solution to business. These are BOs, BFs, BEs, and BPs as shown in Table I: Criterion 14. “BoB”, attribute: “considered”, values: {Yes; No}. Technology-oriented building blocks. Most of existing methods for developing web services are based on lower abstraction levels, i.e. technology-oriented buildings blocks. These building blocks are used at design time or at run-time such as any piece of code (e.g. LA, Java beans, or EJB) as shown in Table II: Criterion 15. “ToB”, attribute: “considered”, values: {Yes; No}. Meta-model. For the alignment, a meta-model (or ontology) is used to allow models (representing the requirements and the views of the solution) to transform to each other for both forward and reverse engineering needs: Criterion 16. “Meta-model based”, attribute: “defined”, values: {Yes; No}. Transformation. To allow transformation from model to model, we need to use rules based on artificial intelligence constraint, or aspect. Criterion 17. “Transformation”, attribute: “rules”, values are {AI; constraint; aspect} 4.2 Framework explained: criteria, attributes, and values Table VI describes the framework, including, the perspectives, the questions Q1-Q3, and the criteria along with their attributes and a set of possible values for each attribute. After having defined the framework, we use it for comparing and analyzing the four approaches.

Alignment IT services with business

Aggregates of methods, including inspection techniques

Q1. To what extent an approach would consider the three aspect: service, composition, and management to deliver software solutions that are conform to SO and SOA principles

SOA and SO

Criteria

C1. SOA architectural style Three roles Auxiliary services (e.g. ESB) C2. SOA principles Loose coupling Interoperability C3. SOA drivers C4. SOA maturity considered (depending on the model) C5. SO design principles Q2. To what extent an approach C6. Process defined would consider the aggregates of a C7. Views of solutions at different method, including representation phases of the process C8. Documented solutions techniques to represent the (services and compositions) solution at different levels of abstraction, tools, and inspection C9. Services and compositions are techniques to assess the delivered modelled solution (service and composition), C10. Use of tools C11. Quality attributes defined in addition to the process C12. Solutions are inspected Q3. To what extent an approach C13. Requirements specification would consider the alignment of C14. Business building block business and IT through the C15. Technology building block C16. Meta-model based application of MDD C17. Transformation/mapping rules

Questions

Perspectives

{Rigid, flexible} {None; service; composition; both} {None; part; all} {None; only service; only composition; both} {None; limited; comprehensive} {None; service; composition; both} {None; basic; simple; advanced} {Formal; semi-formal; informal} {Yes; No} {Yes; No} {Yes; No} {AI-based; constraint-based; aspect-based} Flexibility Faceted Documented Level Coverage Level Scenario

Formalized Considered Considered Defined Rules

{Yes; No} {Yes; No} {Integration; modernization; merging; acquisition} {L1, L2, L3, L4, L4} {Yes; No}

Values

Styled Promoted Driven Level Principled

Attributes

SOSE approaches

297

Table VI. The framework defined

IJWIS 9,4

298

5. Approaches compared within the framework The framework uses the 17 criteria specified in Table VI to discuss to what extent each of the four approaches complies with each of the four perspectives. Table AI (in the Appendix) provides a comprehensive view of the comparison. 5.1 Comparison Tables VII-X show how each of the four approaches behaves against the criteria related to SOA, SO, aggregates of a SOSE method, and alignment, respectively. 5.2 Analysis and concluding remarks The comparison shows the following pluses of the approaches: . Top-down, green-field and meet-in-the middle can best suit for a planned SOA with maturity model, in addition they have flexible processes. . Top-down and met-in-the-middle are tied to existing contracts, which promotes standardization and reuse. . Both green-field and top-down would better suit for the alignment of the IT on the business as they may refine and transform the business building blocks such as BO, BF, or BP into technology building blocks such as services. . A green-field approach would better satisfy SO design principles. . Meet-in-the middle strategy attempts to reach a balance between business analysis and integration of existing LA. . Bottom-up strategy focuses on existing LA and services are identified and developed on an as-needed basis. . Meet-in-the-middle has a flexible process, which is suitable in case of acquisition or merging. Therefore: (1) Green-field and to some extent top down approach may be used if: . alignment of IT to business is a must. Indeed, newer approaches consider BoBs, in addition to the requirements are collected from end-users rather than from the existing ToBs; . readily satisfy SO design principles; and . need for robust web services that yield more that initial SOA maturity level, which would be meant to re-architect any solutions for flexibility and agility. (2) Meet-in-the-middle and to some extent bottom-up approaches may be recommended if: . urgent need for services, as process model they follow is rapid; . need a balance between business analysis and integration of services technologies; and . short term solution for acquisition or merging. However, to be recommended, these approaches need to be improved, as they present some critical issues. We categorize them with respect to the four perspectives: SO, SOA, methods aggregates, and alignment.

Yes No Yes No

Bottom-up

$ L1 Can plan for a SOA maturity model

Yes Can change the contract if the service change without problem Yes If WSDL and SOAP Modernization: redevelopment

Yes No Yes No

Approaches Green-field

Yes Can change the contract if the service change without problem Yes If WSDL and SOAP Integration Modernization (wrapping) Merging Acquisition Maturity (level) $L1 At most L1 Can plan for a SOA maturity At most integration model

Yes No Yes No

Architectural style Roles Provider Consumer Registry Auxiliary (ESB) Principles Loose coupling

No Service is developed for an existing contract Interoperability Yes If WSDL and SOAP Drivers Modernization: redevelopment

Top-down

Criteria

No Service is developed for an existing contract Yes If WSDL and SOAP Integration Wrapping Merging Acquisition $L1 Can plan for SOA maturity model

Yes No Yes No

Meet-in-the-middle

SOSE approaches

299

Table VII. Approaches compared against SOA principles

Table VIII. Approaches compared against SO design principles Bottom-up

Discoverable Yes Contract already published

Yes Generated contract is published

No Existing interfaces could not be designed having in abstraction Yes If WSDL generator is used

No Abstractions of existing implementations Yes If WSDL generator is used

No No mechanism can ensure that existing services are stateless Yes Yes Could be geared towards reuse if Need to make sure that the the principles of reuse applicable existing interfaces and components are reusable without any risk Yes Yes New contract is published Generated contract is published

Yes Service are newly created

Yes Newly designed services

Yes To some extent due to the existing interface and IT infrastructure Yes Newly designed services

Meet-in-the-middle

Yes New service and contract


Yes To some extent due to the existing components and IT infrastructure Autonomy No Yes Existing interfaces may limit the Existing components are autonomy of the services generally autonomous implementing them Abstraction Yes No If existing interfaces are Contract is generated designed as abstractions to be implemented not as abstractions of existing implementations Standard Yes Yes contract If WSDL or industry standard If a WSDL generator is used interface Stateless No No Service implements an existing No mechanism can ensure that interface existing services are stateless Sharing and Yes Yes It is the purpose of bottom-up reuse To some extent as it reuse contract, but the service is not necessarily reusable

SelfYes containment New service

Top-down

300

Criteria

IJWIS 9,4

Flexible Can adapt to new situation (e.g. new interface) Only service

Process defined

Quality attributes defined Solutions are inspected

Use of tools

Services and compositions are modelled

None

Rigid Service already exists

Bottom-up

Service Simple

Service New service may documented Both To some extent New service could be modeled If BPEL is used for representation and if composition is considered Limited Only WSDL generator

Flexible Can adapt to new situation (e.g. new business logic) Only service


Service May have already been documented Both Both To some extent To some extent If WSDL and BPEL are used Existing business logic may as representation languag have been modelled If BPEL is used for e and if composition is considered representation and if composition is considered If UML UC are used Limited Limited Only WSDL generator or Only WSDL generator registry finder Service None Simple None

Views of solutions at different phases of the process Documented solutions Service (services and compositions) If contract is standard

Top-down

Criteria

Service May have already been documented Both To some extent If business logic is already modelled If BPEL is used for representation and if composition is considered Limited Only WSDL generator and wrapper None None

Flexible Can adapt to new situation (e.g. new interface) None

Meet-in-the-middle

SOSE approaches

301

Table IX. Approaches compared against method aggregates

Transformation/ mapping (rules)

No

Yes To some extent if ontology is to describe contract Yes To some extent if ontology transformation No Unless generators are considered as such

Yes

Yes

No Existing service

Yes

Use of technology building block Meta-models based

Informal

Formalized

Bottom-up

Requirement specification Use of business building block

Table X. Approaches compared against alignment Top-down

No Unless generators are considered as such

No

Yes

Yes

Formalized


Yes To some extent if ontology is to describe contract Yes To some extent if ontology transformation

Yes To some extent as the contract may a business building block Yes

Semi-Formal

Meet-in-the-middle

302

Criteria

IJWIS 9,4

From SOA perspective . The approaches concentrate only on the provider of the service. Yet, the consumers and the registry not only have a role but also constraint SOA. . The approaches do not specify how services are combined into composition to support BPs. . Though web services constitute the most suitable realization of SOA, the approaches limit to SOA principles (loose coupling and interoperability), which are rather inherent to web service technology rather than SOA. SOA drivers and maturity model are not considered by the approaches. . The approaches cannot be blindly used for any of the SOA drivers. Indeed, top-down and greed-field are prone to modernization, whereas bottom-up and meet-in-the-middle are prone for merging and acquisition by using rapid wrapping. . None of the approaches consider SOA maturity level, though top-down and green-field are prone to SOA maturity model. From SO perspective . Not all the approaches comply with the service design principles, especially the bottom-up and meet-in-the-middle as they start from existing service contract and business logic (e.g. legacy application). From methodology perspective . None of the approaches considers different views of the solution (for different types of stakeholders), neither have they specified how the realized web services as technology solutions align with the business. . None of the approach provides representation techniques that would map into standard like UML for object orientation, except if WSDL and BPEL are considered as representation languages. . Although, the approaches consider the management aspect, it is limited to the service quality. None of the approaches provides a framework for inspecting a solution; neither have they considered the quality attributes of a solution. . Even if the wrapping modernization technique seems to be the most used by the methods to modernize LA. The approaches do not detail how it is done, i.e. is it a black-box or white-box wrapping technique. . The existing tools, limited to wrapping and generating WSDL, are longer sufficient though useful. A CASE tool should assist the three perspectives: service, composition, and management. A comprehensive CASE tool is a must to challenge the time to market. From alignment perspective . None of the approach concern with the requirements, i.e. how the requirements are specified. . Service is not perceived as value provided to the participants (node) of the value-chain (value-network) such as business (and its employees), customers,

SOSE approaches

303

IJWIS 9,4 .

304

partners, suppliers, or regulatory authorities. Indeed, none of the approaches explicitly considers the service as value, and consequently how the value is added to solution. The approaches lack of representation techniques, specifically modeling techniques that would promote MDD.

To summarize, the comparison advocates for a need of further research related to the aforementioned issues. 5.3 Open issues and further research Although the activities such as build, deploy, and run do exist, a comprehensive process model that promotes SOA development is lacking. Indeed, SOA is not only used for integration and composition, it is foreseen to promote agility of business through the reuse of services and the flexibility of their BPs. Therefore, the main component of SOA, that is service, needs to be regarded differently than a simple piece of code that is accessible via internet. Actually, the discipline of service science (Chesbrough and Spohrer, 2006) is not mature enough. We expect it to provide theories and methods from many different disciplines to study the service as a phenomenon in all business aspects (Demirkan et al., 2011). This new discipline would provide the fundamental properties of service regardless of its usages. These properties would themselves provide a set of service design principles. Further research is needed, which would advocate for newer approaches based on the concept of service as a value (service is realized and provided as economic value), since we believe, it is a core concept in SOA from both business and technology perspectives. That is, service needs to be perceived as value provided to the participants (i.e. change in their states) of the value-chain (or value-network). A value-network is a dependency network of activities that contribute to the value delivered to the participants (Cummins, 2009) such as business (and its employees), customers, partners, suppliers, or regulatory authorities. In a value-chain, value creation is viewed as a collaborative, creative, synergistic BPs. Indeed, a recent consensus of 400 considers that a business model describes the rationale of how an organization creates, delivers, and captures value (Osterwalder et al., 2010). For instance, the essence of a business is that it defines the manner by which the business delivers value to customers, entices customers to pay for value (Teece, 2010). This instance generalizes to all the stakeholders, elements of the value chain. We see web services providing value to the BPs, which in their turn provide value to one or more elements of the value-chain (or value-network). By value, we mean change in the state, with respect to a planned mission, goal, or objective. For instance, the service “ship goods” provides a value to the BP “order entry” by changing its state from “goods packed” to “goods shipped”. The BP “order entry” provides a value to the whole value chain, with respect to the goals/mission/objectives of each element. For instance, a perfect delivery changes the state of customer (e.g. “satisfied”), the state of business (e.g. “get paid and new income”), and similarly for partners, suppliers, and authorities who have their respective state changed.

In other words, approaches need to identify, specify, and design a technology service as a value to many applications. Each application is a supporting value for BPs (regarded as business service). Each BP is a value for one or many nodes of the value-network (value-chain). The basic services, the applications, and the BPs are services. While these services differ in granularity and abstraction level, they readily map to each other. Therefore, the approaches would consist first in understanding: . the value-chain (the value for each node), and the collaboration styles in use; . the BPs (as services) that provide this value; . the business services; and . the technology-related services. This requires designing the service and service contract in terms of value, and how this value it created, distributed, and consumed. This entails: (1) The concepts of service, value and their relationships: more fundamentals are needed with respect to service and value theories, and how they are related to each other, namely: . value-based architecture of any business or technology solution; . the creation of the value: how the value is created; . the delivery of the value: how the value is delivered; and . the consummation of value. The next section sketches out an approach based on the service as value from both business and technology perspectives. 6. Towards a new value-oriented approach guided by a multi-level architecture The findings of the comparison advocate for a newer (or at least improved) approach (along with its process) to deliver web services as main components of SOA. The process itself constitutes the core of a method to realize SOA with respect to different levels of maturity. This method would be better guided by a comprehensive multi-level architecture, where: level 1 deals with the value-chain; level 2 deals with BPs providing this value; level 3 deals with business services and BOs that provide values to BPs; and level 4 deals the technology-related services and compositions (applications) supporting the BPs. 6.1 The architecture defined The architecture consists of four levels linked by three mapping interfaces as shown in Table XI. The three higher levels are IT platform-independent; they deal with the business perspective of the web service’s strategy delivery. The lower level is a platform-dependent; it deals with the implementation, deployment and management of web services and compositions. It is commonly used in business IS development such as in Baghdadi (2012a). The business, BP requirement, and service requirements map to each other as follows:

SOSE approaches

305

Mapping L2/L3: transformation Business services and business objects

Mapping L3/L4: transformation Basic/composite service Execution Support

Interface 2

Interface 3

Level 4

Level 3

Level 2

Mapping L1/L2: transformation Business processes

Interface 1

Content

Technology

Running BPs (BPEL or workflows) IS implementing BOs LA Enterprise and partner service portfolio and ESB

Technologydependent

Business model in terms of Technologyvalue-network independent Identified value-network nodes Identified value for each node Cooperation and collaboration defined Business plan, goals, mission, and objectives Mapping value-networks and collaboration into BPs (values): validate the BPs with respect to the business goals/mission/objectives Agility Agile, flexible, intra- and inter- TechnologyFlexibility organizational BPs (value independent Composition provided) Integration Choreography defined Mapping the business BPs into business services and BOs providing them: validate the business services with respect to their usage Business-related services Business service Technologyindependent Reuse of BOs Set non-redundant, wellspecified and organized BOs, BFs (business logic) Mapping the business services and BOs into basic/composite services

Return on investment Level of SOA maturity that implies strategy and processes for of development Alignment

Business

Perspectives

Level 1

Table XI. Four-level architecture defined

Name

Attributes for quality service and interface Attributes of quality composition Technique

Attributes for quality BOs Technique

Attributes for quality BPs Technique

SOA maturity level Alignment Technique

Inspection

306

Levels

IJWIS 9,4

L1.

At the business level, the value-chain and the collaboration styles are defined.

L2.

At the BP level, the BPs that provide value to the value-chain (by consuming BOs provided as service or value), are defined.

L3.

At the business service level, the BOs, main providers of the business services, are defined.

L4.

At the service level, basic and composite services are defined and connected to the IS.

All the levels should be inspected with different techniques and scenarios. The multi-level architecture consists of separating the business in terms of value-chain and required BPs and the business services from the supporting technology platform in terms of web services. It mainly aims at: . Making decisions about SOA in terms of strategy and objectives (Wang, 2010), specifically the level of maturity of SOA. The decisions result in a proper alignment of the web services technology with business requirements (Baker et al., 2010). . Making the BPs and business services independent of the web services. Indeed, the web SM and monitoring may make changes for better quality assurance and exploitation. The BPs composed out of these web services will not be affected. . Making the identification and design of web services independent of the implementing platform (e.g. J2EE,.NET) to be able to enhance reusability of existing assets. . Inspecting SOA solutions at both business and technology levels. Moe importantly, the architecture provides guidance for a newer approach of delivering web services with respect to a decided SOA level of maturity. This approach describes a process that constitutes the core of a method. In other words, the architecture layers and interface may readily map into steps of the delivery process. To strengthen the approach with models and processes, the architecture could map into MDA, where a model representing a level may transformed into a model representing the level below it (in forward engineering) and vice-versa (for reverse engineering) in a kind of horseshoe model that could be used for reverse engineering, transformation, or forward engineering (Chikofsky and Cross, 1990). 6.2 Models and processes for each level The MDA approach uses models at three levels and the mapping between models. These are computational independent models (CIM), platform independent models (PIM) and platform specific models (PSM) (Kleppe et al., 2003). Table XII shows how our architecture maps into MDA. Levels 2 and 3 are combined into PIM, which describes the BPs. PSM uses the web services and BPEL. This requires: . Using a meta-model (or ontology) at CIM, PIM, and PSM levels. The key concepts of this meta-model are business model, value-chain, value, BP, business services, business object, and service. . Modeling levels by using this ontology to facilitate the transformation by using rules.

SOSE approaches

307

IJWIS 9,4

Content

Level

CIM

Business model in terms of value-network Identified value-network nodes Identified value for each node Cooperation and collaboration defined Business plan, goals/mission/objectives Transform network-value model and choreographies into service-oriented BP model Agile, flexible, intra- and inter-organizational BPs (value provided) Choreography defined Business service: set of non-redundant, well-specified and organized BOs, BFs (business logic), BOs, and existing BPs Transform service-oriented BP into executable such as BPEL such as query/view/transformation (QVT) or ATL Running BPs (BPEL or workflows), ESB IS implementing BOs and LA Enterprise and partner service portfolio

Level 1

308 CIM/PIM PIM

PI/PSM Table XII. Mapping the four-level architecture into MDA

Our architecture Interface

MDA/levels

PSM

.

Interface 1 Levels 2-3

Registry

Interfaces 2 and 3 Level 4

Using a service-oriented BM such described in Baghdadi (2013).

The resulting delivery approach would be an enhanced meet-in-the-middle, where ingredients from other approaches are mixed when required. Indeed, green-field and top-down perform well for the service alignment, and the bottom-up considers the existing LA that could not be left behind for many reasons. 7. Related work Most of the comparison frameworks have dealt with SID and methods comparison. In Al Ani and Baghdadi (2012), the authors compared the methods with respect to the SID approaches. Their research aims at providing a method to identify and classify the services. Gu and Lago (2010) have proposed a literature review on SID. The classification and comparison of 30 identification methods showed significant heterogeneity in the input/process/output of the studied methods. They reported in their conclusion the necessity of future research directions to improve the existing methods. In another work the same authors (Gu and Lago, 2011) proposed a comparison framework that highlights aspects that are specific to SOA and aims to differentiate the methodologies that are truly service-oriented from those that deal little with service aspects. As such, the authors suggest that the criteria defined in the framework can be used as a checklist for selecting a SOSE methodology. Kohlborn et al. (2009) have reviewed 30 service analysis approaches to conclude that a comprehensive approach to the identification and analysis of both business and supporting software service is missing. They proposed a consolidated approach to business and software services and identification that combine the strengths of the examined approaches. Ramollari et al. (2007) presented a state of the art survey of the some service oriented

engineering approaches and methodologies. They conclude that the service paradigm introduces unique requirements that should be addressed by innovative techniques. Another interesting point is that most of the surveyed SOA methodologies propose the meet-in-the middle strategy, where both business requirements and existing LA are taken into account to derive services. Although top-down analysis of the business domain produces services of high quality and long-term value, reality constraints require existing investment on IT infrastructure to be incorporated as well. In Papazoglou and van den Heuvel (2006), the authors provide an overview of the methods and techniques used in service-oriented design and development in order to provide a methodology from the point of view of both service consumer and provider. In Al-Rawahi and Baghdadi (2005), the authors have distinguished business-oriented approaches from technology-oriented approaches. Few works have directly concerned with the four approaches. Brittenham (2001) described the four approaches from a pure technical point of view of the service providers. In Baghdadi (2012b), the author sketched out a framework to select an approach for web service and SOA. This work could be regarded as an extension of these two works. The current study is also meant not only to open issue, but also to provide a comprehensive architecture that would map into a standard such as MDA with respect to MDD. A business-oriented approach for SOA needs to focus on: . the value a business can add to its stakeholders (participants in the value-network), where by the value must be created, distributed, and consumed; and . the expected SOA maturity model and its return on investment. 8. Conclusion First, we have described the four delivery approaches of web services: top-down, bottom-up, green-filed, and meet-in-the-middle, by defining their common, basic concepts; detailing their processes; and illustrating them with examples and with some popular methods from both academia and industry. Next, we questioned to what extent each of these approaches comply with four perspectives of SOSE that are SO, SOA, aggregates of methods, and alignment of technology solutions with business. Then, we have built a framework by refining these perspectives into 17 criteria, and mapping criteria to our main three questions to provide each criterion with an attribute and a set of possible values. Finally, we have compared the approaches within the framework, and analyzed and discussed the findings. Although, the approaches have several pluses, they lack some critical perspectives: . While the service engineering perspective and the management of the delivered services are given much importance, the composition perspective is not considered, even where some coarse-grained services are built by using finer ones. . The consumer and the registry are not given that much importance they deserve as they may constrain the architecture. Only the provider role is considered.

SOSE approaches

309

IJWIS 9,4

.

.

310

.

None of the approaches considers different views of a solution, neither have they provided a framework for inspecting a solution by assessing the quality attribute of a solution, expect for the SM. None of the approaches shows how the technology-related services are aligned on the business-related services and business processes, i.e. they lack models and transformation models. None of the approach considers the realization of services and compositions as value that participate to the value-chain.

These constitute open issues that need further research in order to come up with a newer or improved approach that considers these issues. In the light of the comparison findings, we have proposed a four-level architecture for SOA development, including service and composition as value provided to value-chain, and inspection of this value at both business and technology levels. In addition, it can map to MDA, in order to use a meta-model (or ontology), which would allow transformation of models from different levels. This architecture would guide a comprehensive delivery approach. Indeed, by considering the concept of service, at different levels of abstraction, as value that needs to be inspected, the approach will align technology with business in a SOA methodology that is geared towards reaching a planned SOA maturity level. This has practical implications as it: . provides a better understanding of the approaches, as they are ambiguously used by the existing methods; and . assists developers in deciding an approach having the necessary knowledge related to its process, strengths and weaknesses. It also has theoretical implications as the open issues provide a research roadmap towards the realization of SOA in accordance with a maturity model. This work would be further developed in many directions by exploring any of the open issues. For instance, comparison of some popular methods within the framework, though it is used for comparing generic approaches (delivery/engineering strategy); development of models and transformation with respect to MDD; development of delivery approaches for compositions; or development of inspection techniques at both business and technology level.

Notes 1. Although, SOA is not a technology (Cummins, 2009), it provides a set of principles to re-architect the software infrastructure (Chung and Chao, 2007). It is generally implemented using a whole series of newer, different technologies (Davies et al., 2008), mainly web services technology and standards. 2. We are not comparing the methods themselves but the approaches, as generic methods (or engineering strategies), each of the concrete methods follows. SOSE methods have been compared, in different contexts, within different frameworks (Al Ani and Baghdadi, 2012; Baghdadi, 2012a; Gu and Lago, 2010, 2011; Kohlborn et al., 2009; Ramollari et al., 2007).

References Al Ani, B. and Baghdadi, Y. (2012), “The application of service-oriented principles within service-oriented software engineering methods: a survey and comparison framework”, paper presented at IEEE IT Innovations 12 Conference, Al-Ain, UAE, April. Al Belushi, W. and Baghdadi, Y. (2007), “Approaches to wrap legacy applications into web services”, Proc. IEEE-ICSSSM07, pp. 1-6. Al-Rawahi, N. and Baghdadi, Y. (2005), “Approaches to identify and develop web services as instance of SOA”, Proc. of IEEE Int. Conference on Service Systems and Services Management, pp. 579-584. Arsanjani, A. and Holley, K. (2005), “Increase flexibility with the service integration maturity model (SIMM)”, available at: www-128.ibm.com/developerworks/webservices/library/wssoa-simm/ Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S. and Holley, K. (2008), “SOMA: a method for developing service-oriented solutions”, IBM Systems Journal, Vol. 47 No. 3, pp. 377-396. Baghdadi, Y. (2012a), “A methodology for web services-based SOA realization”, Int. Journal of Business Information Systems, Vol. 10 No. 3, pp. 264-297. Baghdadi, Y. (2012b), “A survey on approaches to identify and develop web-enabled services with respect to service-orientation and SOA: towards a value-oriented approach”, Int. Journal of Computer Applications in Technologies, Vol. 45 No. 1, pp. 1-14. Baghdadi, Y. (2013), “Modeling business processes with services: towards agile enterprise”, Int. Journal of Business Information System (in press). Baker, J., Jones, D., Cao, Q. and Song, J. (2010), “Conceptualizing the dynamic strategic alignment competency”, Journal of the Association for Information Systems, Vol. 12 No. 4, Article 2. Bean, J. (2010), SOA and Web Services Interface Design: Principles, Techniques, and Standards, The Morgan Kaufmann, Burlington, MA. Bianco, P., Kotermanski, R. and Merson, P. (2007), “Evaluating a service-oriented architecture”, Technical Report CMU/SEI-2007-TR-015, Software Architecture Technology Initiative, Carnegie Mellon, Pittsburgh, PA. Brittenham, P. (2001), Web Services Development Concepts, IBM Software Group, North Castle, NY. Casati, F., Shan, E., Dayal, U. and Shan, M. (2003), “Business-oriented management of web services”, Communications of the ACM, Vol. 46 No. 10, pp. 55-60. Chen, H. and He, K. (2010), “A method for service-oriented personalized requirements analysis”, Journal of Software Engineering and Applications, Vol. 1, pp. 59-68. Chesbrough, H. and Spohrer, J. (2006), “A research manifesto for services science”, Communications of the ACM, Vol. 49 No. 7, pp. 35-40. Chikofsky, E.J. and Cross, J.H. (1990), “Reverse engineering and design recovery: a taxonomy”, IEEE Software, Vol. 7 No. 1, pp. 13-17. Chung, J.Y. and Chao, K.M. (2007), “A view on service-oriented architecture”, Service-Oriented Computing and Applications, Vol. 1, pp. 93-95. Chung, S., Young, P.S. and Nelson, J. (2007), “Service-oriented software reengineering: Bertie3 as web services”, Proc. of ICWS, pp. 837-838. Cummins, F.A. (2009), Building the Agile Enterprise with SOA, BPM and MBM, The Morgan Kaufmann, Burlington, MA. Davies, J., Schorow, D., Ray, S. and Rieber, D. (2008), The Definitive Guide to SOA, Oracle, Redwood, CA.

SOSE approaches

311

IJWIS 9,4

312

Demirkan, H., Spohrer, J.C. and Krishna, V. (2011), The Science of Service Systems, Springer, New York, NY. Dijsktra, E.W. (1968), “The structure of “THE”-multiprogramming system”, Communications of the ACM, Vol. 11 No. 5, pp. 341-346. ESI (2010), “CMMIw for services, version 1.3: CMMI-SVC, V1.3 improving processes for providing better services”, Technical Report, CMU/SEI-2010-TR-034, ESC-TR-2010-034. Erl, T. (2009), SOA Design Patterns, Prentice-Hall, Upper Saddle River, NJ. Erl, T., Karmarkar, A., Walmsley, P., Haas, H., Yalcinap, U., Liu, C.K., Tost, A. and Pasley, J. (2008), Web Service Contract Design and Versioning for SOA, Prentice-Hall, Upper Saddle River, NJ. Erradi, A., Anand, S. and Kulkarni, N. (2006), “SOAF: an architectural framework for service definition and realization”, Proc. of Services Computing, SCC’06. IEEE International Conference, pp. 151-158. Gu, Q. and Lago, P. (2010), “Service identification methods: a systematic literature review”, ServiceWave, Vol. 6481, pp. 37-50. Gu, Q. and Lago, P. (2011), “Guiding the selection of service-oriented software engineering methodologies”, Service Oriented Computing and Applications, Vol. 5 No. 4, pp. 203-223. Inaganti, S. and Aravamudan, S. (2007), “SOA maturity model”, available at: http://bpmg. orgwww.bptrends.com/publicationfiles/04-07-ART-The%20SOA%20MaturityModelInagantifinal.pdf/ Kim, Y. and Doh, K.G. (2007), “The service modeling process based on use case refactoring”, in Abramowicz, W. (Ed.), BIS 2007, LNCS, Vol. 4439, Springer, Heidelberg, pp. 108-120. Kleppe, A.G., Warmer, J. and Bast, W. (2003), MDA Explained: The Model Driven Architecture: Practice and Promise, Addison-Wesley, Boston, MA. Kohlborn, T., Korthaus, A., Chan, T. and Rosemann, M. (2009), “Identification and analysis of business and software services – a consolidated approach”, IEEE Transactions on Services Computing, Vol. 2 No. 1, pp. 50-64. Lewis, G.A., Morris, E.J., Smith, D.B. and Simanta, S. (2008), Smart: Analyzing the Reuse Potential of Legacy Components in a Service-Oriented Architecture Environment, Carnegie Mellon University, Software Engineering Institute, Pittsburgh, PA. OASIS (2006), A Reference Model for Service Oriented Architecture, Organization for the Advancement of Structured Information Standards, Billerica, MA. Osterwalder, A., Pigneur, Y. and Smith, A. (2010), Business Model Generation, Wiley, Hoboken, NJ. Papazoglou, M.P. (2008), Web Services: Principles and Technology, Prentice-Hall, Upper Saddle River, NJ. Papazoglou, M.P. and van den Heuvel, W.J. (2006), “Service-oriented design and development methodology”, International Journal of Web Engineering and Technology, Vol. 2 No. 4, pp. 412-442. Papazoglou, M.P., Andrikopoulos, V. and Benbernou, B. (2011), “Managing evolving services”, IEEE Software, Vol. 28 No. 3, pp. 49-55. Papazoglou, M.P., Traverso, P., Dustdar, S. and Leymann, F. (2008), “Service-oriented computing: a research roadmap”, International Journal of Cooperative Information Systems, Vol. 17 No. 2, pp. 223-255. Parnas, D.L. (1972), “On the criteria to be used in decomposing systems into modules”, Communications of the ACM, Vol. 15 No. 1, pp. 1052-1058.

Ramollari, E., Dranidis, D. and Simons, J.H.S. (2007), “A survey of service oriented development methodologies”, 2nd European Young Researchers Workshop on Service Oriented Computing, pp. 75-89. Teece, D.J. (2010), “Business models, business strategy and innovation”, Long Range Planning, Vol. 43 Nos 2/3, pp. 172-194. Wang, P. (2010), “Chasing the hottest IT: effects of information technology fashion on organizations”, MIS Quarter, Vol. 34 No. 1, pp. 63-85. Welke, R., Hirschheim, R. and Andrew Schwarz, A. (2011), “Service-oriented architecture maturity”, IEEE Computer, Vol. 56, pp. 61-67. Wirsing, M., Carizzoni, G., Gilmore, G. and Go¨nczy, S. (2007), “A systematic approach to developing service-oriented systems”, White Paper, Information Society Technologies. Further reading Azevedo, L.G., Santoro, F., Baiao, F., Souza, J., Revoredo, K., Pereira, V. and Herlain, I. (2009), “A method for service identification from business process models in a SOA approach”, Enterprise, Business-Process and Information Systems Modeling, pp. 99-112. W3C (2010), “Web services architecture usage scenarios”, W3C Working Group Note, available at: www.w3.org/TR/wsarch-scenarios (accessed 11 February 2004). Corresponding author Youcef Baghdadi can be contacted at: [email protected]

To purchase reprints of this article please e-mail: [email protected] Or visit our web site for further details: www.emeraldinsight.com/reprints

SOSE approaches

313

Table AI. Approaches compared within the framework

Abstraction

Autonomy

SO design principles C5: (SO design principles)

C4. Maturity (level)

C3. Drivers

Interoperability

Yes No Yes No

Bottom-up

Yes To some extent due to the existing components and IT infrastructure Yes Existing components are generally autonomous

No Existing interfaces may limit the autonomy of the services implementing them Yes No

Yes New service

No Service is developed for an existing contract

Yes No Yes No

Meet-in-the-middle

No

Yes Newly designed services

Yes New service and contract

No (continued)

Yes To some extent due to the existing interface and IT infrastructure Yes Newly designed services

Yes If WSDL and SOAP Integration Wrapping Merging Acquisition $L1 $L1 Can plan for a SOA maturity Can plan for SOA maturity model model

Yes Can change the contract if the service change without problem Yes If WSDL and SOAP Modernization: redevelopment

Yes No Yes No


Yes Can change the contract if the service change without problem Yes Yes If WSDL and SOAP If WSDL and SOAP Modernization: Integration Modernization (wrapping) redevelopment Merging Acquisition $L1 At most L1 Can plan for a SOA maturity At most integration model

SOA Style, principles, drivers, and maturity C1. Architectural style Roles Provider Yes Consumer No Registry Yes Auxiliary (ESB) No C2. Principles Loose coupling No Service is developed for an existing contract

Top-down

314

Criteria

IJWIS 9,4 Appendix

Standard contract

C7. Views of solutions at different phases of the process C8. Documented solutions Service (services and compositions) If contract is standard

Flexible Can adapt to new situation (e.g. new interface) Only service

Yes Contract already published

Discoverable

SOSE method aggregates C6. Process defined

Yes To some extent as it reuse contract, but the service is not necessarily reusable

Sharing and reuse

Stateless

Contract is generated

If existing interfaces are designed as abstractions to be implemented not as abstractions of existing implementations Yes If WSDL or industry standard interface No Service implements an existing interface

Abstractions of existing implementations


Service New service may documented

Service May have already been documented

None

Flexible Can adapt to new situation (e.g. new business logic) Only service

Yes New contract is published

Yes Could be geared towards reuse if the principles of reuse applicable

Yes Service are newly created

Rigid Service already exists

Yes Generated contract is published

No No mechanism can ensure that existing services are stateless Yes It is the purpose of bottomup

Yes Yes If a WSDL generator is used If WSDL generator is used

Bottom-up

Top-down

Criteria

Service May have already been documented (continued)

Flexible Can adapt to new situation (e.g. new interface) None

No No mechanism can ensure that existing services are stateless Yes Need to make sure that the existing interfaces and components are reusable without any risk Yes Generated contract is published

Yes If WSDL generator is used

Existing interfaces could not be designed having in abstraction

Meet-in-the-middle

SOSE approaches

315

Table AI.

Yes No

Yes Yes To some extent if ontology is to describe contract Yes To some extent if ontology transformation

C15. Use of technology building block C16. Meta-models based

C17. Transformation/ mapping (rules)

C11. Quality attributes defined C12. Solutions are inspected Simple Alignment C13. Requirement Formalized specification C14. Use of business Yes building block

C10. Use of tools

Formalized Yes

Informal No Existing service


Simple

None


No

Yes

Service

None

Both To some extent New service could be modelled If BPEL is used for representation and if composition is considered Limited Only WSDL generator


Both To some extent Existing business logic may have been modelled If BPEL is used for representation and if composition is considered Limited Only WSDL generator

Both To some extent: If WSDL and BPEL are used as representation language and if composition is considered If UML UC are used Limited Only WSDL generator or registry finder Service

Bottom-up

C9. Services and compositions are modelled

Table AI. Top-down

Yes To some extent if ontology is to describe contract Yes To some extent if ontology transformation

Yes To some extent as the contract may a business building block Yes

Semi-formal

None

Both To some extent If business logic is already modelled If BPEL is used for representation and if composition is Limited Only WSDL generator and wrapper None

Meet-in-the-middle

316

Criteria

IJWIS 9,4

A comparison framework for service-oriented software engineering ...

A comparison framework for service-oriented software engineering ...

Suggest Documents

A Framework for Software Engineering Experimental Replications

Software Engineering Reference Framework

A Reference Framework - Software Engineering II

Situational Requirement Engineering Framework for Global Software ...

A Company-based Framework for a Software Engineering ... - CiteSeerX

A Framework for Agile Reuse in Software Engineering ... - CiteSeerX

A Unified Framework for Software Engineering Process Improvement ...

A Framework for Software Engineering Experimental ... - Jeffrey Carver

A Process Framework for Global Software Engineering Teams

XP as a Framework for Practical Software Engineering Experiments

a framework for software performance engineering of client/server ...

A Framework for Counting Source Statements - Software Engineering ...

A Framework for Counting Source Statements - Software Engineering ...

A risk management framework for software engineering practice - Core

A Framework for Software Engineering Experimental ... - Jeffrey Carver

A Discipline for Software Engineering A Discipline for Software ...

Software Engineering Framework using Agile Dynamic System ...

Software Engineering Reference Framework - Eindhoven University of

Comparison of Software Architecture Reverse Engineering Methods

Software Engineering Framework for Digital Service ... - IEEE Xplore

software codesign framework for

Hypertext for Software Engineering

A Comparison Between Five Models Of Software Engineering

A Comparison Between Five Models Of Software Engineering