PESOI: Process Embedded Service-Oriented Architecture

ISSN 100-9825, CODEN RUXUEWE-mail: jos@iscas.ac.cnJournal of Software, VoL.17, No.6, June 2006, pp.1470-1484htp://wwjos.org.cnDOI: 10.1360/jos171470Tel/Fax: +86- 10-62562563◎2006 by Journal of Software. All rights reserved.PESOI: Process Embedded Service-Oriented ArchitectureWei-Tek Isait, Yinong Chen, Chun Fan(Department of Computer Science and Engineering, Arizona State University, Tempe AZ, 85281, USA)+ Corresponding author: Phn: +1-480-7276921, Fax: +1-480-9652751, E-mail: wtsai@asu.eduTsai WT, Chen Y, Fan C. PESOI: Process embedded service-oriented architecture. Journal of Software, 2006,17(6):1470- -1484. htp://www.jos.org.cn/1000- 9825/17/1470.htmAbstract: Service Oriented Architecture (SOA) has drawn significant attention recently, and numerousarchitecture approaches have been proposed to represent SOA-based applications. The architecture of SOA-basedapplications is different from traditional software architecture, which is mainly static. The architecture of anSOA-based application is dynamic, i.e., the application can be composed at runtime using existing services, andthus the architecture is really determined at runtime, instead of design time. SOA applications have provided a newdirection for software architecture study, where the architecture can be dynanmically changed at runtime to meet thenew application requirements. This paper proposes a Process Embedded Service-Oriented Infrastructure to buildSOA-based applications. This infrastructure embeds the entire software lifecycle management and service-orientedsystem engineering into the application developed on this infrastructure. Thus, the users can easily re-develop theapplications during operation to meet the changing environments and requirements, through the supports providedby the embedded infrastructure.Key words: service -oriented computing; service-oriented architecture; software architecture; architectureclassification1 IntroductionService Oriented Architecture (SOA) has received significant attention recently as major computer andsoftware companies such as HP, IBM, Intel, Microsoft, and SAP, have all embraced SOA, as well as governmentagencies such as DoD (US department of defense) and NASA. The initial focus on SOA has been the developmentof interoperability standards and protocols, such as WSDL, SOAP, UDDI, and recently numerous SOA standardshave been proposed including ebSOA, ebXML, CPP, CPA, BPEL4WS, OWL-S, and RDF.SOA is a new software development paradigm in which software developers are grouped into three parties interms of their resposibilitis: the application builders (service requesters), the service brokers (service publishers),and the service providers (service developers), which is referred as the standard SOA. Service providers developservices independent of potential applications by following中国煤化工dards. Service brokerspublish the available services to the public such that the a, desired services andcompose the target application using the services. Thus a targe. aprJMYHCNMH Gservice discovery andservice composing instead of traditional process of designing and coding software.SOA has the following characteristics that are different from traditional software:反瓦教据006-02-15; Acepled 2006-03-14Wei-Tek Tsai, et al.: PESOI: Process Embedded Service Oriented Architecture1471Standard-Based interoperability: SOA emphasizes on stand based interface, protocols, communication,coordination, workflow, discovery, collaboration, and publishing via standard protocols. These standards allowservices developed in different computing platforms can interoperate with each other with the knowledge of servicespecifications only.Dynamic composition via discovery: SOA provides a new way of application development by composingservices just discovered. Furthermore, the composition and discovery can be carried out at runtime.Dynamic governance and orchestration: Execution of services needs to be controlled and severalmechanisms are available for execution control. One is service governance by policy. Specifically, policies can bespecified, checked, and enforced during both SOA development time and runtime to ensure the system complieswith the organization requirements. The other is orchestration where process execution will be coordinated by acentral controller and it is responsible for scheduling the execution of services that may be distributed across aconnectivity network such as ESB (enterprise service bus).A complex system is usually represented in layers, inPresentation: Portlets & WSRPRef.[1], a 5-layered architectural template is suggested forBusiness process choreographySOA applications, as ilustrated in Fig.l: Presentation,Services (composite services)Business process choreography, Services， Enterprise管冒Enterprise componentsg刘components, and Operational systems, with two supporting管mechanisms: Integration architecture and Management &Operational systermsmonitoring. The supporting mechanisms can be applied toFig.1 Layers of SOAeach of the five layers.Several studies have been conducted to investigate the architecture of SOA applications, e.g., IBM SOAFoundation architectull-4), Microsoft's .Net 2005 (Whitehore)5), SAP's NetWeaver'), OASIS's FERA7),enterprise SOA applications such as enterprise SOA[8] and Service-Oriented Enterprise (SOE)9), and self healingarchitecture PKUASI01.Software architecture has been an active research areas in software engineering for the last 10 years, withnumerous papers and books, such as Refs.[1,2,7-18]. Currently, several websites have been devoted to softwarearchitecture such as:Resources for Sofware Architects at htp://www.bredemeyer.com/;Global Enterprise Architecture Organization (GEAO) htp://www. geao.org;Software Engineering Institute at CMU software architecture at http://www.sei.cmu.edu/architecture/;Software architecture resource Sites at htp://ww2. umassd.edu/SECenter/SAResources.html;Handbook of Software Architecture at htp://www.booch.com/architecture/index.jsp.Most of the software architecture research projects focus on static architecture, where the emphasis is on:Architecture styles (layered architecture, object-oriented architecture, client-server architecture and soADL (architecture description language) and see the list of available ADLS at thehttp://www.sei.cmu.edu/architecture/adl.html;中国煤化工Architecture evaluation and analysis such as SAAM;JYCHCNMHGDocumentation of existing architectures, practices, and paltcuns,Architecture views such as module structure, process structure, conceptual structure, physical structure,call structures, data flow structure, control flow, and class structure, execution architecture; and●Formalization and specification of software architecture.1472Journal of Software 软件学报Vol.17, No.6, June 2006Recently, several studies have focused on dynamic software architecture, i.e., the software architecture thatmodifies its structure during execution!'31. The current research focuses on the formal specification techniques thatcan be used to reason and analyze dynamic architectures. A variety of reconfiguration rules such as graph rewritingrules, process algebra (such as cCs and CSP), predicate calculus, and architecture modification language (AML)191have been proposed to specify and analyze dynamic archiecturesl!3). However, these studies have not focused onthe dynamic SOA yet. One signifcant difference between the existing dynamic architecture and SOA is that thedynamic architecture of SOA is fully integrated with many aspects of software development, such as servicecomposition, code generation, and deployment.2 Dynamic Architecture and Lifecycle ManagementDue to the dynamic nature of SOA, the architecture of SOA-based systems has the following characteristicsdistinct from traitional software architectures: (1) Dynamic architecture via dynamic composition; (2) Lifecyclemanagement embedded in the operation infrastructure architecture.2.1 Dynamic architectureTraditional software architecture is static. Once the software is developed using components and connectionsamong the components, it cannot be changed. In SOA, the basic building block is not a component but a service.Services are loosely coupled and can be modeled as connected to a bus-like communication backbone, as describedin ESBI20]. Connections among the services arService 1Service 2Service 3controlled by a control center, which is also attachedto the communication backbone, as ilustrated inCommunication backboneControl centerFig.2.The control center is a composition manager thatService 4Service 5Service Nspecifies and controls the application compositionconfiguration via a workflow specification, whichFig.2 A generic SOA application architecturedefines how the services shall be connected togetherto deliver the desired results and how the messages are transferred among the services. With this kind ofarchitectures, a user can compose applications with different architectures or even different architecture styles, suchas a chain, a ring, a star, a layered structure, etc. This kind of architectures is in fact virtual. The connectionrestrictions can be enforced by policy and thus can be changed dynamically.2.2 Lifecycle managementAnother distinguishing characteristic of the SOA-based application architecture is that the lifecyclemanagement can be embedded in the operation infrastructure to facilitate dynamic software composition. In thisway, the SOA application development infrastructure and operation infrastructure can be merged into a single andunified SOA infrastructure. The development infrastructure may include: Modeling, function and policyspecification, analysis, design, code generation, and verification and validation such as model checking and testing.The operation infrastructure may include: Code deployment,Ercement, monitoring,中国煤化工communication, and system reconfiguration.Both IBM and Microsoft take this approach in their SOA:FYHC N M H Gation Architectuel.,development activities (modeling and assembly) and operation activities (deployment and management) areintegrated into a single process as ilustrated in Fig.3.Wei-Tek Tsai, et al: PESOI: Process Embedded Service -Oriented Architecture1473The architecture consists of four phases: modeling,assembling, deployment, andmanagement. Furthermore,runtime goverance activities are performed to provideModeling lguidance and oversight for the target SOA application. Theactivities in the four phases are performed iteratively:ManagementAssembling●Modeling: This phase models the user requirementsin a system model with a set of services;I Deployment(Goverpance●Assembling: This phase composes applications usinggahdpocessesservices that have been created or discovered atruntime according to the model specified in theFig.3 IBM SOA foundation architectureprevious phase;Deployment: In this phase, the runtime environment is configured to meet the application'srequirements, and the application is loaded into that environment for execution;Management: After the application is deployed, the services used in the application are monitored.Information is collcted to prevent, diagnose, isolate, and/or fix any problem that might occur duringexecution. These activities in management phase will provide the designer with better knowledge tomanage the application.The entire process will be controlled and orchestrated by the govermance policies. IBM SOA foundationarchitecture is based on such a model-driven application development process. This looping back process along withthe govemance and other processes can be delivered together with the target SOA application to the user. Whenthere is a need of changing the application architecture, the user can re-specify the system model, and theapplication can be re-assembled and re-deployed.2.3 IBM WebSphere integration reference architectureIBM WebSphere Integration Reference Architecturel221] is a SOA application model, which provides a set ofservices to enable business integration in a large diverse enterprise environment. Figure 4 shows the key integrationfunctions needed to provide comprehensive and enterprise -level solutions. The core of the WebSphere IntegrationReference Architecture is the connectivity services, which provides the infrastructure to support and to instantiatethe Enterprise Service Bus (ESB)201.Business innovation and optimizationservicesInteractionProcessInformationConnectivity services号吕PartnerBusinessApplicationappliation& informationassctsInfrastructure services中国煤化工:IHCNMH GFig.4 IBM WebSphere integration reference architecture2.4 Microsoft service- oriented application development frameworkMicrosoft also takes this approach in Visual Studio .Net 2005 (Whitehorse)f), which has the capabilities for1474Joumal of Software 软件学报Vol.17, No.6, June 2006modeling, architecture, code generation, code deployment, and code execution. In .Net 2005, an SOA applicationdesigner can select services from a service pool and define the architecture to specify how services cancommunicate with each other. After completing the architecture block diagram, the designer can execute it to see ifthe application can work as desired without knowing the details of the services used. The application can be easilychanged by changing the architecture model. Figure 5 ilustrates the architecture block diagram of an SOA-basedapplication developed in .Net 2005.P Bookstorc一Mcro4ot Vsua StudboFle Edtvew Propeat Debung Dugan Dxa Tools let wndw Comeunty HQ日100% .门.990，对Bokokoredaord 9otPoi Undpcints年Porter用Weberxetrnpor] webCorerEndpoirtgetOdriroaddToCartsxeChurgeDarnk] GenerEndpent 8a Applicetions》ASPINTwetecePotrtrJWrdonhopleationplarecroeASPMETWeoderncenChentprocessOrderpublisher》ASPNETetAcpok成EntensteteveeGenerailorderBookparcel牛PounterarsucomstulL Correction鱼ExtondwetfernceH ConnertFig.5 Microsoft whitehorse SOA designer3 PESOI: Process-Embedded Service-Oriented InfrastructurePESOI (process-embedded service-oriented infrastructure) is a framework developed at Arizona StateUniversity, which integrates the development infrastructure into the operation infrastructure, so that the applicationcan be re-developed during its operation. In addition to the capacities that WebSphere and .Net 2005 have, PESOIalso includes explicit Verification and Validation (V&V) capacities, a reconfiguration process, and a model drivenapproach. This section presents the overallSOAdesign of PESOI, lifecycle, and the dynamicapplicationarchitecture of the applications developed onModel of thePESOI.aplicationFigure 6 shows the layers of a related SOADevelopmentapplication. First, the application is decomposedinfrastructureinto the model consisting of patterns ofsub- models. Each of the sub-models is developedOperationusing a tool in the development infrastructure,它心Lfhirn._ mans the sub model into anEmbedding几中国煤化工tion nfrstrscure..InfrastructureYHC N M H Grecycle (developmentembeddedand operation phases) of applications developedon PESOI, which consists of the followingFig.6 Infrastructure _Embedded SOA applicationphases: Modeling and specification, VerificationWei-Tek Tsai, et al: PESOI: Process Embedded Service -Oriented Architecture1475of specification, Code generation for validation, Validation (simulation and testing), Assembling and deployment,Operation and monitoring, Evaluation at runtime, and Reconfiguration.SimulationModelingValidationRequirementVerificationspecificationgenerationOperationAssemblingReconfigurationEvaluationmonitoringdeploymentFig.7 PESOI reference architectureThese phases form a feedback loop, where the last phase reconfiguration is connected to the first phasemodeling and specification. Each of the phases in PESOI is elaborated as follows:Modeling & Specification phase: This phase consists of two sub-phases. The modeling sub-phase is atarchitecture or component level, similar to Microsoft architecture model shown in Figure 6 and IBMSCA/SDO model. The specification sub-phase uses PSML-S process specification and modelinglanguage, which is similar to BPEL4WS, to define the flow and conditions between the components;Verification phase: It contains activities such as Completeness & Consistency (C&C) analysis, modelchecking, test case generation based on the functional and policy specification;Assembling phase: It consists of automated code generation from the process specification and bindingof external services to obtain the executable code;Validation phase: It runs the executable in a simulation environment and validates the code via testing;Deployment phase: This phase deploys executable code into the execution environment. It involvesbinding the addresses of real devices into the code. Monitors and data collectors will be embedded intothe code;Execution and monitoring phase: The executable code is executed in the real environment. The monitorsand data collctors will collect and record data for later analysis;Evaluation phase: It analyzes the data, evaluates reliability and performance, and provides input for thereconfiguration phase;Reconfiguration phase: It takes reliability evaluation results as input and decides if a rebinding isnecessary to replace a less reliable service through rebinding a reliable services. A service farm containsthe backup spares need for rebinding. The services in the farm are tested and ranked in an independentprocess such as group testing221. If the application requirement is revised by the user, a re-compositionor re- architecture needs to be performed. In this case, the composition or architecture of the applicationwill be modified. The modified application needs to go through the entire development process, and thus,the development infrastructure needs to be embedded into the application to enable the reconfiguration.The rest of the paper will talk about issues related to PESOI. Specifically, Section 4 will discuss the modelingissues in PESOI, Section 5 will discuss the dynamic reconfiguration issues, and Section 6 will talk about theverification and validation issues in PESOI.中国煤化工4 Single Model Multiple Analyses (SMMA)MHCNMHGNumerous modeling projects have been proposed to model software, ranging from informal descriptions tosemi-formal models, such as a state model, to formal models, such as process algebra CCS, CSP and ACl-14,16-18.For SOA applications, informal methods are not applicable because one can not produce code from informal1476Jourmal of Sofware软件学报Vol.17, No.6, June 2006descriptions automatically. However, strict formal methods will need more time to mature before they can beapplied to SOA applications. Most current approaches use lightweight formal techniques that can produce softwaredesign and code automatically, and can be easily used by practitioners due to the visualization capabilities of thesemodels.Currently, the UML from OMG htp://www.omg.org/technology/documents/formal/uml.htm] is the de factorindustry standards for specifying and analysis of software models, particularly for object- oriented programs. Thequestion is whether UML is suitable for SOA. Particularly, is UML suitable for SOA applications with on-demanddynamic composition?UML 2.0 has 13 different types of diagrams, divided into three categories:●Structure models: Class Diagram, Object Diagram, Component Diagram, Composite Structure Diagram,Package Diagram, and Deployment Diagram;Behavior models: Use Case Diagram, Activity Diagram, and State Machine Diagram;Interaction models: Sequence Diagram, Communication Diagram, Timing Diagram, and InteractionOverview Diagram.The UML has more than 20 models. While each individual model within UML is useful for modeling andanalyses for certain aspects of the system engineering, the fact that it has so many models is a concern. One problemis that it is not possible to convert one model (for example Activity Diagram) to another model (such as StateMachine Diagram) automatically. Thus, a change in a model may need the involved engineers to manually updatethe rest of models to keep these models consistent with each other. This does not bode well with on-demanddynamic composition in SOA where code needs to be generated from the model, and possibly both the model andthe code need to be analyzed, verified, and validated dynamically at runtime using existing services.We call the approach taken by UML the MMMA (multiple models multiple analyses) approach because it hasmultiple models and each model has its own analysis techniques. In a typical MMMA approach, models areinterconnected with each other, but not fully integrated to each other, i.e., it is not possible to generate the rest ofmodels from one model. Thus, MMMA is error-prone during system updating, and thus it is not suitable for theSOA environment, where models can be dynamically changed at runtime as applications are re-composed orreconfigured.On the other hand, if the development is based on a single model, all other models and analyses areautomatically derived from this model, the approach is called SMMA (single model multiple analyses) approach.One of the characteristics of SMMA is that a designer can focus his/her attention on the single model only. If achange is made, he/she can just update the primary model, and the rest of models and analyses can be automaticallygenerated. Specifically, once the primary model is updated, code can be automatically re-generated, completenessand consistency analysis can be re-checked, simulation code can be automatically generated and simulationperformed, state model can be automatically updated based on the new model and so on. In this way, significantsystem engineering tasks can be automatically performed. SSMA approach does not conflict with the principle of“separation of concerns". Instead, it makes sure that components created by other parties can interoperateseamlessly. A demo of the SMMA approach in a network of service-nriented emhedded rnhnts can be viewed at the中国煤化工website at htp://asusr.eas. asu.edu/EmbeddedExplorer/.PESOI is the only infrastructure that has taken the SMMAYHC N M H Gwhere PSML (processspecifcation and modeling language) is the single model and all the analyses are directly or indirectly based on thismodel. PSMLS (PSML for Services) and PSML-P (PSML for Policies) are derived from PSML, which are used tomodel the functionality and policies in the application, respectivelyl23. Table 1 lists the operations and analyses that.Wei- Tek Tsai, et al: PESOI: Process Embedded Service-Oriented Architecture1477can be automatically performed on a PSML-S and PSML-P models.AssemblingRealOperationdeploymentMonitoringEvaluationSimulationSimulation +Validation ,ReconfgurationI code generationtestingcodeFunctionmodelPSMLPMSL-S/verificationPolicy手PolicyenforcementServicemnittesting/farm。Policydatabaseextraction↑↑↑Service inputFig.8 PESOI's approach of single model multiple analysesTable 1 Operations and analyses on PSML-S and PSML-P modelsAnalysesModel and toolCommentsAutomated codeCode is generated by following the process flow ofC# code is generated fom PSML-S.generationthe PSMLS.Both PSML-S and PSMLP models, asAs process modeling in PSML and generated codeModel checkingwell as the generated code, can be modelare contol-flow based, they can be checked by achecked by BLAST [25] and BLADE1261.model checkers based on control flow models.Completeness andBoth PSML-S and PSML-P models, asThe C&C checking is based on an abstracted model,consistency (C&C)well as the generated code, can beand the abstracted model can be obtained either fromcheckingchecked for C&C at runtimethe PSML-S and PSML-P, or generated code.Policy specification,checked only at runtime. Policy isThe issue is to ensure that constraints specified byanalysis, and enforcement interesting because it can be specifiedpolicies can be enforced at runtime.using the same language PSML-PI27!.Various testing techniques can be used includingDynamic test caseTest input can be generated by analyzingpartition testing, random testing, Swiss cheesethe PSML-S and PSML-P models.testing techniques301DistributedThe dificult part is the simulation infrastructure toThe code generated can be executed as.service-orientedcoordinate the execution run of concurrentsimulationthe simulation of the model specified241.processes.Reliability modeling andThe reliability of application as well asThe architecture-based reliability models can bethat of participating services can beused and they can be validated using the DREPassessmentestimated using the data ollected.model29]5 PESOI Support for Dynamic ReconfigurationsGenerally, three levels of reconfigurations are available in SOA, once an application is developed anddeployed, as ilustrated in Fig.9:Rebinding: A service in the application is replaced by another service that has the same functionality.The change required is to change the binding address related to the service. Rebinding is mainly used forfault- tolerant computing (replacing a failed service or arMH中国煤化工upgrade;Re-composition: In addition to rebinding, a new servicC N M H Gting service can beremoved from the application. However, the architecture style remains unchanged. Re-composition ismainly used for functionality and performance enhancement;●Re-Architecture: In addition to re- composition, the architecture style can be changed, for example,万方数掘ing the bus type of connection to the layered type of architecture. The former allows any two1478Journal of Sofware软件学报Vol.17, No.6, June 2006components to communicate directly, while the latter only allows the communication betweencomponents in the two adjacent layers. Re-architecture allows the human designer to generate a newapplication at runtime time.ServicesfarmModifiedArchitecture modelarchitecture modelBinding andrebindingBus type architecture出Process model ofcomposite serviceprocess modelFig.9 llustration of rebinding, re-composition, re-architecture, and service farmSOA application development starts with architecture model, in which the application is modeled by a set ofcomponents with certain type conectivity, e.g., bus, peer to peer, and layered type, which are called architecturepatterns. The architecture model will be elaborated manually, but with the help of architectural patterm, into theprocess model, in which the flows between components and selections among flows are defined. Each component inthe process model is linked to a service that can perform the required functions. To tolerate service faults, multipleservices with the same functionality can be bound to a component through a Dynamic Reconfiguration Service(DRS) agent. Rebinding means to substitute the address of a new service for that of the service to be replaced.Re-composition means changing the process model or the flow between the components, without changing thearchitecture. Re architecture means changing the type of connectivity among the components. To enable seamlessruntime reconfigurations, checking points are used periodically to save the status of the target system so that, whena reconfiguration is necessary, the reconfigured system can continue its execution from the last checking point.5.1 PESOI supports for rebindingRebinding is the basic and most frequently used reconfiguration supports provided by PESOI. The supportsprovided to rebinding, which also apply to re-composition and re-architecture, include:Service farm and service cache: All the evaluated services that can be used to replace one of the serviceslinked to the application will be placed in a service farm as backup services. The backup services can be evaluatedaccording to rliabiliti, performance, user feedback, and profiles The services in the farm with the highest rankingwill be placed in a service cache, which is used like the cache i中国煤化工ure 10 shows how theservice farm and service cache are established and associatedMYHCNMHGPESOIlooksuptheservice broker to find all services that can meet the requirement of each service in the application compostion. Theservice testing manager will then test each service. If the number of services found is large, group testing can beapliedl22. The qualified services are put into the service farm as the backup spares and the best qualified servicesWei-Tek Tsai, et al: PESOI: Process Embedded Service Oriented Architecture1479will be placed in the service cache.Application compositionService brokerServicei RegisteringdirectorySearchingService testingmanagerTestingService cacheServices fromdifferentservice providersFig.10 Establishment of the service farmDynamic reconfiguration service (DRS)28): DRS is a framework with distributed agents which will monitor,assess, and reconfigure the SOA application at runtime. The framework defines an agent-based, collaborative andself-reconfigurable architecture for service-oriented distributed computing, supported by a set of DRS services andagents, including registration service, monitoring service, and dynamic reconfiguration agents (DRS agent). DRSagents are embedded into the application, which coordinate with each other to make the applicationself-reconfigurable. In this example, two applications use the same encryption service. If one application wants toupgrade its encryption method, it cannot simply rebinds to a different service. It has to coordinate with itscommunication peers, so that they can upgrade at the same time and thus can decrypt each other's data.5.2 PESOI supports for re-compositionRe-Composition is a much harder problem than rebinding because not only services may be replaced, the SOAapplication is actually changed. In additional to the supports listed in Section 5.1, PESOI supports the SMMA forthe re-composition, i.e., the SOA application specification can be updated by changing the model only. Once themodel is changed, it will be automatically re-verified. Then, the code can be automatically re-generated, and thegenerated code can be re-validated and re-evaluated. During the code re-generation, new services may be searched,discovered, and bound into the new application.5.3 PESOI supports for re-architectureIn additional to the supports listed in Sections 5.1 and 5.2, PESOI uses architecture patterns to supportre-architecture. The patterns are restrictions defined in policies. The modification to the. nalicies leads to thearchitecture change and architecture pattems help the fast re-generat中国煤化工n in PSML-S andPSML-P.YHCNMHGBecause of the re-architecture, applications developed using PESOI no long have fixed architecture, such asbus, layered, or point-to-point. The architecture can be changed after the deployment of the application.1480Joumal of Software 软件学报Vol.17, No.6, June 20065.4 Service access and service cacheCurrent SOA application supports two kinds service accesses: remote invocation and code importation withlocal access. The former technique binds the URL of a service into the application and each access to the service isaremote invocation. The latter technique, called service cache, imports the executables of the services into the samecomputer that runs the application or different nodes in a local distributed system or network.Imported services eliminate the internet access and are much faster and much more reliable. However, it useslocal resources, which are often limited, and rebinding will take much longer because the entire service code needsto be loaded and deployed into a local machine. Assume that an application needs (composed of) N extermal servicesand has M slots (processors and memory) to import (host) external services. PESOI implements the service farm andservice cache as follows.First, the service test manager will find services that meet the requirements of the application and put them allinto the service farm. The service farm only needs to store the service IDs and URLs of the services. The number ofservices that can be listed in the service farm is practically unlimited. However, the service cache needs to store theentire executable code of the services and thus is limited and the selection of services needs to be optimized. Table 2lists the relationship between N and M and the PESOI placement and replacement policies in each case.Table 2 Relationship between N and M and the PESOI placement and replacement policiesNo. of servicesNo. of backupN-MReplacement and replacement policiesusing localusing remoteservices using localin the service cacheccessescessesaccesses per serviceM=0All services use remote invocationM out of N services use local accesses.N2MM0Most frequently used services will beimportedAll services use local access. The mostNS11- →S12-→S13-→S14→nullService S2-→>S21->S22- +>S23- →>nullService S3-→>S33- →>S32- →S31→nullo Service S4-→S42- →S41→nullPESOI uses different length of backup services, instead of equal length, to reflect the fact that some servicesmay have less reliable link or services and need more frequent rebinding than the others.6 A Case Study- -Pet ShopAn application called Pet Shop is built for ilustrating the development and operation phases in PESOI. Anintegrated modeling environment for constructing the PSML-S model is provided, which allows the applicationbuilders to specify the detailed system model information using PSML-S language, the application compositionlogic, and the application configuration policies based on the users requirements. Figure 12 ilustrates the PESOIeditor's window, which support convenient writing of the PSML-S and PSML-P specifications. For the pet shopapplication, the PSML-S specification consists of 12 Actor elements, 16 Action elements, 3 Condition elements, 2Data elements, 2 Event elements, 4 processes, and one default application composition configuration. A part of thespecification script is shown in the editor window in Fig.12. A PSML-S model can consist of the following modelelements: Actors, Actions, Attributes, Conditions, Data, Events and process that defines the flows among the modelelements!231.P SCNRTPol Tanttesing口石网at Y fodh Beport BnetrasI GOLDILEx4 Entesint| RegeterxPoprbeReger (ScongcelTlDotpe PReeqlaHeardicoewusingPerthreTenglste ，OuPasFmsratment. Fell1erTvraeFig.12 PSML-S edi中国煤化工Following the SMMA, we have performed the C&C analyses,:MYHC N M H Geration, simulationcode generation, simulation, and testing.Among these operations, the simulation validates the execution logic of the PSML-S model to check if italways generates an acceptable outcome for each test case. Two user's interfaces are implemented to observe thesimula而衣数据. A graphical simulation interface highlights the current point of execution in the flowchart of the1482Jourmal of Sofware软件学报Vol.17, No.6, June 2006PSML-S specification. Figure 13 shows a snapshot of the execution. A text simulation interface records every tracethat has been tested and the output corresponding to each input. A snapshot of the interface is given in Fig.14.E一中O站→宁PFig.13 Graphical simulation trace animation只Computer Management0O& Crot PopetesFileActonWewWendownebo_6xErer1/520 Souce Smdston_Loo9 Comoute Mangrentoc TrypeDateSource... CatsgerTee 53003附[ Cxeg00 Noe15/20065:0:07附1 S m Jton LogTot Htematon EwerID: 0FioreCorouter LOWS:30:05附loreDescreton.PHontloneNonefor nore domolon.c Hedep and Sppot CertersI NonePlone中RerordbieStrore器Dedetfogrmenter: 白Serve ond Aplatosos Qine16/20065:30:01附Smulaton_Log1/6/20065:2:9附Smulaton_LogNonCOK_CmeFig.14 Text simulation traceUsing the graphical interface, users can visualize the simulation execution step by step from the control flowchart of the PSML-S model. Thus users can closely observe the behavior of the PSML-S model. This feature isextremely useful when users want to perform debugging on the PSML-S model.The text simulation interface records the detailed system ev中国煤化iulations with diferetconfigurations can be performed. The simulation results storedyzed later for differentTYHCNMHGpurposes such as detecting reliability evaluation.7 Conclusion芳程e presentsthe PESOI infrastructure for SOA application development, which has the followingWei-Tek Tsai, et al: PESOI: Process Embedded Service-Oriented Architecture1483unique features:●PESOI takes an SMMA approach, that is, all the analyses and evaluations are based on the PSML-Smodel. When the application needs to be modified, only the PSML-S model needs to be modified and therest of the system is automatically modified accordingly;PESOI supports three levels of reconfigurations, rebinding to external services, re-composition of theapplication logic, and re-architecture of the application. Different level of reconfiguration requiresdifferent level of V &V support;Dynamic reconfiguration needs dynamic V&V to ensure the dependability of the dynamically createdapplications. PESOI enforces V&V in every phase of the development and operation.PESOI is proposed based on the experience in several experimental and industrial projects that we haveimplemented. Different mechanisms have been implemented in different projects but we have not implemented allthe V&V and evaluation mechanisms in a single project. We are currently implementing a prototype that put allthese components together in order to obtain the complete and coherent lifecycle data.References:[1] Arsanjani A. Service-Oriented modeling and architecture: How to identify, specify, and realize services for your SOA. Whitepaperfrom IBM, Nov 2004. ht///ww.28.ibim.com/developerworks/webervices/ibrary//- soa-design1/2] High RJr, Kinder s, Graharm s. IBM SOA foundation: An architectural introduction and overvicw, Version 1.0. 2005.3] IBM Developers Works. New to SOA and Web services. ht://ww- 128.ibm.com/developerworks/webservices/newto/[4] Simmons S. Introducing the WebSphere integration reference architecture: A service-based foundation for enterprise-level businessintegration. IBM WebSphere Developer Technical Jourmal, 2005. htp://ww-128.jbm.com/developerworks/websphere/techjournal/0508_ simmons/0508_ simmons.html[5] Randell BA, Lhotka R. Bridge the gap between development. and operations with whitehorse. MSDN magazine, 2005.htp://msdn.microsoft.comsnmag/issues/04/07/whitehorse/defaultaspx6] SAP NetWeaver product introduction. htp:// www.sap .com/solutions/netweaver/index.cpx[7] Brown G, Carpenter R. Successful application of service -oriented architecture across the enterprise and beyond. Int'l TechnologyJourmal, 2004. htp://www .intel.comn/technology/itj/2004/volume08issue04/art09_ successful/ p07. references.htm8] Krafig D, Banke K, Slama D. Enterprise SOA: Service-oriented Architecture Best Practices. New York: Prentice Hall, PTR, 2005.[9] Erl T. Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. New York: Prentice Hall, PTR, 2004.[10] Mei H, Huang G, Tsai WT. Towards self-healing systems via dependable architeture and rflctive middleware. In: Proc. of the10th IEEE Int'l Workshop on Object-Oriented Real-Time Dependable Systems. Sedona, 2005. 337-344.[11] Allen R, Douence R, Garlan D. Specifying and analyzing dynamic software architectures. In: Proc. of the '98 Conf. onFundamental Approaches to Software Engineeing (FASE'98). Lisbon, 1998.[12] Dobrica L, Niemela E. A survey on software architecture analysis methods. IEEE Trans. on Software Engineering Arechive, 2002,28():638-653.Bradbury JS, Cordy JR, Dingel J, Wermelinger M. A survey of self-management in dynamic achitecture specifications. In: Proc. ofthe Int'l Workshop on Self- Management Systems. 2004.{14] Garlan D. Allen R. Formalizing architectural connection. In: Proc. of the 16th Int'l Conf. on Software Engineering. 1994. 71-80.[15] Garlan D, Monroe RT, Wile D. Acme: Archtectural description of component-based systems. In: Leavens GT, Sitaraman M, eds.Foundations of Component Based Systems. Cambridge University Press, 2中国煤化工[16] Inverardi P, Wolf A. Formal specification and analysis of software archite|YHC N M H G machine model. IEEETrans. on Software Engineering, Special Issue on Software Architecture, 1995.21(4):373-386.[17] Shaw M, Garlan D. Formulations and formalisms in software architecture. Computer Science Today: Recent Trends andDevelopments, LNCS 1000, Springer-Verlag, 1995.1484Journal of Software软件学报Vol.17, No.6, June 2006[18] Shaw M, DeLine R, Klein DV, Ross TL, Young DM, Zelesnik G. Abstractions for software architecture and tools to support them.IEEE Trans. on Software Engineering, 1995. 314- 335.[19] Dowling J, Caill V. Dynamic software evolution and the k-component model. In: Proc. of the Workshop on Software Evolution,OOPSLA. 2001.[20] Chappell D. Enterprise Service Bus. New York: 0' Reilly Media, 2004.[21] IBM eServer and Automatic Computing. htp://ww03.ibm.com/servers/autonomic/[2] Tsai WT, Bai X, Chen Y, Zhou x. Web service group testing with windowing mechanisms. IEEE Int'l Workshop onService-Oriented System Engineering (SOSE). Beijing, 2005. 213-218.[23] Tsai WT, Paul RA, Xiao B, Cao z, Chen Y. PSML-S: A process specification and modeling language for service orientedcomputing. In: Proc. of the 9th IASTED Int'l Conf. on Software Engincering and Applications (SEA). Phoenix, 2005. 160-167.[24] Tsai WT, Fan C, Chen Y, Paul RA. DDSOS, distributed service -oriented simulation. In: Proc. of the 39th Annual Simulation Symp.(ANSS). Huntsville, 2006. 160 -167.Henzinger TA, Jhala R, Majumdar R, Sutre G. Lazy abstraction. In: Proc. of the 29th Annual Symp. on Principles of ProgrammingLanguages. 2002. 58-70.[26] Huang H, Tsai WT, Paul RA, Chen Y, Automated model checking and testing for composite Web services. In: Proc. of the 8thIEEE Int'l Symp. on Obiject Oriented Real-Time Distributed Compuing (ISORC). Seattle, 2005. 300-307.[27] Tsai WT, Chen Y, Paul RA. Dynamic simulation verification and validation by policy enforcement. In: Proc. of the 38th AnnualSimulation Symp.2005. 2005. 91-98.[28] Tsai WT, Song W, Paul RA, Cao Z, Huang H. Services-Oriented dynamic reconfiguration framework for dependable distributedcomputing. In: Proc. of the IEEE COMPSAC 2004. 2004. 554-559.[29] Tsai WT. Service-Oricented system engineering: A new paradigm. In: Proc. of the IEEE Int'l Workshop on Service -Oriented SystemEngineering (SOSE). Beijing, 2005. 3-8.[30] Tsai WT, Wei X, Chen Y, Xiao B, Paul RA, Huang H. Developing and assuring trustworthy Wcb services. In: Proc. of the 7th Int'lSymp. on Autonomous Decentralized Systems. Chengdu, 2005. 43- -50.TSAI Wei-Tek is a professor at ArizonaFAN Chun received his Ph.D. degree atState University. His research areas areArizona State University in 2006 and isservice- oriented computing. embeddednow with Motorola, USA. His researchsystems, and system verification andareas are service-oriented simulation andvalidation.software development life cycle.CHEN Yinong is a senior researchscientist at Arizona State University. Hiscomputing, embedded systems anddependable computing.中国煤化工MYHCNMHG