SOA for services or UML for objects: Reconciliation of the battle of giants with Object-Process Methodology

Transcription

1 SOA for services or UML for objects: Reconciliation of the battle of giants with Object-Process Methodology Dov Dori Technion, Israel Institute of Technology, Haifa, Israel Massachusetts Institute of Technology, Cambridge, MA, USA ABSTRACT Two software system lifecycle development paradigms have been competing on the minds and hearts of software developers and executives: The traditional Object-Oriented approach and the emerging Service-Oriented Architecture (SOA) or SO Development of Application (SODA). While OO puts objects and their encapsulated behavior at the center stage, emphasizing primarily rigid structure, SODA hails services as the prime players to cater primarily to behavior. We discuss the new SOA technologies from the extended enterprise and the service network all the way to the atomic service level and show that Object- Process Methodology (OPM), which strikes a unique balance between structure and behavior, is most suitable as the underlying SOA-based lifecycle engineering approach. Using OPCAT, the OPMsupporting systems modeling software environment, we construct the top level diagram of a model of SODA and simulate it using animation in order to show how OPM conveniently serves as an ideal overarching comprehensive methodology that encompasses the entire spectrum of service-oriented enterprise systems development. 1. Introduction: From Objects to Services The Object-Oriented (OO) paradigm has dominated the software world since the early 1980's. It suppressed the previously accepted functional programming paradigm, which put functions as the central players in computer programs. The domination of the OO paradigm has promoted the proliferation of a plethora of objectoriented analysis and design methods. The amount of methods that were basically similar in principle but different in their types of diagrams and symbols, culminated in the proposal and eventual adoption by the Object Management Group (OMG) of the Unified Modeling Language (UML) as the lingua franca of OO-based software development. Until recently, it looked like OO, along with its ensuing technologies, such as Design Patterns, Component-Based Development, and Aspect-Oriented Programming, is the ultimate solution to many problems that were at the basis of the "software crisis" of the late 1980's, and that consequently the OO domination is going to last for a very long time. However, the recent move of the IT world to cater to the business needs of enterprises of all sorts and magnitudes has created a rather surprising twist a modern return to the good old functional approach, which puts back functions (now called services) rather than objects as the top-level entities in the architecture of complex, enterprise-wide systems. It is thus becoming more and more evident that the most popular new three-letter acronym of the decade is going to be SOA Service-Oriented Architecture [1], or its four-letter companion SODA Service-Oriented Development of Applications [2]. Dressed with a new architectural garment and backed with state-of-the-art Internet-based cross-enterprise networking capabilities, this new trend is admittedly way more sophisticated and technologically advanced than its pre-oo old functional (also called structured) programming counterpart. Software has slowly been undergoing a series of decoupling processes. Client/Server architecture has separated the database from the "fat client". In the emerging "thin-client", the user interface was decoupled from the business logic. Now SOA is decoupling the integration logic from the business logic. Newly proposed process-driven architectures decouple the process logic from the business logic. The traditional Object-Oriented (OO) approach and the emerging Service-Oriented Architecture (SOA) are two software system lifecycle development approaches that are founded on complementary paradigms structure, and behavior, using objects and services respectively as their prime building blocks. OO and SOA have been competing on the minds and hearts of software developers and executives. While OO puts objects and

