Software development methods: SOA vs. CBD, OO and AOP Mika Koskela, Mikko Rahikainen, and Tao Wan Helsinki University of Technology [email protected],[email protected],[email protected] Abstract. BeforetheemergenceofService-OrientedArchitecture(SOA), similarissueshavebeenaddressedbyothersoftwaredevelopmentparadigms including e.g. Object-Oriented Programming (OOP), Aspect-Oriented Programming (AOP) and Component-Based Development (CBD). In this study, these approaches are compared to SOA and their relation- ship is discussed. Different kind of criteria is used: methods of enabling softwarereuse,impactsonenterpriseapplications,architecturalpatterns and support for application extensions and versioning. It is concluded that many of the mechanisms provided by SOA can be enabled by soft- ware elements at the lower level. The main contribution of SOA is the focus on high-level business logic. SOA, CBD and OOP can be built on each other in layered manner with possible adoption of AOP having its effects on each level. Still, some things such as version control pose problems for each of the approaches. Key words: Service-Oriented Architecture, Object-Oriented Program- ming, Component-Based Development, Aspect-Oriented Programming, SOA, OOP, CBD, AOP 1 Introduction ServiceOrientationiscurrentlyoneofthemostappraisedparadigmsinsoftware engineering and enterprise IT. However, many of its claimed benefits have been addressed by previous approaches in software development. Additionally, soft- waresystemsarenotbuiltusingservicesastheonlyelementofconstructionbut lower level artifacts are also required. These can be represented by components or objects, for example. In this report, the Service-Oriented Architecture and Computing (SOA / SOC) approach is compared to other software development paradigms. The domain of investigation is software development and this is the perspective that is taken on SOA here. In the comparison, the main emphasis is on Component-Based Development (CBD) and Object-Oriented Programming (OOP) approaches but also Aspect-Oriented Programming (AOP) is discussed. Theobjectiveistoaddressthemainaimsandbenefitsoftheseapproaches.These are then compared to the characteristics of the Service-Oriented approach and differencesandsimilaritiesinbothmeansandendsarepointedout.Additionally, the relationship between these paradigms is described and their fitting together briefly explained. 2 Software development methods: SOA vs. CBD, OO and AOP This report is solely based on a literature study. In the study, the emphasis was on rudimentary literature discussing the approaches. This means that re- views on products and specific technologies as well as detailed implementation casestudieswereleftoutofthescopeoftheresearch.However,theaimwasalso toassesshowwelltheparadigmshavebeencurrentlyrealized.Inthecomparison of the approaches, specific frameworks of criteria are used. The report is structured as follows: first section 2, each focal paradigm is brieflyintroducedandtheapproachofsoftwarereusediscussed.Next,insection 3, the approaches are compared with one another. There are three angles to this:levelofabstraction,reuse,implementation,logicallayeringandsupportfor applicationextension.Finally,insection4,thefindingsofthesecomparisonsare discussed and the conclusions are made. 2 Background 2.1 Service-Oriented Computing and Architecture Papazoglou and Georgakopoulos [14] define Service-Oriented Computing (SOC) as a paradigm that utilizes services as fundamental elements of distributed ap- plication development. Accordingly, services are self-describing, open software components that communicate with each other over the Internet via public in- terfaces. Service-Oriented Architecture can be seen as an architectural concept based on SOC. Erl [3] recognizes the following characteristics for SOAs: – Loose Coupling: minimum amount of interdependencies between services – Service Contract: the interaction between services is based on a communi- cation and document agreement – Autonomy: services control the logic they encapsulate. – Abstraction: services hide their internal logic from the external environment except those parts that are described in the service contract. – Reusability: dividing logic to services promotes reuse. – Composability: services can be assembled from other services – Statelessness: minimum amount of activity specific information is stored. – Discoverability: the existence of discovery mechanisms so that services can be discovered by their users 2.2 Object Oriented Programming and Development Object oriented programming traces back to Simula language of 60s which was developedfordescribingandprogrammingsimulations.[17,PartIII]Late80sand 90s can be seen as a time frame when OOP moved to mainstream application development. Since then most influential OO-languages in industry have been C++ and Java. As a result of research and development in OO many tools and technologies have been introduced to support OO-based development as modeling languages, application servers, OO-databased or relational mapping tools and OO-based development processes. Software development methods: SOA vs. CBD, OO and AOP 3 In object oriented languages the execution flow of programs is passing mes- sages between objects which represents concepts of the problem domain. Each objectencapsulatesrelateddataorstateoftheobjectandoperationsinoneunit, compared to functional programming where data is usually passed as a parame- ter to a function. This encapsulation of data allows code reuse and transparent change of implementation. Grouping objects to classes and allowing subclasses to inherit both interfaces and implementation from their parent classes allows on the other hand building on existing code. Mappingpersistentstateofobjectstorelationaldatabasehasbeenonemajor technical problem in OOP. Handling persistent objects and transactions is not a simple task and development wise it is usually better to use existing solutions - applications servers from both OSS and software vendors have been made to allow developers of business applications to concentrate more on business logic. Also there is OO-middleware for distributed development like CORBA ORB- implementations and, JRMI and other messaging solutions that allow remote methods calls between objects on different nodes. Object oriented modeling is usually the first step in object oriented devel- opment model. From high level conceptual model of problem domain and use cases, the design phase continues eventually to lower level implementation view of classes and objects. Modeling of these aspects is usually carried out in stan- dardmodelinglanguagesuchasUML.Directionhavebeentowardsmodeldriven architecture, MDA, where actual program code can be compiled from modeling effort[12]. KeypromisesofOO-baseddevelopmentcanbelistedasincreasedcodereuse, easier building on existing code, better change tolerance and decrease in errors by data hiding and encapsulation and finally OO can be seen as natural way to model the problem domain. 2.3 Component Based Development A software component has been described as ”a nontrivial, nearly independent and replaceable part of a system that fulfills a clear function in the context of a well-definedarchitecture”byBrownandWallnau.Itisabletointer-communicate with other existing components with a predefined service. Clemens Szyperski and David Messerschmitt present the following five principles that a software component should have: – Multiple-use – Non-context-specific – Composable with other components – Encapsulated – A unit of independent deployment and versioning [23] Unlike objects in the Object Oriented Programming (OOP), a component is an ”OOP objects composed”, an object made to a specification. It does not concern what the specification is, such as, COM (Component Object Model), 4 Software development methods: SOA vs. CBD, OO and AOP DCOM (Distributed COM, JavaBeans and etc., as long as the object clings to the specification. This enables a component to obtain features like reusability, reusequalityandsoon.Inpractice,componentsarebuiltontopofmanysoftware ”objects” (although they are not confined to OOP) and provide a coherent unit of functionality. ”All ”objects” work together to performance a specific task at a particular level of service. ” [18] The idea of software componentized, built from prefabricated components, was first introduced in Dougalas McIlroy’s address at the NATO conference on softwareengineeringinGarmisch,Germany1968titledMassProducedSoftware Components. The modern concept of a software component was wildly defined by Brad Cox of Stepstone, who called then Software ICs and created an infras- tructure in order to market for these components by inventing the Objective-C programming language. [23] Aftermentioningwhatthesoftwarecomponentis,wearegoingtoinvestigate CBDE(Component Based Software Engineering) and CBD (Component Based Development).Aswellknow,whenyoupurchasesomePCcomponentsfromany marketvendorstosetupacomputer,itisveryeasytoassembly.Youdonotneed tobuildPCsystemfromhundredsofdiscreteparts,becauseeachcomponenthas been designed to compatible each other and standardized. CBSE also does the same thing in order to design and construct systems by using reusable software components. ”Making applications from software components had been a dream in soft- ware engineering community since its very early time. Programmers have re- lied on the reuse of code and data structures from as far back as 1968, when M.D.McILROYpublishedapapertitled”Mass-ProducedSoftwareComponents”.” [18] The purpose of CBSE is to improve QoS, productivity and time-to-market in software development. It encourages the compositions of software system and focus on reusing and adapting existing components.[18] There are three stages should be done in Components Based Development. 1. Componentqualification.Itisidentifiedbycharacteristics(performance,re- liability and usability) in their interfaces , and also checks reusable compo- nents. 2. Component adaption is needed. Because components will very less integrate with the system immediately. 3. Component composition, which integrates the components into a working system. Componentsmightchangetobeupdatedbasedontherequirementsofsystem changes.Inordertomakesureupdatestothecomponentsadheretothesystem architecture being developed. Summarily, they must be qualified and adapted if reusable components are available for potential integration. They also must be engineered if new components are added. [18] Software development methods: SOA vs. CBD, OO and AOP 5 2.4 Aspect Oriented Programming According to Kiczales et al. [10], traditional modularity approach cannot be applied in the construction of complex software systems. This is because they include aspects which cut across both one another and the actual executable code. These aspects include for example distribution and failure handling. The cross-cutting of aspects means that the software modules eventually become tangled with aspects. This is considered one of the main sources of complexity in software systems. Aspect-Oriented Programming (AOP) is a programming paradigm which deals directly with aspects of concern rather than modules of software code. The purpose of AOP is to remove the tangling by making it possible to express aspects of concern and then to combine those aspects with one another and executable code using automating tools. AlsoinAOPabstraction anddecomposition areusedtobreakdowncomplex problem.However, insteadoffunctional decomposition, AOPisbasedaspectual decomposition. This means that in Aspect-Oriented programming, the software artifacts do not remain contiguous in the executable program. Instead, the code resides in separate aspect descriptions which are spread over the actual exe- cutable program. [10] This enables decoupling the aspect-oriented code and other functionality. Therefore, the details of the aspects can be modified without having to modify all software code that the aspects affect. The modularization of the concerns is realized in AOP languages trough the following basic elements [2]: – Join point model which specifies the points in the code that the aspect enhancements are added in – means of identifying join points – means of specifying join point behavior – methods for combining aspects and their specifications – methods for attaching aspects to the program Aspectorientationhasalsobeenappliedtosoftwaredevelopmentstagespre- ceding programming, thus developing a Aspect-Oriented Software Development (AOSD)andAspect-OrientedDesign (AOD)disciplines.Itisthereforenecessary to observe software architecture from Aspect-Oriented angle. However, software architecture and aspect orientation have evolved separately as disciplines which poses problems in this process. Reasons for this are two-folded: firstly, it is diffi- cult to handle different aspects in a consistent, similar way in the architecture. Secondly, the same aspects can require different treatment in different systems. . In principle, integrating aspect into the software architecture requires defining thejoinpointsofthecomponentsandtheconnections betweendifferentaspects andcomponentsatthearchitecturallevel.Itcanbesaidthatwithsuchmethods, the simplicity of the design process is difficult to preserve. [13] 2.5 Reuse Based Development The NATO Software Engineering Conference in 1968 can be considered as a starting point for the software engineering view in general [16]. The aim of the 6 Software development methods: SOA vs. CBD, OO and AOP conference was to tackle the so-called software crisis: there was a need to build complex software systems in a controlled and cost-effective manner. From the beginning,thereuseofsoftwarecomponentswasconsideredtobeoneofthemain concerns in software engineering. In short, software reuse means using existing software artifacts in the construction of a new software system [11]. However, although the field in general has matured, software reuse has not become a standardpractice.Inadditiontoreusablepiecesofcode,softwarereuseincludes reusing e.g. modules, specifications and documentation [5]. All software reuse techniques can be analyzed based on four different dimensions [11]: 1. Abstraction: it is essential that the reusable artifacts are abstracted so that the developers can easily determine whether a reusable artifact is feasible for their needs and how this artifact should be used in a specific context. Abstraction is the most important aspect of software reuse. The idea is that softwaretypicallyconsistsofseverallayersofabstractioninwhichthehigher layershidethedetailsofthelowerlayers.Inotherwords,abstractiondistin- guishes specification representation on the higher level from the realization on the lower level. 2. Selection: artifacts are often categorized to guide the developers when they searchtheartifactlibrary.Alsothewaysofretrievingandexposingartifacts are essential to any software reuse technique. 3. Specialization: software artifacts are often merged into generic artifacts. To be able to use them, the developers have to specialize the artifact trough parameters or other kind of refinement. 4. Integration: software developers construct complete software systems from reusable artifacts using an integration framework. An example of this kind of framework is module interconnection language in which functions are ex- ported from modules that implement them and imported to modules that use them. Due to the generic nature of these issues, a multitude of software reuse tech- niques can be recognized. Krueger et al. (1992) divide software reuse into the following eight categories: – High level languages – Design and code scavenging – Source code components – Software schemas – Application generators – Very high-level languages – Transformational systems – Software architectures Accordingly, the difficulty in software reuse stems from the complexity of abstractions.Thedevelopersneedtobefamiliarwiththeabstractionstobeable tousethesoftwareartifacts.Forexample,ifalibraryofmathematicaloperations is used, domain knowledge is required. The use of abstract data structures, in contrast, necessitates understanding of the underlying semantics. [11] Software development methods: SOA vs. CBD, OO and AOP 7 3 Comparing approaches 3.1 Scope of SOA vs. OO, CBD and AOP The objectives of the four discussed software development approaches - Service- OrientedArchitecture,Object-Orientation,Component-basedDevelopmentand Aspect-OrientedProgramming-aresimilartosomeextent.Theycanallbecon- sidered as ways to promote software reuse and methods for structuring software systems into artifacts that can be managed separately for each other. However, these approaches have different scopes and focuses and they can be considered to operate on different levels of abstraction. Conceptually,theapproachesdefinedifferentsoftwaresystemcharacteristics. Bydefinition,servicesaresoftwarecomponents.Clearly,agoodservicecaptures the basic characteristics of a component. However, the characteristics of SOA define in more detail the software architecture that these specific components constitute. For instance, services operate in distributed environment and focus ondocument-centriccommunication.Incontrast,component-baseddevelopment doesnottakethatmuchstandonhowthecomponentsinteractwithoneanother -thisdependsonthetechnologythatthecomponentsarebasedon.Ontheother hand,componentscanprovidethebasisforservices,i.e.serviceinterfacesandthe structure of exchanges messages is often based on the component specifications. In turn, components can encapsulate objects. Aspect-orientation, on the other hand,canbeseenasacomplementaryparadigmaffectingthesoftwaresystemon several levels. Aspects are closely connected to objects and their classes because they affect directly to the methods at the code level. However, aspects must be also taken into account when relationships between different components are defined. Similarly, they affect the composition of services and therefore the eventual structure of SOA. Basedontheabovediscussion,alayeredorganizationofthedifferentartifacts defined by the approaches (figure 1) can be outlined: It can also be stated that the scope and level of ambition associated with each of the approaches is different. To truly leverage from SOA, one should aim at high service reusability at the enterprise level. Components provide similar benefits but on a smaller scale. Objects, on the other hand, can be adopted for a single application development project but they can still provide value. An enterprise-wideOO-architectureisofcoursealsopossibleandsignificant,evenif itwouldnotresultintheuseofcomponentsorservices.Finally,aspectsaddvalue especially if they are used across the enterprise. However, unlike services, they concentrate on a specialized, recurrent aspects, not reusable business functions like services. 3.2 Enterprise application with SOA, OO, CBD and AOP SOA Software components in a SOA are services based on standard protocols, whicharenotjustencapsulationofsomecodeofthelowerlayerofapplication.A service is a software asset of distinctive functional meaning that encapsulates a 8 Software development methods: SOA vs. CBD, OO and AOP Services(cid:13) Components(cid:13) Aspects(cid:13) Objects(cid:13) Fig.1. A layered organization of Objects, Components, Services and Aspects high-level business concept including contract, interfaces, implementation, busi- ness logic and data. OO and AOP have no corresponding elements for reposi- tories. Object-Oriented (OO) programming is a programming paradigm which deals with relationship between objects, and Aspect-Oriented Programming is alsoaprogrammingparadigmwithdealsdirectlywithaspectsofconcernrather than modules of software code. In SOA, Service repository provides facilities to discover services and ac- quires all information needed to the use of the service, especially if service must bediscoveredoutsidescopeoftheofenterprise;italsoprovidesadditionalinfor- mation to service contract like location, availability, QoS, Provider information, constraintsandsoon.Moreover,itisnecessarytoenablelongtermbenefitsand reuse. Service Bus is used to connect all participants of an SOA. ”In computing, an enterprise service bus (ESB) provides foundational services for more com- plex architectures via an event-driven and standards-based messaging engine, and generally provides an abstraction layer on top of an implementation of an enterprise messaging system which allows integration architects to exploit the value of messaging without writing code. ESB does not implement a SOA but provides the features with which one may be implemented. Although a com- mon belief, ESB is not necessarily web-services based. Most ESB providers now build ESBs to incorporate SOA principles and increase their sales, e.g. Business Process Execution Language (BPEL).” [22] CBD with COTS Modern enterprise application systems developing process become more and more large-scaled, uneasily controlled, complex. Also, due to time-to-market,nodevelopingstandardpressureandgrowingdemandofsearch- Software development methods: SOA vs. CBD, OO and AOP 9 ing for a cost-effective, efficient and satisfying multiple Quality of service (QoS) requirement software developing paradigm, enterprise application are developed by using commercial-off-the-shelf (COTS) components rapidly. Comparison to the traditional approach in which software systems can only be implemented from scratch; these COTS components can be developed by different vendor us- ing different languages and different computer platforms. In CBD, COTS com- ponents can be checked out from a component repository, and assembled into a target software system. So that Enterprise applications increasingly developed using COTS component middleware. Component middleware encapsulates sets of services in order to provide reusable building blocks that can be used to de- velopenterpriseapplicationsmorerapidlyandrobustlythanthosebuiltentirely from scratch.[7] There are many examples of CTOS component middleware like the Common Object Request Broker Architecture (CORBA), Component Ob- ject Model (COM), Distributed COM(DCOM), Sun Microsystem’s JavaBeans and Enterprise JavaBeans (J2EE), and emerging Web Services middleware such as .Net and ONE, based on XML and Simple Object Access Protocol (SOAP). Currently, the growing importance of open source enabled services in the economy and in most areas of business has been widely recognized. It is a very economy way to do deployment of an SOA that integrates various OSS systems with CBD in order to reduce the cost and improve the work efficiency. 3.3 Reuse AOP, OO, CBD and SOA do work at different levels of abstraction (3.1) . AOP at code level, OO at object level, CBD at component level and SOA at service level. This means that also reuse techniques are also working on different lev- els of abstraction. Software reuse can be divided to four different dimensions: abstraction, selection, integration and specialization (2.5, [11, p. 3]). To anal- yse differences in reuse techniques, these techniques can be categorized along dimensions (Table 1: Dimensions of reuse). As it can be seen, SOA methods for reuse are quite similar to OO and CBD methods. Service Interfaces are equivalent of class or component interfaces from reuse perspective as data ownership is equivalent of data hiding and encapsula- tion. Discoverability and use of service repositories is basic SOA principles to en- able reuse. For CBD and OO comparable method can be use of class and com- ponent libraries, though their use is not as strongly tied to methodology as use of repositories in SOA. For AOP there is not equivalent selection strategy. For integrating existing components, SOA has a concept of service compo- sitions which is facilitated by service bus. Equivalent CBD and OO-methods are method or function calls and application framework or middleware such as objectrequestbrokers,messagepassingmiddlewareandapplicationservers.For AOPthejointpointmodelallowsintegrationofdifferentaspectstocompleteap- plication. Comparing SOA and OO strategies, service composition using service bus is technically close to RPC calls between objects or components. 10 Software development methods: SOA vs. CBD, OO and AOP Method/Dimen- CBD OO AOP SOA sion Abstraction Component Classes, Decoupling of Service inter- Interfaces, Interfaces, aspects face/contract, Encapsula- Data hiding Data tion and ownership encapsulation Selection Component Class libraries NA Repositories libraries Integration Function Method calls, Join point Service class, ORBs ORBs etc. model composition, etc. ESB Specialization NA Inheritance NA Payload semantics Table 1. Dimensions of reuse For specialization SOA principle of payload semantics allows building more specializedcomponentsonexistingcodebyaddingnewmessagefields.Inobject orientedprogramminginheritanceisthemethodforcreatingsub-classesthatcan inheritimplementationandinterfacesfromsuper-classes.Thesemethodsarenot equivalent as payload semantics in itself only allows services to be extended but inheritance mechanism is built for the reuse in mind. Payload semantics could also be used in CBD or in OO development, but interface semantics and strong typingisusuallyusedasitisbuiltinforOO-languages.AsCBDcouldbedonein purelyprocedurallanguage,inheritancehasnotbeenincludedasareusemethod tothetable.Themethodsforreusearenotmutuallyexclusive.AsSOAandOO have different levels of abstraction, SOA development can also use OO based reuse mechanisms if services are programmed using object oriented principles. AOPcanbeusedonthesameprojecttoenablemorereusebyseparatingaspect specificcodefromdomain specificcodeiftheselectedframeworkandtoolshave support for it. 3.4 Layering and architectural patterns Layering is one key architectural principle in traditional software development. Martin Fowler[4] suggests three key architectural layers that are used in enter- prise applications (Table 2). Note: These layers are logical layers in application and can be distributed differently in normal N-tier architecture between tiers. For example in case of a thin client, most of the presentation logic could be on the server and in some cases to have faster response times some of the domain logic could be implemented on the client. When compared to N-tier architecture, in SOA services can call each other without tiered layering approach. But still these three principal layers are rep- resented in SOA application. Application front end is part of the presentation layer,domainlogicisimplementedinservicesandESBintegratesservices.Same