A comparison framework for service-oriented software engineering approaches Issues and solutions

Size: px
Start display at page:

Download "A comparison framework for service-oriented software engineering approaches Issues and solutions"

Transcription

1 The current issue and full text archive of this journal is available at wwwemeraldinsightcom/ 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 q Emerald Group Publishing Limited DOI /IJWIS

2 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:

3 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 (eg 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 SOSE approaches 281 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, ie 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

4 IJWIS 9,4 282 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 (eg UML class diagram, UML use cases (UC), E-R, or industry standard interfaces), or run-time (eg 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 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 UML UC Design level UML classes or E-R entity types Standard interfaces DB schema Implementation level Component and interface (any piece of code) Table II Some ToBs of YB and NB 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

5 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 31 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) SOSE approaches Service By service, we mean web service, it is a piece of code that has a URL and is accessible via internet protocol (eg SOAP over HTTP) For instances, get quotation, ship good, invoice order, or track shipment may be provided as services 312 Service contract Service contract is a machine-processable description of the service interface description It exhibits the semantics of its functional (eg capabilities), non-functional (eg quality of service), the message description (or schema), and policy and agreement requirements We distinguish the abstract part (eg what is the purpose of the service and its capabilities) from the concrete part (eg how and where can the service be accessed) This distinction is very important as an abstract part may be: realized differently (eg location and protocol); designed from scratch (by the provider); reused from and existing industry standard (eg i_get quotation ), or existing package (eg 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

6 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 313 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 (eg 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 314 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 (eg 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 (ie business logic provided as a service) 315 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 316 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 317 Service composition: orchestration and choreography mechanisms Web services are developed to be reused in composing more coarse-grained web services or BPs (eg 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 (eg YB enterprise in Table I) Choreography is associated with the message exchanges between multiple BPs (eg YB enterprise and NB Concepts IT-example Business example Table III Service and service contract Service Service contract 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

7 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 318 Technology architecture (platform) The technology architecture refers to: the platform that hosts the services, ie the web service server or application server under which runs the business logic that implements the service (eg EJB); and the architecture of the IS that hosts the LA and the BOs SOSE approaches 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 3110 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 Architecture perspective Development perspective Owns the service Platform that hosts the service, ie the server or application server that hosts the components that implements the service (eg EJB) Business that needs the service Application or web service that invokes the service Owns the registry Public or private registry such as UDDI Develops the service Uses the service Develops the registry Table IV Roles in SOA from business, technology, and development perspectives Registry Service Provider Registry: UDDI Publish Contract (WSDL) Service Contract: WSDL Check Solvability Find (Service Contract) Check Solvability: WSDL Application/Service: Order Entry Service Consumer SOAP Request of Customer Service (Check Solvability) SOAP Response (Y/N) Customer: Web Service Application Server IS Figure 1 SOA instantiated with web service: customer is exposed as a service

8 IJWIS 9,4 286 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 32 Approaches defined With respect to SOA and web service, the delivery approach, ie the engineering strategy depends on: whether the service exists or not, ie whether the business logic that implements the service (eg class/component, or legacy application, or any piece of code) exists or not; and whether the service contract exists or not, ie 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) 321 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 (eg 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, ie find the interface locally (local private registry or the IS), or from an industry registry The service abstract part (eg 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 (ie 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 (eg a web service specific server or an application server)

9 SOSE approaches Legend Template Process Service Contract Registry/IS Component Flow Input/output Legend for Figure Registry Template Web Service: (Business Logic) WSDL Service Contract Servers Start S1: Find Service Contract (Abstract Part) S2: Generate Service Contract (Abstract Part) Template S3: Design/Implement/ Test Web Service S4: Deploy Web Service S5: Complete Service Contract Stop (a) Top-down: process of developing a new web service from an existing interface IS Service Contract WSDL Registry Business logic Servers Start S1: Find Business Logic S2: Generate Service Contract (Abstract Part) S3: Deploy Business Logic as Web Service S4: Complete Service Contract S5: Publish Service Contract Stop (b) Bottom-up: process of generating a service contract from an existing logic Web service: Business logic New Service Contract WSDL Registry Servers WSDL Start S1: Design/ Implement/Test Web service S2: Define/Generate new Web Service Contract S3: Deploy Web Service S4: Complete Service Contract S5: Publish Service Contract Stop (c) Green-field: process of developing a new service from scratch IS/Registry Template Wrapper WSDL Registry Service Contract Servers WSDL Start S1: Find Service Contract (Abstract Part) S2: Generate (Abstract Part) Template S3: Develop Web Service Wrapper~ Design & Implementation S4: Deploy Wrapper S5: Complete Service Contract S6: Publish Service Contract (d) Meet-in-the-Middle: process of wrapping existing logic and interface into web service Stop Figure 2 Four processes to develop web service and its contract

10 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) 322 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 (eg 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 (eg legacy application implementing check availability ) S2 Generate the service contract abstract part (eg 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 (eg 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 323 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 (eg 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 (ie 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

11 S3 Deploy the run time code for the web service within the platform (eg 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 324 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, ie 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 (eg remote method invocation); and invoke the legacy application with its proprietary protocol (eg remote method invocation) SOSE approaches 289

12 IJWIS 9, 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 331 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 332 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

13 Strategy Process Identification Contract design Construction Input Output Input Output Characteristics methods WSDL and policies Both (reengineering, wrapping and migration) AD and LA Service candidates and support models PA, SID, BM, SDS, SCO, SP, SMO, SMM SOMA Meet-in-themiddle WSDL and policies Erl s Top-down PA, SID, BM, SDS BP and LA Service candidates and support models Both (wrapping) XML schema, WSDL, policies BP and LA Service candidates and support models PA, SID, BM, SDS, SCO, SP, SMO SDLC Meet-in-themiddle Both (reengineering, wrapping and XML schema WSDL policies PA, SID, BM, SDS, SCO AD and LA Service candidates and support models SOAF Meet-in-themiddle migration) Reengineering, wrapping and XML schema WSDL policies BM, SDS, SCO, SP, SMO AD and LA Service candidates and support models Sensoria Meet-in-themiddle 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 SOSE approaches 291 Table V Approaches as claimed and used in different methods

14 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), ie implementation and testing, service publication (SP), service monitoring (SMO), and service management (SM) Service identification This includes the type of input for identification phase, ie 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 34 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, ie 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

15 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, ie 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 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 41 describes the perspectives, whereas Section 42 details the framework 41 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 411 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 Refinement Criteria Questions: Q1, Q2, and Q3 Mapping Attributes with {Values} Figure 3 Process to build the framework

16 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 (eg 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} 412 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

17 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} 413 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 295

18 IJWIS 9,4 296 Criterion 12 Solution inspected, attribute: scenario, values: {none, basic, simple, advanced} 414 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 (eg top-down, green-field or forward engineering) or reversely by abstraction (eg 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, ie technology-oriented buildings blocks These building blocks are used at design time or at run-time such as any piece of code (eg 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} 42 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

19 Perspectives Questions Criteria Attributes Values {Yes; No} {Yes; No} {Integration; modernization; merging; acquisition} {L1, L2, L3, L4, L4} {Yes; No} C1 SOA architectural style Styled Three roles Promoted Auxiliary services (eg ESB) Driven C2 SOA principles Level Loose coupling Principled Interoperability C3 SOA drivers C4 SOA maturity considered (depending on the model) 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 {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} Flexibility Faceted Documented Level Coverage Level Scenario C5 SO design principles 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 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 Aggregates of methods, including inspection techniques {Formal; semi-formal; informal} {Yes; No} {Yes; No} {Yes; No} {AI-based; constraint-based; aspect-based} Formalized Considered Considered Defined Rules C13 Requirements specification C14 Business building block C15 Technology building block C16 Meta-model based C17 Transformation/mapping rules Q3 To what extent an approach would consider the alignment of business and IT through the application of MDD Alignment IT services with business SOSE approaches 297 Table VI The framework defined

20 IJWIS 9, 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 51 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 52 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

A Multifaceted Web Services Architecture: Toward a Meta-Service Framework for Service and Composition Development

A Multifaceted Web Services Architecture: Toward a Meta-Service Framework for Service and Composition Development Computer and Information Science; Vol. 7, No. 1; 2014 ISSN 1913-8989 E-ISSN 1913-8997 Published by Canadian Center of Science and Education A Multifaceted Web Services Architecture: Toward a Meta-Service

More information

A Comparison of SOA Methodologies Analysis & Design Phases

A Comparison of SOA Methodologies Analysis & Design Phases 202 A Comparison of SOA Methodologies Analysis & Design Phases Sandra SVANIDZAITĖ Institute of Mathematics and Informatics, Vilnius University Abstract. Service oriented computing is a new software engineering

More information

A Survey of Service Oriented Development Methodologies

A Survey of Service Oriented Development Methodologies A Survey of Service Oriented Development Methodologies Ervin Ramollari 1, Dimitris Dranidis 1, and Anthony J. H. Simons 2 1 South East European Research Centre (SEERC) 17 Mitropoleos Str., 54624 Thessaloniki,

More information

Introduction to Service Oriented Architectures (SOA)

Introduction to Service Oriented Architectures (SOA) Introduction to Service Oriented Architectures (SOA) Responsible Institutions: ETHZ (Concept) ETHZ (Overall) ETHZ (Revision) http://www.eu-orchestra.org - Version from: 26.10.2007 1 Content 1. Introduction

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Charlie Abela Department of Artificial Intelligence charlie.abela@um.edu.mt Last Lecture Web Ontology Language Problems? CSA 3210 Service Oriented Architecture 2 Lecture Outline

More information

Service-Oriented Architectures

Service-Oriented Architectures Architectures Computing & 2009-11-06 Architectures Computing & SERVICE-ORIENTED COMPUTING (SOC) A new computing paradigm revolving around the concept of software as a service Assumes that entire systems

More information

Service-Oriented Architecture and its Implications for Software Life Cycle Activities

Service-Oriented Architecture and its Implications for Software Life Cycle Activities Service-Oriented Architecture and its Implications for Software Life Cycle Activities Grace A. Lewis Software Engineering Institute Integration of Software-Intensive Systems (ISIS) Initiative Agenda SOA:

More information

Service Oriented Architecture Design and Development Method. Name: René van Donselaar. Universiteit Utrecht

Service Oriented Architecture Design and Development Method. Name: René van Donselaar. Universiteit Utrecht Service Oriented Architecture Design and Development Method René van Donselaar Universiteit Utrecht Notice of Originality I declare that this paper is my own work and that information derived from published

More information

Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies

Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies 3-day seminar Give Your Business the Competitive Edge SOA has rapidly seized the momentum and center stage because

More information

Government's Adoption of SOA and SOA Examples

Government's Adoption of SOA and SOA Examples Government's Adoption of SOA and SOA Examples Presented by : Ajay Budhraja, Chief of Enterprise Services ME (Engg), MS (Management), PMP, CICM, CSM, ECM (Master) AIIM, ITIL-F Copyright 2008 Ajay Budhraja

More information

Dagstuhl seminar on Service Oriented Computing. Service design and development. Group report by Barbara Pernici, Politecnico di Milano

Dagstuhl seminar on Service Oriented Computing. Service design and development. Group report by Barbara Pernici, Politecnico di Milano Dagstuhl seminar on Service Oriented Computing Service design and development Group report by Barbara Pernici, Politecnico di Milano Abstract This paper reports on the discussions on design and development

More information

Service Computing: Basics Monica Scannapieco

Service Computing: Basics Monica Scannapieco Service Computing: Basics Monica Scannapieco Generalities: Defining a Service Services are self-describing, open components that support rapid, low-cost composition of distributed applications. Since services

More information

Federal Enterprise Architecture and Service-Oriented Architecture

Federal Enterprise Architecture and Service-Oriented Architecture Federal Enterprise Architecture and Service-Oriented Architecture Concepts and Synergies Melvin Greer Chief Strategist, SOA / Cloud Computing Certified Enterprise Architect Copyright August 19, 2010 2010

More information

Service-Oriented Architecture and Software Engineering

Service-Oriented Architecture and Software Engineering -Oriented Architecture and Software Engineering T-86.5165 Seminar on Enterprise Information Systems (2008) 1.4.2008 Characteristics of SOA The software resources in a SOA are represented as services based

More information

A Quick Introduction to SOA

A Quick Introduction to SOA Software Engineering Competence Center TUTORIAL A Quick Introduction to SOA Mahmoud Mohamed AbdAllah Senior R&D Engineer-SECC mmabdallah@itida.gov.eg Waseim Hashem Mahjoub Senior R&D Engineer-SECC Copyright

More information

Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies

Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies Service Oriented Architecture (SOA) Architecture, Governance, Standards and Technologies 3-day seminar Give Your Business the Competitive Edge SOA has rapidly seized the momentum and center stage because

More information

Chapter 15. Web services development lifecycle

Chapter 15. Web services development lifecycle Slide 15.1 nology Chapter 15 Web Services Development Lifecycle Web Service es: Princip ples & Tech Mike P. Papazoglou mikep@uvt.nl Slide 15.2 Topics Web services development Properties of service development

More information

Reengineering Open Source CMS using Service-Orientation: The Case of Joomla

Reengineering Open Source CMS using Service-Orientation: The Case of Joomla Reengineering Open Source CMS using Service-Orientation: The Case of Joomla Tagel Gutema tagelgutema@gmail.com Dagmawi Lemma Department of Computer Science, Addis Ababa University, Ethiopia dagmawil@yahoo.com

More information

Service-Oriented Computing and Service-Oriented Architecture

Service-Oriented Computing and Service-Oriented Architecture Service-Oriented Computing and Service-Oriented Architecture Week 3 Lecture 5 M. Ali Babar Lecture Outline Service-Oriented Computing (SOC) Service-Oriented Architecture (SOA) Designing service-based systems

More information

Developing SOA solutions using IBM SOA Foundation

Developing SOA solutions using IBM SOA Foundation Developing SOA solutions using IBM SOA Foundation Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.3 4.0.3 Unit objectives After completing this

More information

SOA Myth or Reality??

SOA Myth or Reality?? IBM TRAINING S04 SOA Myth or Reality Jaqui Lynch IBM Corporation 2007 SOA Myth or Reality?? Jaqui Lynch Mainline Information Systems Email jaqui.lynch@mainline.com Session S04 http://www.circle4.com/papers/s04soa.pdf

More information

Architectural Decisions as Service Realization Methodology in Model-Driven SOA Construction

Architectural Decisions as Service Realization Methodology in Model-Driven SOA Construction December 4 6, 2006 Zurich, Switzerland Business Track Session 2, Talk 2 Architectural Decisions as Service Realization Methodology in Model-Driven SOA Construction From Analysis-Level Process Models to

More information

D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES

D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES 1. Principles of serviceorientation 2. Service exchange lifecycle 3. Service composition 4. Evolution of SOA 212 D.1 Principles of service-orientation 213 HISTORICAL

More information

Oracle SOA Reference Architecture

Oracle SOA Reference Architecture http://oraclearchworld.wordpress.com/ Oracle SOA Reference Architecture By Kathiravan Udayakumar Introduction to SOA Service Oriented Architecture is a buzz word in IT industry for few years now. What

More information

Emerging Technologies Shaping the Future of Data Warehouses & Business Intelligence

Emerging Technologies Shaping the Future of Data Warehouses & Business Intelligence Emerging Technologies Shaping the Future of Data Warehouses & Business Intelligence Service Oriented Architecture SOA and Web Services John O Brien President and Executive Architect Zukeran Technologies

More information

SOA CERTIFIED CONSULTANT

SOA CERTIFIED CONSULTANT SOA CERTIFIED CONSULTANT (5 Days) A Certified SOA Consultant is required to obtain proficiency in a cross-section of key SOA topic areas, including both conceptual and technical aspects of service-oriented

More information

CT30A8901 Chapter 10 SOA Delivery Strategies

CT30A8901 Chapter 10 SOA Delivery Strategies CT30A8901 Chapter 10 SOA Delivery Strategies Prof. Jari Porras Communications Software Laboratory Contents 10.1 SOA Delivery lifecycle phases 10.2 The top-down strategy 10.3 The bottom-up strategy 10.4

More information

Identification and Analysis of Business and Software Services A Consolidated Approach

Identification and Analysis of Business and Software Services A Consolidated Approach IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 2, NO. 1, JANUARY-MARCH 2009 1 Identification and Analysis of Business and Software Services A Consolidated Approach Thomas Kohlborn, Axel Korthaus, Member,

More information

Myths About Service-Oriented Architecture Demystifying SOA. producers can coexist, and still have no dependence on each other.

Myths About Service-Oriented Architecture Demystifying SOA. producers can coexist, and still have no dependence on each other. WSJ: SOA Myths About Service-Oriented Architecture Demystifying SOA Service-oriented architecture (SOA) refers to an architectural solution that creates an environment in which services, service consumers,

More information

Policy Driven Practices for SOA

Policy Driven Practices for SOA Independent Insight for Oriented Practice Policy Driven Practices for SOA Lawrence Wilkes CBDI Forum www.cbdiforum.com Agenda! Enterprise SOA Challenge! SOA Policy Areas! Layered Architecture as a basis

More information

Service Oriented Architecture 1 COMPILED BY BJ

Service Oriented Architecture 1 COMPILED BY BJ Service Oriented Architecture 1 COMPILED BY BJ CHAPTER 9 Service Oriented architecture(soa) Defining SOA. Business value of SOA SOA characteristics. Concept of a service, Enterprise Service Bus (ESB) SOA

More information

Enterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing

Enterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing Enterprise SOA Strategy, Planning and Operations with Agile Techniques, Virtualization and Cloud Computing Presented by : Ajay Budhraja, Chief, Enterprise Services ME (Engg), MS (Mgmt), PMP, CICM, CSM,

More information

Guiding Principles for Modeling and Designing Reusable Services

Guiding Principles for Modeling and Designing Reusable Services Guiding Principles for Modeling and Designing Reusable Services Max Dolgicer Managing Director International Systems Group, Inc. mdolgicer@isg-inc.com http://www.isg-inc.com Agenda The changing notion

More information

A standards-based approach to application integration

A standards-based approach to application integration A standards-based approach to application integration An introduction to IBM s WebSphere ESB product Jim MacNair Senior Consulting IT Specialist Macnair@us.ibm.com Copyright IBM Corporation 2005. All rights

More information

Service-oriented architecture in e-commerce applications

Service-oriented architecture in e-commerce applications Service-oriented architecture in e-commerce applications What is a Service Oriented Architecture? Depends on who you ask Web Services A technical architecture An evolution of distributed computing and

More information

SOMA, RUP and RMC: the right combination for Service Oriented Architecture

SOMA, RUP and RMC: the right combination for Service Oriented Architecture SOMA, RUP and RMC: the right combination for Service Oriented Architecture WebSphere User Group, Bedfont, 4th March, 2008 Keith Mantell Senior Solution Architect IBM Rational keith_mantell@uk.ibm.com March

More information

Extend the value of your core business systems.

Extend the value of your core business systems. Legacy systems renovation to SOA September 2006 Extend the value of your core business systems. Transforming legacy applications into an SOA framework Page 2 Contents 2 Unshackling your core business systems

More information

Business-Driven Software Engineering Lecture 3 Foundations of Processes

Business-Driven Software Engineering Lecture 3 Foundations of Processes Business-Driven Software Engineering Lecture 3 Foundations of Processes Jochen Küster jku@zurich.ibm.com Agenda Introduction and Background Process Modeling Foundations Activities and Process Models Summary

More information

Service-Oriented Architecture: Analysis, the Keys to Success!

Service-Oriented Architecture: Analysis, the Keys to Success! Service-Oriented Architecture: Analysis, the Keys to Success! Presented by: William F. Nazzaro CTO, Inc. bill@iconatg.com www.iconatg.com Introduction Service-Oriented Architecture is hot, but we seem

More information

Information as a Service in a Data Analytics Scenario A Case Study

Information as a Service in a Data Analytics Scenario A Case Study 2008 IEEE International Conference on Web Services Information as a Service in a Analytics Scenario A Case Study Vishal Dwivedi, Naveen Kulkarni SETLabs, Infosys Technologies Ltd { Vishal_Dwivedi, Naveen_Kulkarni}@infosys.com

More information

SOA GOVERNANCE MODEL

SOA GOVERNANCE MODEL SOA GOVERNANCE MODEL Matjaz B. Juric University of Ljubljana, Slovenia matjaz.juric@fri.uni-lj.si Eva Zupancic University of Ljubljana, Slovenia Abstract: Service Oriented Architecture (SOA) has become

More information

SOA REFERENCE ARCHITECTURE

SOA REFERENCE ARCHITECTURE SOA REFERENCE ARCHITECTURE August 15, 2007 Prepared by Robert Woolley, Chief Technologist and Strategic Planner INTRODUCTION This document is a derivative work of current documentation and presentations

More information

Principles and Foundations of Web Services: An Holistic View (Technologies, Business Drivers, Models, Architectures and Standards)

Principles and Foundations of Web Services: An Holistic View (Technologies, Business Drivers, Models, Architectures and Standards) Principles and Foundations of Web Services: An Holistic View (Technologies, Business Drivers, Models, Architectures and Standards) Michael P. Papazoglou (INFOLAB/CRISM, Tilburg University, The Netherlands)

More information

California Enterprise Architecture Framework. Service-Oriented Architecture (SOA) Reference Architecture (RA)

California Enterprise Architecture Framework. Service-Oriented Architecture (SOA) Reference Architecture (RA) California Enterprise Architecture Framework Service-Oriented Architecture (SOA) Reference Architecture (RA) Version 1.0 Final January 2, 2014 This Page is Intentionally Left Blank Version 1.0 Final ii

More information

Introduction to WebSphere Process Server and WebSphere Enterprise Service Bus

Introduction to WebSphere Process Server and WebSphere Enterprise Service Bus Introduction to WebSphere Process Server and WebSphere Enterprise Service Bus Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.3 Unit objectives

More information

MODELING OF SERVICE ORIENTED ARCHITECTURE: FROM BUSINESS PROCESS TO SERVICE REALISATION

MODELING OF SERVICE ORIENTED ARCHITECTURE: FROM BUSINESS PROCESS TO SERVICE REALISATION MODELING OF SERVICE ORIENTED ARCHITECTURE: FROM BUSINESS PROCESS TO SERVICE REALISATION Marek Rychlý and Petr Weiss Faculty of Information Technology, Brno University of Technology, Czech Republic, rychly@fit.vutbr.cz,

More information

Service Oriented Architecture

Service Oriented Architecture Service Oriented Architecture Service Oriented Analysis and Design (SOAD) in Practice Part 4 Adomas Svirskas Vilnius University October 2005 Agenda Service identification and definition Business process

More information

SOA Fundamentals For Java Developers. Alexander Ulanov, System Architect Odessa, 30 September 2008

SOA Fundamentals For Java Developers. Alexander Ulanov, System Architect Odessa, 30 September 2008 SOA Fundamentals For Java Developers Alexander Ulanov, System Architect Odessa, 30 September 2008 What is SOA? Software Architecture style aimed on Reuse Growth Interoperability Maturing technology framework

More information

Agile Modeling and Design of Service-Oriented Component Architecture

Agile Modeling and Design of Service-Oriented Component Architecture Agile Modeling and Design of Service-Oriented Component Architecture Zoran Stojanovic, Ajantha Dahanayake, Henk Sol Systems Engineering Group, Faculty of Technology, Policy and Management, Delft University

More information

SOA CERTIFIED JAVA DEVELOPER (7 Days)

SOA CERTIFIED JAVA DEVELOPER (7 Days) SOA CERTIFIED JAVA DEVELOPER (7 Days) To achieve this certification, the following exams must be completed with a passing grade: Exam S90.01: Fundamental SOA & Service-Oriented Computing Exam S90.02: SOA

More information

Open Source egovernment Reference Architecture Osera.modeldriven.org. Copyright 2006 Data Access Technologies, Inc. Slide 1

Open Source egovernment Reference Architecture Osera.modeldriven.org. Copyright 2006 Data Access Technologies, Inc. Slide 1 Open Source egovernment Reference Architecture Osera.modeldriven.org Slide 1 Caveat OsEra and the Semantic Core is work in progress, not a ready to use capability Slide 2 OsEra What we will cover OsEra

More information

SOA Enabled Workflow Modernization

SOA Enabled Workflow Modernization Abstract Vitaly Khusidman Workflow Modernization is a case of Architecture Driven Modernization (ADM) and follows ADM Horseshoe Lifecycle. This paper explains how workflow modernization fits into the ADM

More information

Introduction to Service-Oriented Architecture for Business Analysts

Introduction to Service-Oriented Architecture for Business Analysts Introduction to Service-Oriented Architecture for Business Analysts This course will provide each participant with a high-level comprehensive overview of the Service- Oriented Architecture (SOA), emphasizing

More information

Component-Based and Service-Oriented Software Engineering: Key Concepts and Principles

Component-Based and Service-Oriented Software Engineering: Key Concepts and Principles Component-Based and Service-Oriented Software Engineering: Key Concepts and Principles Hongyu Pei Breivold, Magnus Larsson ABB AB, Corporate Research, 721 78 Västerås, Sweden {hongyu.pei-breivold, magnus.larsson}@se.abb.com

More information

Prerequisites for Successful SOA Adoption

Prerequisites for Successful SOA Adoption George Feuerlicht University of Technology, Sydney jiri@it.uts.edu.au 1. INTRODUCTION The adoption of SOA (Service Oriented Architecture) has gained momentum in the past two years, and the predictions

More information

Outline SOA. Properties of SOA. Service 2/19/2016. Definitions. Comparison of component technologies. Definitions Component technologies

Outline SOA. Properties of SOA. Service 2/19/2016. Definitions. Comparison of component technologies. Definitions Component technologies Szolgáltatásorientált rendszerintegráció Comparison of component technologies Simon Balázs, BME IIT Outline Definitions Component technologies RPC, RMI, CORBA, COM+,.NET, Java, OSGi, EJB, SOAP web services,

More information

SOACertifiedProfessional.Braindumps.S90-03A.v2014-06-03.by.JANET.100q. Exam Code: S90-03A. Exam Name: SOA Design & Architecture

SOACertifiedProfessional.Braindumps.S90-03A.v2014-06-03.by.JANET.100q. Exam Code: S90-03A. Exam Name: SOA Design & Architecture SOACertifiedProfessional.Braindumps.S90-03A.v2014-06-03.by.JANET.100q Number: S90-03A Passing Score: 800 Time Limit: 120 min File Version: 14.5 http://www.gratisexam.com/ Exam Code: S90-03A Exam Name:

More information

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) VERSION 2.1 SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS 1 TABLE OF CONTENTS INTRODUCTION... 3 About The Service-Oriented Modeling Framework

More information

Enterprise Application Designs In Relation to ERP and SOA

Enterprise Application Designs In Relation to ERP and SOA Enterprise Application Designs In Relation to ERP and SOA DESIGNING ENTERPRICE APPLICATIONS HASITH D. YAGGAHAVITA 20 th MAY 2009 Table of Content 1 Introduction... 3 2 Patterns for Service Integration...

More information

Applying SOA to OSS. for Telecommunications. IBM Software Group

Applying SOA to OSS. for Telecommunications. IBM Software Group IBM Software Group Applying SOA to OSS for Telecommunications Kevin Twardus Manager of Industry Architecture and Standards IBM Software Group Communications Sector IBM Corporation The Details of SOA depends

More information

Web Application Development for the SOA Age Thinking in XML

Web Application Development for the SOA Age Thinking in XML Web Application Development for the SOA Age Thinking in XML Enterprise Web 2.0 >>> FAST White Paper August 2007 Abstract Whether you are building a complete SOA architecture or seeking to use SOA services

More information

Service Oriented Architecture Integration

Service Oriented Architecture Integration ORIENTAL JOURNAL OF COMPUTER SCIENCE & TECHNOLOGY An International Open Free Access, Peer Reviewed Research Journal Published By: Oriental Scientific Publishing Co., India. www.computerscijournal.org ISSN:

More information

Toward Next Generation Distributed Business Information Systems: Five Inherent Capabilities of Service-Oriented Computing

Toward Next Generation Distributed Business Information Systems: Five Inherent Capabilities of Service-Oriented Computing Toward Next Generation Distributed Business Information Systems: Five Inherent Capabilities of -Oriented Computing Chung, Sam and Davalos, Sergio Abstract The research conducted examines how the emerging

More information

10 Years of Hype Cycles - Do We Forget Knowledge?

10 Years of Hype Cycles - Do We Forget Knowledge? 10 Years of Hype Cycles - Do We Forget Knowledge? Aaron McConnell Research Scientist IU-ATC School of Computing and Information Engineering University of Ulster at Coleraine Northern Ireland Aaron McConnell

More information

Methods and tools for data and software integration Enterprise Service Bus

Methods and tools for data and software integration Enterprise Service Bus Methods and tools for data and software integration Enterprise Service Bus Roman Hauptvogl Cleverlance Enterprise Solutions a.s Czech Republic hauptvogl@gmail.com Abstract Enterprise Service Bus (ESB)

More information

SOA Architect Certification Self-Study Kit Bundle

SOA Architect Certification Self-Study Kit Bundle SOA Architect Certification Bundle A Certified SOA Architect has demonstrated proficiency in the mechanics of serviceoriented computing through the mastery of patterns, principles, practices, and industry

More information

A Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus

A Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus A Unified Messaging-Based Architectural Pattern for Building Scalable Enterprise Service Bus Karim M. Mahmoud 1,2 1 IBM, Egypt Branch Pyramids Heights Office Park, Giza, Egypt kmahmoud@eg.ibm.com 2 Computer

More information

Web Service Implementation Methodology

Web Service Implementation Methodology 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 Web Service Implementation Methodology Public Review Draft 1.0, 05 September 2005

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2008 Vol. 7 No. 7, September-October 2008 Applications At Your Service Mahesh H. Dodani, IBM,

More information

2 (18) - SOFTWARE ARCHITECTURE Service Oriented Architecture - Sven Arne Andreasson - Computer Science and Engineering.

2 (18) - SOFTWARE ARCHITECTURE Service Oriented Architecture - Sven Arne Andreasson - Computer Science and Engineering. Service Oriented Architecture Definition (1) Definitions Services Organizational Impact SOA principles Web services A service-oriented architecture is essentially a collection of services. These services

More information

SOA for Healthcare: Promises and Pitfalls

SOA for Healthcare: Promises and Pitfalls SOA for Healthcare: Promises and Pitfalls Dennis B. Smith dbs@sei.cmu.edu SOA in Health Care Conference: Value in a Time of Change Chicago, IL USA June 3, 2009 Agenda Healthcare IT Challenges SOA: The

More information

Independent Insight for Service Oriented Practice. An SOA Roadmap. John C. Butler Chief Architect. A CBDI Partner Company. www.cbdiforum.

Independent Insight for Service Oriented Practice. An SOA Roadmap. John C. Butler Chief Architect. A CBDI Partner Company. www.cbdiforum. Independent Insight for Oriented Practice An SOA Roadmap John C. Butler Chief Architect A CBDI Partner Company www.cbdiforum.com Agenda! SOA Vision and Opportunity! SOA Roadmap Concepts and Maturity Levels!

More information

Business Process Management Tampereen Teknillinen Yliopisto

Business Process Management Tampereen Teknillinen Yliopisto Business Process Management Tampereen Teknillinen Yliopisto 31.10.2007 Kimmo Kaskikallio IT Architect IBM Software Group IBM SOA 25.10.2007 Kimmo Kaskikallio IT Architect IBM Software Group Service Oriented

More information

SOA: The missing link between Enterprise Architecture and Solution Architecture

SOA: The missing link between Enterprise Architecture and Solution Architecture SOA: The missing link between Enterprise Architecture and Solution Architecture Jaidip Banerjee and Sohel Aziz Enterprise Architecture (EA) is increasingly being acknowledged as the way to maximize existing

More information

Technical Track Session Service-Oriented Architecture

Technical Track Session Service-Oriented Architecture Technical Track Session Service-Oriented Architecture Terry Woods Agenda A little history What is Service-Oriented Architecture? How do you build a Service-Oriented Architecture Solution? What is an Enterprise

More information

Service Oriented Architecture (SOA) An Introduction

Service Oriented Architecture (SOA) An Introduction Oriented Architecture (SOA) An Introduction Application Evolution Time Oriented Applications Monolithic Applications Mainframe Client / Server Distributed Applications DCE/RPC CORBA DCOM EJB s Messages

More information

Business Process Execution Language for Web Services

Business Process Execution Language for Web Services Business Process Execution Language for Web Services Second Edition An architect and developer's guide to orchestrating web services using BPEL4WS Matjaz B. Juric With Benny Mathew and Poornachandra Sarang

More information

Service Oriented Architectures

Service Oriented Architectures 8 Service Oriented Architectures Gustavo Alonso Computer Science Department Swiss Federal Institute of Technology (ETHZ) alonso@inf.ethz.ch http://www.iks.inf.ethz.ch/ The context for SOA A bit of history

More information

JOURNAL OF OBJECT TECHNOLOGY

JOURNAL OF OBJECT TECHNOLOGY JOURNAL OF OBJECT TECHNOLOGY Online at www.jot.fm. Published by ETH Zurich, Chair of Software Engineering JOT, 2008 Vol. 7, No. 8, November-December 2008 What s Your Information Agenda? Mahesh H. Dodani,

More information

SOA IN THE TELCO SECTOR

SOA IN THE TELCO SECTOR SOA IN THE TELCO SECTOR In order to optimize costs and improve IT management, companies look with greater interest at business process management and optimization issues. The present reference model for

More information

ITU-T Kaleidoscope Conference Innovations in NGN. Managing NGN using the SOA Philosophy. Y. Fun Hu University of Bradford y.f.hu@bradford.ac.

ITU-T Kaleidoscope Conference Innovations in NGN. Managing NGN using the SOA Philosophy. Y. Fun Hu University of Bradford y.f.hu@bradford.ac. ITU-T Kaleidoscope Conference Innovations in NGN Managing NGN using the SOA Philosophy Y. Fun Hu University of Bradford y.f.hu@bradford.ac.uk Next Generation Network (NGN) A IP/IMS based network Provide

More information

Service Oriented Architecture: A driving force for paperless healthcare system

Service Oriented Architecture: A driving force for paperless healthcare system 2012 International Conference on Computer Technology and Science (ICCTS 2012) IPCSIT vol. 47 (2012) (2012) IACSIT Press, Singapore DOI: 10.7763/IPCSIT.2012.V47.16 Service Oriented Architecture: A driving

More information

Business Process Management Enabled by SOA

Business Process Management Enabled by SOA Business Process Management Enabled by SOA Jyväskylä 8.5.2007 Kimmo Kaskikallio IT Architect IBM Software Brands Five middleware product lines designed to work together Service-Oriented Architecture (SOA)

More information

An Oracle White Paper October 2013. Maximize the Benefits of Oracle SOA Suite 11g with Oracle Service Bus

An Oracle White Paper October 2013. Maximize the Benefits of Oracle SOA Suite 11g with Oracle Service Bus An Oracle White Paper October 2013 Maximize the Benefits of Oracle SOA Suite 11g with Oracle Service Bus Maximize the Benefits of Oracle SOA Suite 11g with Oracle Service Bus Table of Contents Introduction...

More information

Guiding Principles for Technical Architecture

Guiding Principles for Technical Architecture This document is a statement of the principles that will guide the technical development of the Kuali Student system. It will serve as a reference throughout the full lifecycle of the project. While these

More information

Introduction to Service Oriented Architecture

Introduction to Service Oriented Architecture Introduction to Service Oriented Architecture CSCI-5828 Foundations of Software Engineering Ming Lian March 2012 Executive Summary This Executive Summary gives the straight word to the fresh that have

More information

Getting Started with Service- Oriented Architecture (SOA) Terminology

Getting Started with Service- Oriented Architecture (SOA) Terminology Getting Started with - Oriented Architecture (SOA) Terminology Grace Lewis September 2010 -Oriented Architecture (SOA) is a way of designing, developing, deploying, and managing systems it is neither a

More information

Automating Rich Internet Application Development for Enterprise Web 2.0 and SOA

Automating Rich Internet Application Development for Enterprise Web 2.0 and SOA Automating Rich Internet Application Development for Enterprise Web 2.0 and SOA Enterprise Web 2.0 >>> FAST White Paper November 2006 Abstract Modern Rich Internet Applications for SOA have to cope with

More information

SOA Success is Not a Matter of Luck

SOA Success is Not a Matter of Luck by Prasad Jayakumar, Technology Lead at Enterprise Solutions, Infosys Technologies Ltd SERVICE TECHNOLOGY MAGAZINE Issue L May 2011 Introduction There is nothing either good or bad, but thinking makes

More information

Tool Support for Developing Scalable J2EE Web Service Architectures. Guus Ramackers Application Development Tools Oracle Corporation

Tool Support for Developing Scalable J2EE Web Service Architectures. Guus Ramackers Application Development Tools Oracle Corporation Tool Support for Developing Scalable J2EE Web Service Architectures Guus Ramackers Application Development Tools Oracle Corporation guus.ramackers@oracle.com www.oracle.com Using All This in Real Life

More information

Table of Contents. 1 Executive Summary... 2 2. SOA Overview... 3 2.1 Technology... 4 2.2 Processes and Governance... 8

Table of Contents. 1 Executive Summary... 2 2. SOA Overview... 3 2.1 Technology... 4 2.2 Processes and Governance... 8 Table of Contents 1 Executive Summary... 2 2. SOA Overview... 3 2.1 Technology... 4 2.2 Processes and Governance... 8 3 SOA in Verizon The IT Workbench Platform... 10 3.1 Technology... 10 3.2 Processes

More information

Model Driven and Service Oriented Enterprise Integration---The Method, Framework and Platform

Model Driven and Service Oriented Enterprise Integration---The Method, Framework and Platform Driven and Oriented Integration---The Method, Framework and Platform Shuangxi Huang, Yushun Fan Department of Automation, Tsinghua University, 100084 Beijing, P.R. China {huangsx, fanyus}@tsinghua.edu.cn

More information

Designing an Enterprise Application Framework for Service-Oriented Architecture 1

Designing an Enterprise Application Framework for Service-Oriented Architecture 1 Designing an Enterprise Application Framework for Service-Oriented Architecture 1 Shyam Kumar Doddavula, Sandeep Karamongikar Abstract This article is an attempt to present an approach for transforming

More information

On-Demand Business Process Integration Based on Intelligent Web Services

On-Demand Business Process Integration Based on Intelligent Web Services 132 On-Demand Business Process Integration Based on Intelligent Web Services Xiaohua Lu 1, Yinsheng Li 1, Ying Huang 2 1 Software School, Fudan University, Shanghai, China Phone: +86-21-55664096-808, {0014010,

More information

David Pilling Director of Applications and Development

David Pilling Director of Applications and Development Service Oriented Architecture for Law Firms: SOA is inevitable, are you ready? David Pilling Director of Applications and Development "Things should be made as simple as possible, but no simpler. -- Albert

More information

CSCI 5828 Spring 2010 Foundations of Software Engineering. - Arpit Sud

CSCI 5828 Spring 2010 Foundations of Software Engineering. - Arpit Sud CSCI 5828 Spring 2010 Foundations of Software Engineering - Arpit Sud 1 Agenda What is it? Why to use it? When to use it? How to implement it? Where not to apply it? 2 Service oriented Architecture 3 What

More information

Service Governance and Virtualization For SOA

Service Governance and Virtualization For SOA Service Governance and Virtualization For SOA Frank Cohen Email: fcohen@pushtotest.com Brian Bartel Email: bbartel@pushtotest.com November 7, 2006 Table of Contents Introduction 3 Design-Time Software

More information

ANALYZING THE USAGE OF OPEN SOURCE PRODUCTS FOR SOA. Sajid Ali. A thesis submitted in partial fulfillment of the requirements for the degree of

ANALYZING THE USAGE OF OPEN SOURCE PRODUCTS FOR SOA. Sajid Ali. A thesis submitted in partial fulfillment of the requirements for the degree of ANALYZING THE USAGE OF OPEN SOURCE PRODUCTS FOR SOA By Sajid Ali A thesis submitted in partial fulfillment of the requirements for the degree of Master of Software Engineering of Distributed Systems School

More information

Service Oriented Architecture Based Integration. Mike Rosen CTO, AZORA Technologies, Inc. Mike.Rosen@Azoratech.com

Service Oriented Architecture Based Integration. Mike Rosen CTO, AZORA Technologies, Inc. Mike.Rosen@Azoratech.com Service Oriented Architecture Based Integration Mike Rosen CTO, AZORA Technologies, Inc. Mike.Rosen@Azoratech.com Mike Rosen ACCESS TO THE EXPERTS Consultant Chief Enterprise Architect for service and

More information

1 What Are Web Services?

1 What Are Web Services? Oracle Fusion Middleware Introducing Web Services 11g Release 1 (11.1.1.6) E14294-06 November 2011 This document provides an overview of Web services in Oracle Fusion Middleware 11g. Sections include:

More information