2 their encapsulated behavior at the center stage, emphasizing primarily rigid structure, SOA hails services as the prime players to cater primarily to behavior. We discuss the new SOA technologies from the extended enterprise and the service network all the way to the atomic service level and show that Object- Process Methodology (OPM), which strikes a unique balance between structure and behavior, is most suitable as the underlying SOA-based lifecycle engineering approach. Using OPCAT, the OPMsupporting systems modeling software environment, we construct the top level diagram of a model of SOAbased lifecycle development and simulate it using animation in order to show how OPM conveniently serves as an ideal overarching comprehensive methodology that encompasses the entire spectrum of service-oriented enterprise systems development. The recent move of the IT world to cater to the business needs of enterprises of all sorts and magnitudes has triggered SOA Service-Oriented Architecture [1], or its four-letter companion SODA Service-Oriented Development of Applications [2] as a modern return to the good old functional ("structured") approach, which puts back functions (now called services) as the top-level entities in the architecture of complex, enterprise-wide systems. SOA is an umbrella for (mostly XML-based) modeling languages like BPEL4WS [3] and BPEL4People [4]. In a processdriven architecture, the application is viewed from a process perspective [2]. A top-level process is broken down into level-1 subprocesses, called activities and each activity is further broken down into level-2 subprocesses, called tasks. The process information is then recorded as a "digital process" that can be executed within an "orchestration engine", also dubbed "process execution engine" or "process virtual machine", which we describe later. 2. Services as Software Processes To better understand what Service-Oriented Architecture (SOA) really is, we need to first clarify the term service. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. In other words, a service is a process which, by transforming objects, generates value for its consumer. Examples of services in the real world have been abundant for thousands of years. Selling goods, hairdressing, mail delivering, food cooking and house cleaning are examples of services. In each such service, some object is transformed to bring value to its consumer. Selling goods changes the ownership of the goods from the seller to the buyer, who, in turn, uses them for her benefit. Hairdressing changes the look of the customer's hair from untidy to tidy. Mail delivering changes the location of each sent mail item from the sender to the recipient, usually benefiting both sides. Food cooking changes the raw food materials from inedible to edible, so the consumer can eat them and satisfy his hunger. House cleaning changes the house from dirty to clean, benefiting the tenants living in it. In each service, as all these examples consistently show, there is at least one object that undergoes a state change, and it is this change exactly that creates value for the consumer or the customer. This value motivates service providers to develop and offer services that consumers are willing to pay for. Provides develop specializations of their skills so they benefit from the economy of scale. The mail deliverer, for example, delivers hundreds of mail items to the same street in a fraction of the total time it would take each sender to personally deliver his mail piece to the recipient. The pattern we have seen with services shows that invariantly, at least one object is transformed in order for the service to be of value. Hence we cannot talk about services in a vacuum there must always be a transformee (a transformed object) which is involved. Moreover, we cannot talk about a service without reference to its provider and consumer, which are objects too. 3. Web Services The situation in the software world is not principally different than that in the real world: services transform (informatical) objects by consuming or crating or affecting (changing the state of) these objects. And like in the real world, there are providers and consumers for each service. The service provider and the service consumer are "software agents," i.e., they are intelligent programs that act on behalf of their owners, who may be individual humans or actual organizations. Web services are the atomic units of service which are available on the Internet. Web services are founded on three XML-based components: Web Services Description Language (WSDL), Simple Objects Access Protocol (SOAP), and Universal Description, Discovery, and Integration (UDDI). SOAP defines an XML messaging protocol for basic service interoperability. WSDL introduces a common grammar for describing services. UDDI provides the infrastructure required to publish and discover services in a systematic way. Together, these specifications allow applications to find each other and interact following a loosely coupled, platform-independent model.

