Service-oriented modeling is the discipline of modeling business and software systems, for the purpose of designing and specifying service-oriented business systems within a variety of architectural styles and paradigms, such as application architecture, service-oriented architecture, microservices, and cloud computing.

Any service-oriented modeling method typically includes a modeling language that can be employed by both the "problem domain organization" (the business), and "solution domain organization" (the information technology department), whose unique perspectives typically influence the service development life-cycle strategy and the projects implemented using that strategy.

Service-oriented modeling typically strives to create models that provide a comprehensive view of the analysis, design, and architecture of all software entities in an organization, which can be understood by individuals with diverse levels of business and technical understanding. Service-oriented modeling typically encourages viewing software entities as "assets" (service-oriented assets), and refers to these assets collectively as "services." A key service design concern is to find the right service granularity both on the business (domain) level and on a technical (interface contract) level.

edit

Several approaches have been proposed specifically for designing and modeling services, including SDDM, SOMA and SOMF.

Service-oriented design and development methodology

edit

Service-oriented design and development methodology (SDDM) is a fusion method created and compiled by M. Papazoglou and W.J. van den Heuvel.[1] The paper argues that SOA designers and service developers cannot be expected to oversee a complex service-oriented development project without relying on a sound design and development methodology. It provides an overview of the methods and techniques used in service-oriented design, approaches the service development methodology from the point of view of both service producers and requesters, and reviews the range of SDDM elements that are available to these roles.

An update to SDDM was later published in Web Services and SOA: Principles and Technology by M. Papazoglou.[2]

Service-oriented modeling and architecture

edit

IBM announced service-oriented modeling and architecture (SOMA) as its SOA-related methodology in 2004 and published parts of it subsequently.[3] SOMA refers to the more general domain of service modeling necessary to design and create SOA. SOMA covers a broader scope and implements service-oriented analysis and design (SOAD) through the identification, specification and realization of services, components that realize those services (a.k.a. "service components"), and flows that can be used to compose services.

SOMA includes an analysis and design method that extends traditional object-oriented and component-based analysis and design methods to include concerns relevant to and supporting SOA. It consists of three major phases of identification, specification and realization of the three main elements of SOA, namely, services, components that realize those services (aka service components) and flows that can be used to compose services.

SOMA is an end-to-end SOA method for the identification, specification, realization and implementation of services (including information services), components, flows (processes/composition). SOMA builds on current techniques in areas such as domain analysis, functional areas grouping, variability-oriented analysis (VOA) process modeling, component-based development, object-oriented analysis and design and use case modeling. SOMA introduces new techniques such as goal-service modeling, service model creation and a service litmus test to help determine the granularity of a service.

SOMA identifies services, component boundaries, flows, compositions, and information through complementary techniques which include domain decomposition, goal-service modeling and existing asset analysis. The service lifecycle in SOMA consists of the phases of identification, specification, realization, implementation, deployment and management in which the fundamental building blocks of SOA are identified then refined and implemented in each phase. The fundamental building blocks of SOA consist of services, components, flows and related to them, information, policy and contracts.[4]

Service-oriented modeling framework

edit

Service-oriented modeling framework (SOMF) has been devised by author Michael Bell as a holistic and anthropomorphic modeling language for software development that employs disciplines and a universal language to provide tactical and strategic solutions to enterprise problems.[5] The term "holistic language" pertains to a modeling language that can be employed to design any application, business and technological environment, either local distributed, or federated. This universality may include design of application-level and enterprise-level solutions, including SOA landscapes, cloud computing, or big data environments. The term "anthropomorphic", on the other hand, affiliates the SOMF language with intuitiveness of implementation and simplicity of usage.

Discipline-specific modeling process

edit

SOMF is a service-oriented development life cycle methodology, a discipline-specific modeling process. It offers a number of modeling practices and related disciplines that contribute to a successful service-oriented life cycle development and modeling during a project. The image below illustrates the major elements that identify the “what to do” aspects of a service development scheme. These are the modeling pillars that will enable practitioners to craft an effective project plan and to identify the milestones of a service-oriented initiative—either a small or large-scale business or a technological venture.

 
Service-Oriented Modeling Framework (SOMF) Processes, Artifacts, and Best Practices

SOMF building blocks

edit

Furthermore, the video clip below, depicts the three SOMF building blocks, segments that drive the service-oriented modeling process:

  1. Practices and Modeling Environments. These are the two overlapping Abstraction and Realization Practices that are implemented in three service-oriented modeling environments: Conceptual Environment, Analysis Environment, and Logical Environment.
  2. Modeling Disciplines. Each service-oriented modeling environment is driven by a related discipline: Conceptual Architecture Discipline, Service Discovery & Analysis Discipline, and Logical Architecture Discipline.
  3. Artifacts. This SOMF segment identifies the chief artifacts required for each modeling environment.
Service-Oriented Modeling Framework (SOMF) Three Segments (while running stop to review in details)

See also

edit

References

edit
  1. ^ Mike P. Papazoglou, Willem-Jan van den Heuvel: Service-oriented design and development methodology. Int. J. Web Eng. Technol. 2(4): 412–442 (2006)
  2. ^ M. Papazoglou, INFOLAB, Tilburg University, The Netherlands (2013) Web Services and SOA: Principles and Technology (2nd Edition), Pearson Education Canada, Paper, 856 pp, published 01/13/2012, ISBN 9780273732167
  3. ^ Ali Arsanjani, Abdul Allam: Service-Oriented Modeling and Architecture for Realization of an SOA. IEEE SCC 2006: 521
  4. ^ Bieberstein et al., Executing SOA: A Practical Guide for the Service-Oriented Architect (Paperback), IBM Press books, 978-0132353748
  5. ^ Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. ISBN 978-0-470-14111-3.

Further reading

edit
edit