Service Oriented Design and Development

SOAD – Service Oriented Analysis and Design

The term Service Oriented Analysis and Design was first used in the publication Elements of Service Oriented Analysis and Design. Service Oriented Analysis and Design is also covered in the publication Service Oriented Architecture Compass. Service Oriented Analysis and Design is a strategy that IBM created especially for Service Oriented Architecture. SOAD added innovations for service orchestration, the enterprise service bus, as well as service repositories. Moreover, it helps the construction, design, aggregation, and deployment of applications as web services based on UDDI, SOAP, and WSDL technology.

Service Modeling

Service modeling is descriptive of a sub process of the service oriented analysis process that is explored in the work of Thomas Erl called Service Oriented Architecture: Concepts, Technology, and Design. This process is responsible for defining and refining service candidates based on a number of vital considerations, including a particular subset of service orientation methodologies.

SOMA – Service Oriented Modeling and Architecture

This is another IBM concept. Service Oriented Modeling and Architecture refers to the general domain of service modeling that is necessary for the creation and design of Service Oriented Architecture. Service Oriented Modeling and Architecture covers a much larger scope and implements service oriented analysis and design via a specification, designation, and actualization of services, as well as the components that help realize those services and the flows that can aid in the process of building such services.

Service Oriented Modeling and Architecture is inclusive of an analysis and design system that extends traditional component based and object oriented methodologies to include things that are both supportive of and relevant to Service Oriented Architecture. Service Oriented Modeling and Architecture consists of three major steps of realization, identification, and specification of the three core components of Service Oriented Architecture.

Business Driven Development

Business driven development is a method for the development of Information Technology solutions that immediately satisfy the requirements of a Business. This goal is attained through the adoption of a model driven approach that effectively begins with the Business strategy, goals, and requirements, and then transforms these components into an Information Technology solution. Such a transformation is usually attained through the application of model transformations.

Owing to the alignment of Business and Information Technology layers, it is often possible for the propagation of changes in the Business to take place automatically in the Information Technology systems. The result is an increase in flexibility as well as shorter turnaround times during the period that the Information Technology system is being adapted. Business Driven Development shares these objectives with both Service Orientated Analysis and SOAD. This makes it one of the premiere methodologies for Service Oriented Architecture design. Business Driven Development and SOMA can be used together, as well.

Business Processes

A Business process can be viewed as a set of connected activities that effectively manages to create value through the transformation of an input in to a more valuable output. Output and input alike may be artifacts or data. Machines, human beings, or a combination of both might perform the transformation.

There are three main types of Business processes. The first, management, refers to the type of process that governs the operation. The second, operational, refer to the processes that forge the primary value stream that are part of the main Business. Finally, there are the supporting processes, which are meant to support the core processes; examples of supporting processes might include accounting or Information Technology support.

We might also further decompose Business processes in to numerous sub processes that possess attributes of their own. These sub processes also contribute the goal of attaining the super process. Analyzing Business processes usually entails the mapping of processes and sub processes down to the level of activity.

Activities can be thought of as those parts of the Business process that do not entail decision making actions. Thus, they are not considered worthy of decomposition, even though it would be possible to do so.

Within a workflow, Business Process Modeling Notation is often employed as a means for drawing Business processes up.

Workflow

Workflow can be thought of as the movement of projects or tasks through a particular work process. In other words, workflow describes the operational side of a work procedure – that is, how are tasks to be structured, who will perform them and in what order, how are they to be synchronized, how data should flow as a means of supporting the tasks, and how those tasks should be tracked. The dimension of time is also considered in the workflow. Thus, throughput is considered a distinct measure in the workflow realm. Problems relating to workflow are typically analyzed and modeled by utilizing such graph based formalisms as Petri nets.

The concept of workflow is not specific to IT. Support for workflow, however, is integrated in to both imaging and document management software. Since the year 1993, the Workflow Management Coalition has existed as a trade consortium to focus on workflow management as well as the interoperability of work flow management systems.

It is vital to make a distinction between Business and scientific workflow paradigms. While scientific paradigms tend to be concerned with the throughput of data via numerous algorithms, services and applications, Business paradigms are focused on the scheduling of task executions. These might include dependencies that are not necessarily driven by data. They may also include the use of human agents.

In the early part of this century, scientific workflows found major acceptance in such fields as cheminformatics and bioinformatics. It was in this field that the workflow paradigm was able to meet the need for the handling of multiple data formats, large data quantities, as well as multiple interconnected tools. What is more, the scientific workflow paradigm fell close to the established tradition of Perl scripting in life science research companies. Thus, this adoption was representative of a natural step towards structured infrastructure set ups.

Of course, Business workflows tend to be more generic, as they are able to represent any task structuring and can be applicable as well to task scheduling with application servers and the organization of paper or electronic document trails within a company.