3 4. SOA and SODA Defined and Analyzed Following the definition in [1], Service-Oriented Architecture is a collection of distributed, selfcontained Web services that communicate with each other independently of the context or state of other services. Put differently, SOA is an approach to architecting systems that is based on retrievable Web services which can be combined via loose coupling among interacting software agents. SOA constitutes a major departure from the OO approach, as it considers services as stand-alone entities, not encapsulated within a certain object. For example, if consumer electronic would be designed following OO philosophy, every CD would come bundled with its own player software. Instead, in the SA spirit, there is loose coupling between a CD and a CD player via a standard interface, so a CD can be played on any player. The loose coupling among interacting software agents is achieved by (1) few simple, universally available and ubiquitous interfaces with the participating software agents, and (2) schemaconstrained extensible messages delivered through the interfaces. The extensibility of the schema allows new versions of services to be introduced while keeping existing services. Invariantly in any service, at least one object is transformed in order for the service to be of value, and there is at least on object which is the service provider and yet another object the service consumer. Hence we cannot talk about software services in a vacuum there must always be a transformee (a transformed object) which is involved. In spite of this simple, straightforward observation, the current state of affairs is that neither OO nor SOA alone can possibly serve as a solid foundation for a comprehensive conceptual paradigm for modeling interesting complex systems such as interacting enterprises, since each suffers from lack of appropriate representation of either structure or behavior. The inescapable conclusion is that a methodology must be put in place which will consider both objects and processes as equally important firstclass building blocks. This methodology must formally and intuitively unify, merge, and reconcile the Objectand Service-Oriented approaches. Luckily, such paradigm is already in existence for over a decade. It is called Object-Process Methodology (OPM). 5. Business Process Execution Language The resulting enterprise model serves as a basis for identification of services, which are mapped using Business Process Execution Language (BPEL) for Web services [3]. BPEL, also sometimes identified as WS-BPEL, BPELWS or BPEL4WS, is an orchestration language that defines a notation for specifying business process behavior based on Web Services. An XML-based language, BPEL is designed to enable task-sharing for a distributed- or a gridcomputing environment, both within and across organizations, using a combination of Web services. Written by developers from such software houses as BEA Systems, IBM, and Microsoft, BPEL combines and replaces earlier versions like IBM's WebServices Flow Language (WSFL) and Microsoft's XLANG specification. By providing a language for the formal specification of business processes and business interaction protocols, BPEL4WS extends the Web Services interaction model and enables it to support business transactions. BPEL4WS defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces. Using BPEL, one can formally describe a business process that will take place across the Web such that any cooperating entity can perform one or more steps in the process the same way. In a supply chain process, for example, a BPEL program might describe a business protocol that formalizes the information pieces that comprise a product order, and what exceptions may have to be handled. BPEL4WS allows companies to describe business processes that include multiple Web services and standardize message exchange internally and between partners. It is important to note that the BPEL specification does not specify how a given Web service should process a given order internally. The separation of the public aspects of business process behavior from internal or private aspects is due to (1) reluctance of businesses to reveal their internal decision making and data management to their business partners, and separating public from private process, so private aspects of the process implementation can be changed without affecting the public business protocol. These protocols are clearly described in a platform-independent manner and capture all behavioral aspects that have crossenterprise business significance. This enables each participant to understand and plan for conformance to the business protocol without the need for additional time consuming human agreements, which still hinder a more rapid progress in business-to-business automation. Human user interactions are currently not covered by WS-BPEL, which is primarily designed to support automated business processes based on Web services. In practice, however, many business process scenarios require user interaction. A work under way by IBM

4 and SAP, dubbed BPEL4People [4], describes scenarios where users are involved in business processes, and defines appropriate extensions to WS- BPEL to address these. 6. SOA-based Lifecycle Development Schematically the lifecycle of an enterprise venturing SOA comprises three main processes: Conceptual Modeling, Enterprise Service Modeling, and Web Services Embedding. The lifecycle of SOA-based development ideally starts with a comprehensive analysis which results in a conceptual model of the enterprise, in which services are to be embedded and operational. Hence, successful SOA implementation requires careful planning founded on a detailed yet holistic view of the contemplated architecture. Business Process Modeling, Analysis, and Management (BPM) is the orchestration of various business systems into identifiable and controllable system-of-systems that can potentially consolidate a myriad of related enterprise processes. There is a plethora of BPM tools that can be used at this stage. Conceptual Modeling yields the Enterprise Conceptual Model. This model constitutes the basis for the skeletal Enterprise BPEL4WS Model. Using the Web Services Repository, the skeletal Enterprise BPEL4WS Model is populated with concrete Web Services via the Web Services Embedding process, changing its state from "skeletal" to "web-services embedded". The Enterprise itself the focus of all these activities, is the object undergoing the lifecycle. The initial state of the Enterprise is "pre-modeled". Other states are "conceptually modeled", "BPEL4WSmodeled", and "web-serviced", the latter being the final state. As the Enterprise undergoes its SOA lifecycle, it changes its states. Each of the three major processes also affects the Enterprise by changing its state. Conceptual Modeling changes the Enterprise from "pre-modeled" to "conceptually modeled", Enterprise Service Modeling changes it from "conceptually modeled" to "BPEL4WS-modeled", and Web Services Embedding from "BPEL4WS-modeled" to "webserviced". As each one of the three major processes Conceptual Modeling, Enterprise Service Modeling, and Web Services Embedding is executed, one of the three parts comprising the Enterprise Model Set the Enterprise Conceptual Model, the Enterprise BPEL4WS Model, and the Web Services Repository are respectively created. Since the Enterprise keeps evolving, a Conceptual Model Enhancing process usually takes place continuously, using the current web-services embedded Enterprise BPEL4WS Model, and it keeps updating the Enterprise Conceptual model. While this SOA lifecycle model makes a lot of sense, in spite of the significant efforts by the leading software giants worldwide, current tools cover only segmented parts of the entire lifecycle of SOA-based development. For example, Business Process Analysis tools model organizational processes but do not directly carry on the resulting conceptual model to tackle the technological part, where BPEL is utilized. BPEL, in turn, is not seamlessly integrated into the three XML-based components of Web services Web Services Description Language (WSDL), Simple Objects Access Protocol (SOAP), and Universal Description, Discovery, and Integration (UDDI). 7. SOA vs. OO: The Battle of the Giants In most complex systems in general, and enterprises in particular, structure and behavior are highly intertwined and hard to separate. For example, in a manufacturing system, the manufacturing process cannot be contemplated in isolation from its inputs raw materials, model, machines, and operators, and its output the resulting product. The inputs and the output are objects, some of which are transformed by the manufacturing process, while others just enable it. In spite of this simple, straightforward observation, what we are witnessing is a conflict between two competing paradigms: OO and SOA. While OO emphasize structure using objects as the only top players in the modeling game, SOA conversely focuses on the system's behavior via modeling processes (services) while suppressing the role of objects as prime building blocks of the enterprise conceptual model. The current state of affairs is that each of these two competing approaches highlights one of the two major system aspects structure and behavior at the expense of suppressing the other. The bottom line is that neither OO nor SOA alone can possibly serve as a solid foundation for a comprehensive conceptual modeling method of any interesting complex system under study, as each suffers from lack of appropriate representation of either structure or behavior. All this points to one clear conclusion: There must be a methodology that formally and intuitively unifies, merges, and reconciles the Object- and Service- Oriented approaches. Luckily, such paradigm is already in existence for over a decade. It is called Object-Process Methodology (OPM).

