A comparison framework for
service-oriented software
engineering approaches
Issues and solutions
Youcef Baghdadi
Sultan Qaboos University, Muscat, Oman
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 The current issue and full text archive of this journal is available at
www.emeraldinsight.com/1744-0084.htm
Received 7 March 2013 Revised 7 June 2013 Accepted 10 June 2013
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
SOSE
approaches
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:
IJWIS
9,4
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
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. 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
“YB” enterprise “NB” enterprise: partner Event BP BOs SVs: activities/data BOs SVs: activities/data
Customer order Order entry Customer Track shipment Stock Ship order . . . Items Tax calculation Bill Bill order
Orders Check availability . . . Get quotation Invoices Check solvability . . .
Table I. Some BoBs of the business “YB” and its partner “NB”
Design level Implementation level
UML UC
UML classes or E-R entity types
Standard
interfaces DB schema
Component and interface (any piece of code) Check availability Check solvability Customers Items Orders Invoice I_get quotation I_purchase order I_track shipment I_tax calculation Set of SQL tables
Java bean, class
Java interface, PL/SQL packages Interface description language (IDL)
Legacy application Table II.
Some ToBs of “YB” and “NB”
IJWIS
9,4
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
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
Concepts IT-example Business example
Service Service contract
Web service
WSDL: abstract part or service interface descriptor WSDL: concrete part of service implementation descriptor
Component-module-application
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
Table III. Service and service contract
IJWIS
9,4
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.
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 Request Registry
Business perspective
Owns the service Business that needs the service
Owns the registry
Architecture perspective
Platform that hosts the service, i.e. the server or application server that hosts the components that implements the service (e.g. EJB)
Application or web service that invokes the service
Public or private registry such as UDDI
Development perspective
Develops the service Uses the service Develops the registry
Table IV. Roles in SOA from business, technology, and development perspectives
Figure 1. SOA instantiated with web service: “customer” is exposed as a service Application Server Service Contract: WSDL • Check Solvability • ... IS Customer: Web Service Registry: UDDI
Application/Service: Order Entry
Publish Contract (WSDL)
Find (Service
Contract) Check Solvability:WSDL
SOAP Request of Customer Service (Check Solvability)
SOAP Response (Y/N)
Service Provider Service Consumer Registry
SOSE
approaches
285
. 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.
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).
IJWIS
9,4
Figure 2. Four processes to develop web service and its contract
Template Process ContractService Registry/IS Flow Legend
Input/output Component
Legend for Figure 2
(a) Top-down: process of developing a new web service from an existing interface
Service Contract IS Business logic S1: Find Business Logic S2: Generate Service Contract (Abstract Part) S3: Deploy Business Logic as Web Service Servers S4: Complete Service Contract Start Start Stop Stop WSDL S5: Publish Service Contract Registry
(b) Bottom-up: process of generating a service contract from an existing logic
(c) Green-field: process of developing a new service from scratch
(d) Meet-in-the-Middle: process of wrapping existing logic and interface into web service
Service Contract Registry Template Web Service: (Business Logic) S1: Find Service Contract (Abstract Part) S2: Generate Service Contract (Abstract Part) Template S3: Design/Implement/
Test Web Service
Servers
S4: Deploy
Web Service
Start
Start S5: Complete StopStop
Service Contract WSDL Registry Web service: Business logic S2: Define/Generate
new Web Service Contract S1: Design/ Implement/Test Web service Servers S3: Deploy Web Service Start
Start S4: Complete StopStop
Service Contract S5: Publish Service Contract WSDL New Service Contract WSDL Service Contract Template Wrapper S1: Find Service Contract (Abstract Part) S2: Generate (Abstract Part) Template S3: Develop
Web Service Wrapper~ Design & Implementation
Servers
S4: Deploy
Wrapper
Start
Start StopStop
IS/Registry S5: Complete Service Contract S6: Publish Service Contract Registry WSDL WSDL
SOSE
approaches
287
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.
IJWIS
9,4
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. 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 (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. 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).
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
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.
IJWIS
9,4
Characteristics methods Strategy Process Identification Contract design Construction Input Output Input Output SOMA Meet-in-the- middle PA, SID, BM, SDS, SCO, SP, SMO, SMM AD and LA Service candidates and support models WSDL and policies Both (reengineering, wrapping and migration) Erl’s Top-down PA, SID, BM, SDS BP and LA Service candidates and support models WSDL and policies “ – ” “ – ” SDLC Meet-in-the- middle PA, SID, BM, SDS, SCO, SP, SMO BP and LA Service candidates and support models XML schema, WSDL, policies Both (wrapping) SOAF Meet-in-the- middle PA, SID, BM, SDS, SCO AD and LA Service candidates and support models XML schema WSDL policies Both (reengineering, wrapping and migration) Sensoria Meet-in-the- middle BM, SDS, SCO, SP, SMO AD and LA Service candidates and support models XML schema WSDL policies Reengineering, wrapping and migration SOSR Bottom-up PA, SID, BM, SCO, SP LA Support model WSDL Modernization and reengineering Kim’s Top-down PA, SDS, SID, BM UC Service candidate WSDL “ – ” “ – ” Table V. Approaches as claimed and used in different methods
SOSE
approaches
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
IJWIS
9,4
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.
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,
Figure 3. Process to build the framework
Perspectives: SO, SOA, Method
Aggregates, and
Alignment Refinement Criteria Mapping
Questions: Q1, Q2, and Q3 Attributes with {Values}
SOSE
approaches
293
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
IJWIS
9,4
desirable properties are: (P1) self-containment, (P2) autonomy, (P3) abstraction, (P4) Sstandard contract, (P5) stateless, (P6) sharing and reuse, and (P7) discoverability:
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}.
SOSE
approaches
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.
IJWIS
9,4
Perspectives Questions Criteria Attributes Values SOA and SO 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 C1. SOA architectural style
Styled Promoted Driven Level Principled
{Yes; No} {Yes; No} {Integration; modernization; merging; acquisition} {L1, L2, L3, L4, L4} {Yes; No} 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 Aggregates of methods, including inspection techniques Q2 . To what extent an approach would consider the aggregates of a method, including representation techniques to represent the solution at different levels of abstraction, tools, and inspection techniques to assess the delivered solution (service and composition), in addition to the process C6. Process defined C7. Views of solutions at different phases of the process C8. Documented solutions (services and compositions) C9. Services and compositions are modelled C10. Use of tools C11. Quality attributes defined C12. Solutions are inspected
Flexibility Faceted Documented Level Coverage Level Scenario
{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} Alignment IT services with business Q3 . To what extent an approach would consider the alignment of business and IT through the application of MDD C13. Requirements specification C14. Business building block C15. Technology building block C16. Meta-model based C17. Transformation/mapping rules
Formalized Considered Considered Defined Rules
{Formal; semi-formal; informal} {Yes; No} {Yes; No} {Yes; No} {AI-based; constraint-based; aspect-based} Table VI. The framework defined
SOSE
approaches
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.
IJWIS
9,4
Approaches Criteria Top-down Bottom-up Green-field Meet-in-the-middle
Architectural style Roles
Provider Yes Yes Yes Yes Consumer No No No No Registry Yes Yes Yes Yes Auxiliary (ESB) No No No No Principles Loose coupling No Yes Yes No Service is developed for an existing contract Can change the contract if the service change without problem Can change the contract if the service change without problem Service is developed for an existing contract Interoperability Yes Yes Yes Yes If WSDL and SOAP If WSDL and SOAP If WSDL and SOAP If WSDL and SOAP Drivers Modernization: redevelopment Integration Modernization: redevelopment Integration Modernization (wrapping) Wrapping Merging Merging Acquisition Acquisition Maturity (level) $ L1 At most L1 $ L1 $ L1 Can plan for a SOA maturity model At most integration Can plan for a SOA maturity model Can plan for SOA maturity model Table VII. Approaches compared against SOA principles
SOSE
approaches
Approaches Criteria Top-down Bottom-up Green-field Meet-in-the-middle Self-Yes Yes Yes Yes containment New service To some extent due to the existing components and IT infrastructure New service and contract To some extent due to the existing interface and IT infrastructure Autonomy No Yes Yes Yes Existing interfaces may limit the autonomy of the services implementing them Existing components are generally autonomous Newly designed services Newly designed services Abstraction Yes No No No If existing interfaces are designed as abstractions to be implemented not as abstractions of existing implementations Contract is generated Abstractions of existing implementations Existing interfaces could not be designed having in abstraction Standard Yes Yes Yes Yes contract If WSDL or industry standard interface If a WSDL generator is used If WSDL generator is used If WSDL generator is used Stateless No No Yes No Service implements an existing interface No mechanism can ensure that existing services are stateless Service are newly created No mechanism can ensure that existing services are stateless Sharing and Yes Yes Yes Yes reuse To some extent as it reuse contract, but the service is not necessarily reusable It is the purpose of bottom-up Could be geared towards reuse if the principles of reuse applicable Need to make sure that the existing interfaces and components are reusable without any risk Discoverable Yes Yes Yes Yes Contract already published Generated contract is published New contract is published Generated contract is published Table VIII. Approaches compared against SO design principles
IJWIS
9,4
300
Approaches Criteria Top-down Bottom-up Green-field Meet-in-the-middle Process defined Flexible Rigid Flexible Flexible Can adapt to new situation (e.g. new interface) Service already exists Can adapt to new situation (e.g. new business logic) Can adapt to new situation (e.g. new interface) Views of solutions at different phases of the process Only service None Only service None Documented solutions Service Service Service Service (services and compositions) If contract is standard May have already been documented New service may documented May have already been documented Services and compositions Both Both Both Both are modelled To some extent To some extent To some extent To some extent If WSDL and BPEL are used as representation languag Existing business logic may have been modelled New service could be modeled If business logic is already modelled e and if composition is considered IfUML UC are used If BPEL is used for representation and if composition is considered If BPEL is used for representation and if composition is considered If BPEL is used for representation and if composition is considered Use of tools Limited Limited Limited Limited Only WSDL generator or registry finder Only WSDL generator Only WSDL generator Only WSDL generator and wrapper Quality attributes defined Service None Service None Solutions are inspected Simple None Simple None Table IX. Approaches compared against method aggregates
SOSE
approaches
301
Approaches Criteria Top-down Bottom-up Green-field Meet-in-the-middle Requirement specification Formalized Informal Formalized Semi-Formal Use of business Yes No Yes Yes building block Existing service To some extent as the contract may a business building block Use of technology building block Yes Yes Yes Yes Meta-models based Yes No No Yes To some extent if ontology is to describe contract To some extent if ontology is to describe contract Transformation/ Yes No No Yes mapping (rules) To some extent if ontology transformation Unless generators are considered as such Unless generators are considered as such To some extent if ontology transformation Table X. Approaches compared against alignment
IJWIS
9,4
302
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
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.
IJWIS
9,4
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
Levels Name Perspectives Content Technology Inspection Level 1 Business Return on investment Business model in terms of value-network Technology- independent SOA maturity level Level of SOA maturity that implies strategy and processes for of development Alignment Identified value-network nodes Identified value for each node Cooperation and collaboration defined Alignment Technique Business plan, goals, mission, and objectives Interface 1 Mapping L1/L2: transformation Mapping value-networks and collaboration into BPs (values): validate the BPs with respect to the business goals/mission/objectives Level 2 Business processes
Agility Flexibility Composition Integration
Agile, flexible, intra-and inter-organizational BPs (value provided) Choreography defined Technology- independent Attributes for quality BPs Technique Interface 2 Mapping L2/L3: transformation Mapping the business BPs into business services and BOs providing them: validate the business services with respect to their usage Level 3 Business services and business objects Business-related services Reuse of BOs Business service Set non-redundant, well-specified and organized BOs, BFs (business logic) Technology- independent Attributes for quality BOs Technique Interface 3 Mapping L3/L4: transformation Mapping the business services and BOs into basic/composite services Level 4 Basic/composite service Execution Support Running BPs (BPEL or workflows) Technology- dependent Attributes for quality service and interface IS implementing BOs LA Enterprise and partner service portfolio and ESB Attributes of quality composition Technique Table XI. Four-level architecture defined
IJWIS
9,4
306
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.