5 8. Object-Process Methodology Modeling of complex systems should conveniently combine structure and behavior in a single model. Motivated by this observation, OPM [5], [6] is a comprehensive, holistic approach to modeling, study, development, engineering, evolution, and lifecycle support of systems. DMReview [1] defines: Object-Process Methodology (OPM): A conceptual modeling approach for complex systems that integrates in a single view the functional, structural and procedural aspects of the modeled system using formal yet intuitive graphics that is translated on the fly to a subset of natural language. Employing a combination of graphics and a subset of English, the OPM paradigm integrates the objectoriented, process-oriented, and state transition approaches into a single frame of reference. Structure and behavior coexist in the same OPM model without highlighting one at the expense of suppressing the other to enhance the comprehension of the system as a whole. Rather than requiring that the modeler views each of the system's aspects in isolation and struggle to mentally integrate the various views, OPM offers an approach that is orthogonal to customary practices. According to this approach, various system aspects can be inspected in tandem for better comprehension. Complexity is managed via the ability to create and navigate via possibly multiple detail levels, which are generated and traversed through by several abstraction/refinement mechanisms. Due to its structure-behavior integration, OPM provides a solid basis for representing and managing knowledge about complex systems, regardless of their domain. This section provides an overview of OPM, its ontology, semantics, and symbols. 9. The OPM Ontology The elements of the OPM ontology, shown in Figure 1, are divided into three groups: entities, structural relations, and procedural links Entities Entities, the basic building blocks of any system modeled in OPM, are of three types: stateful objects, namely objects with states, and processes. As defined below, processes transform objects by (1) creating them, (2) destroying them, or (3) changing their state. The symbols for these three entities are respectively shown as the first group of symbols at the left hand side of Figure 1, which shows the symbols in the toolset available as part of the GUI of OPCAT [7, 8]. entities structural relations procedural links Figure 1. The three groups of OPM symbols in the toolset of OPCAT 9.2. OPM Things: Objects and Processes Objects are (physical or informatical) things that exist, while processes are things that transform (create, destroy, or change the state of) objects. Following is a set of basic definitions that build on top of each other. An object is a thing that exists. Objects are the things that are being transformed in the system. Processes are the things that transform objects in the system. A process is a thing that represents a pattern of object transformation. In OPL, bold Arial font denotes non-reserved phrases, while non-bold Arial font denotes reserved phrases. In OPCAT, various OPM elements are colored with the same color as their graphic counterparts (by default, objects are green, processes are blue, and states are brown). Essence is an attribute that determines whether the thing is physical or informational. The default essence is informatical. A thing whose essence is physical is symbolized by a shaded shape. Affiliation is an attribute that determines whether the thing is environmental (external to the system) or systemic. The default affiliation is systemic. A thing whose affiliation is environmental is symbolized by a dashed contour OPM States Objects can be stateful, i.e., they may have one or more states. A state is a situation at which an object can exist at certain points during its lifetime or a value it can assume.

6 Stateful objects can be affected, i.e., their states can change. Effect is a change in the state of an object OPM Structure Modeling Structural relations express static, time-independent relations between pairs of entities, most often between two objects. Structural relations, shown as the middle group of six symbols in Figure 1, are of two types: fundamental and tagged The four fundamental structural relations Fundamental structural relations are a set of four structural relations that are used frequently to denote relations between things in the system. Due to their prevalence and usefulness, and in order to prevent too much text from cluttering the diagram, these relations are designated by the four distinct triangular symbols shown in Figure 1. The four fundamental structural relations are: (1) aggregation-participation, a solid triangle,, which denotes the relation between a whole thing and its parts, (2) generalization-specialization, a blank triangle,, which denotes the relation between a general thing and its specializations, giving rise to inheritance, (3) exhibition-characterization, a solid inside blank triangle,, which denotes the relation between an exhibitor a thing exhibiting a one or more features (attributes and/or operations) and the things that characterize the exhibitor, and (4) classification-instantiation, a solid circle inside a blank triangle,, which denotes the relation between a class of things and an instance of that class. Each fundamental structural relation has a default, preferred direction, which was determined by how natural the sentence sounds. Each one of the four fundamental structural relations is characterized by the hierarchy it induces between the root the thing attached to the tip of the triangle and the leaves the thing(s) attached to the base of the triangle, as follows. (1) In aggregation-participation, the tip of the solid triangle,, is attached to the whole thing, while the base to the parts. (2) In generalization-specialization, the tip of the blank triangle,, is attached to the general thing, while the base to the specializations. (3) In exhibition-characterization, the tip of the solid inside blank triangle,, is attached to the exhibitor (the thing which exhibits the features), while the base is attached to the features (attributes and operations). (4) In classification-instantiation, the tip of the solid circle inside a blank triangle,, is attached to the thing class, while the base to the thing instances. The things which are the leaves of the hierarchy three, namely the parts, features, specializations, and instances, are collectively referred to as refineables, since they refine the ancestor, the root of the tree. Refineable is a generalization of part, feature, specialization, and instance. Figures 2 through 5 present examples for each one of the four fundamental structural links, showing the root and the refineables for each link, and the corresponding OPL sentence in the figure legend. Figure 2. OPD of the sentence "RDF Statement consists of Subject, Predicate, and Object." Figure 3. The OPD obtained by inputting into OPCAT the OPL sentence "RDF is a Language." 9.5. OPM Behavior Modeling Procedural links connect entities (objects, processes, and states) to express dynamic, time-dependent

7 behavior of the system. Behavior, the dynamic aspect of a system, can be manifested in OPM in three ways: state to Cashing, while an output link leads from Cashing to the final state cashed. Figure 4. The OPD representing the sentence RDF has a simple data model." Figure 6. The Cashing process changes the state of Check from the uncashed to the cashed state. The OPL sentence generated automatically by OPCAT as a result of adding these input and output links is: Cashing changes Check from uncased to cashed. Figure 5 The OPM model of "XMLLiteral is instance of Datatype of RDF." (1) A process can transform (generate, consume, or change the state of) objects, (2) An object can enable a process without being transformed by it, and (3) An object or a process can trigger an event that might, in turn, invoke a process if some conditions are met. Accordingly, a procedural link can be a transformation link, an enabling link, or an event link Transformation links A transformation link expresses how a process transforms one or more objects. The transformation of an object can be its consumption, generation, or state change. The transforming process is the transformer, while object that is being transformed is called transformee Input and output links In Figure 6, Cashing is linked to the two states of Check: An input link leads from the initial uncashed Effect link Sometimes we may not be interested in specifying the states of an object but still show that a process does affect an object by changing its state from some unspecified input state to another unspecified output state. To express this, we suppress (hide) the input and output states of the object, so the edges of the input and output links migrate to the contour of the object and coincide, yielding the effect link shown in Figure 7. The OPL sentence that represents this graphic construct is: Cashing affects Check. Figure 7. Suppressing the input and output states of Check cause the two link edges to migrate to the contour of Check and coincide, yielding the single bidirectional effect link between Check and Cashing. We have seen that one type of object transformation is effect, in which a process changes the state of an object from some input state to another output state. When these two states are expressed (i.e., explicitly

8 shown), then we can use the pair of input and output links to specify the source and destination states of the transformation. When the states are suppressed, we express the state change by the effect link, a more general and less informative transformation link Result and consumption links State change is the least drastic transformation that an object can undergo. Two more extreme transformations are generation and consumption, denoted respectively by the result and consumption links. Generation is a transformation which causes an object, which had not existed prior to the process execution, to become existent. For example, as Figure 8 shows, Check is born as a result of a Check Making process. Figure 8. The object Check is consumed as a result of executing the Destroying process. The result link is the arrow originating from the generating process and leading to the generated object. The OPL sentence that represents this graphic construct (shown also in Figure 8) is: Check Making yields Check. In contrast to generation, consumption is a transformation which causes an object, which had existed prior to the process execution, to become nonexistent. For example, Check is consumed as a result of a Destroying process State-specified result and consumption links We sometimes wish to be specific and state not only that an object is generated by a process, but also at what state that object is generated. Some other times, we might wish to be able to state not only that an object is consumed by a process, but also at what state that object has to be in order for it to be consumed by the process. As Figure 9 shows, the object Check is generated in its unendorsed state as a result of executing the process Check Making. Figure 9. The object Check is generated in its unendorsed state as a result of executing the Check Making process. The OPL sentence that represents this statespecified result link graphic construct (shown also in Figure 9) is: Check Making yields unendorsed Check. In comparison, the regular, non-state-specified result link is the same, except that the (initial) state is not specified: Check Making yields Check. The difference is the addition of the state name (unendorsed in our case) before the name of the object (Check) that owns that state. Analogously, a state-specified consumption link leads from a (final) state to the consuming process. For example, assuming a check can only be destroyed if it is cashed, Figure 10 shows the state-specified consumption link leading from the final state cashed of Check to the consuming process Destroying. The OPL sentence that represents this statespecified consumption link graphic construct (shown also in Figure 10) is: Destroying consumes cashed Check Enablers and enabling links An enabler is an object that is required for a process to happen, but is not transformed by the process. An enabling link expresses the need for a (possibly statespecified) object to be present in order for the enabled process to occur. The enabled process does not transform the enabling object. An agent is a human enabler, while an instrument is a non-human one. The agent and instrument links are the first two in the procedural links group in Figure OPM Model of SOA-based Lifecycle Having presented the main concepts of OPM, their graphic symbols and OPL syntax, we now turn back to the SOA lifecycle discussed in Section 6.

9 from BPEL4WS-modeled to web-serviced and Enterprise BPEL4WS Model from skeletal to webservices embedded. Figure 10. The object Check is consumed in its cashed state as a result of executing the Destroying process. Figure 11 is an Object-Process Diagram (OPD) of a generic OPM model of SOA-based Lifecycle Development. Figure 12 is the Object-Process Language (OPL) paragraph of the SOA-based Lifecycle Development that was generated automatically by OPCAT. Note that both the OPD and the OPL faithfully and intuitively describe the exact model discussed in Section 7 SOA-based Lifecycle Development. In order to get a more vivid picture of our modeled system in action and capture design errors as soon as they are created, we have the option in OPCAT to run an animated simulation. Enterprise can be pre- modeled, conceptually modeled, web-serviced, or BPEL4WS- modeled. pre- modeled is initial. web-serviced is final. Enterprise Model Set consists of Enterprise Conceptual Model, Enterprise BPEL4WS Model, and Web Services Repository. Enterprise BPEL4WS Model can be skeletal or webservices embedded. skeletal is initial. web-services embedded is final. Conceptual Modeling changes Enterprise from premodeled to conceptually modeled. Conceptual Modeling yields Enterprise Conceptual Model. Enterprise Service Modeling requires Enterprise Conceptual Model. Enterprise Service Modeling changes Enterprise from conceptually modeled to BPEL4WS- modeled. Enterprise Service Modeling yields skeletal Enterprise BPEL4WS Model. Web Services Embedding requires Web Services Repository. Web Services Embedding changes Enterprise BPEL4WS Model from skeletal to web-services embedded and Enterprise from BPEL4WS- modeled to web-serviced. Conceptual Model Enhancing requires web-services embedded Enterprise BPEL4WS Model. Conceptual Model Enhancing affects Enterprise Conceptual Model. Figure 12. OPL of SOA-based Lifecycle Development. More refined views on each one of these top-level processes, such as Web Services Embedding, can be specified within in-zoomed OPDs that OPCAT enables to create with a click of a button, maintaining the consistency across all the OPDs in the system's OPD set. Figure 11. OPD of SOA-based Lifecycle Development. Figure 13 shows the initial stage, where no process has yet been activated and the only existing objects are the Enterprise in its pre-modeled state and the Web Services Repository. Figure 14 shows another snapshot of the animation, where Enterprise Service Modeling has already executed and generated the skeletal Enterprise BPEL4WS Model, while Web Services Embedding, now in action, is concurrently changing the Enterprise 11. Summary and Future Work It seems like the jury is already out on the outcomes of the fierce battle between OO and SOA, with SOA exiting with the upper hand. However, SOA needs a solid, well balanced methodological foundation in order to provide it with a holistic framework. Object- Process Methodology, which balances structure and behavior in a single bi-modal model is the ideal paradigm for this purpose. We have constructed the top-level diagram of an OPM SOA-based lifecycle engineering model. The combination of intuitive and formal graphics with the subset of English, generated on the fly, enables all the stakeholders involved to be on the same page with respect to the system's details at all levels.

10 Figure 13. Animated simulation of SOA-based Lifecycle Development: The initial system state Figure 14. Animated simulation of SOA-based Lifecycle Development: Web Services Embedding in action The main benefits of OPCAT s holistic modeling approach include improved communication between all involved stakeholders via OPCAT s intuitive yet comprehensive common graphic and textual language; leveraging past investments while mitigating the risk of abrupt transformation to new architectures via stepby step implementation; avoiding duplications and enhancing reuse of the organization's assets; improving the utilization of legacy systems; and animated simulation of the entire system at the design level. Following near future R&D work, OPCAT [7] SOA Modeling Solution will enable the organization to clearly and concisely model its entire end-to-end service-based architecture based on Object-Process Methodology. The resulting platform-independent holistic model of the organization's Service Oriented Architecture will seamlessly integrate business processes, legacy systems, the corporate data warehouse, internal and external databases and services, and corporate policies, such as security, privacy, and access control, incorporating and hooking to the plethora of state-of-the-art SOA-related technologies surveyed in this paper. The comprehensive system-of-systems model will serve as the underlying infrastructural blueprint for the entire enterprise and enable overseeing its operations, management, and control. It can be simulated and verified conceptually, exported and implemented by tools employing such standards as BPEL, J2EE, and.net, while being maintained current and accurate via two-way communication with these deployment tools. Acknowledgements This work was partially supported by the Gordon Research Fund for Systems Engineering, Technion and by the European Networks of Excellence COCOON and TERREGOV. References [1] DMReview. Available resources/glossary.cfm?keywordid=s, [2] Service Oriented Enterprise. Available tml, [3] Business Process Execution Language for Web Services version 1.1 IBM, BEA Systems, Microsoft, SAP AG, Siebel Systems. Available ibm.com/developerworks/library/specification/ws-bpel/, [4] Kloppmann, M., Koenig D., Leymann, F. Pfau, G., Rickayzen, A., von Riegen, C., Schmidt, P., and Trickovic, I. WS-BPEL Extension for People BPEL4People. A Joint White Paper by IBM and SAP, July Available: ibm.com/developerworks/webservices/library/specificati on/ws-bpel4people/ [5] Dori, D. Object-Process Analysis: Maintaining the Balance between System Structure and Behavior. Journal of Logic and Computation, 5, 2, 1995, pp [6] Dori, D. Object-Process Methodology - A Holistic Systems Paradigm, Springer Verlag, Berlin, Heidelberg, New York, [7] Dori, D., Reinhartz-Berger, I., and Sturm, A. Developing Complex Systems with Object-Process Methodology using OPCAT. Conceptual Modeling ER Lecture Notes in Computer Science (2813), 2003, pp