Enfoque interdisciplinario: OOD y SOA integrados

Un bien desarrollado artículo sobre arquitecturas orientadas a servicio, va contra la difundida idea de que la orientación a objetos no es adecuada en el marco de SOA.

While the SOA approach strongly reinforces well-established, general software architecture principles such as information hiding, modularization, and separation of concerns, it also adds additional themes such as service choreography, service repositories, and the service bus middleware pattern.
A structured approach or analysis and design method is required to craft SOAs of quality. As none of the existing approaches met the authors requirements on recent SOA projects, they suggest combining elements from well-established practices such as OOAD, EA, and BPM, complementing them with innovative elements upon demand.

Qué implica SOA (orientación a servicios) desde el punto de vista del diseño:

In anticipation of the discovery of new business opportunities or threats, the SOA architectural style aims to provide enterprise business solutions that can extend or change on demand. SOA solutions are composed of reusable services, with well-defined, published and standards-compliant interfaces. SOA provides a mechanism for integrating existing legacy applications regardless of their platform or language.
Conceptually, there are three major levels of abstraction within SOA:

• Operations: Transactions that represent single logical units of work (LUWs). Execution of an operation will typically cause one or more persistent data records to be read, written, or modified. SOA operations are directly comparable to object-oriented (OO) methods. They have a specific, structured interface, and return structured responses. Just as for methods, the execution of a specific operation might involve invocation of additional operations.
• Services: Represent logical groupings of operations. For example, if we view CustomerProfiling as a service, then, Lookup customer by telephone number, List customers by name and postal code, and Save data for new customer represent the associated operations.
• Business Processes: A long running set of actions or activities performed with specific business goals in mind. Business processes typically encompass multiple service invocations. Examples of business processes are: Initiate New Employee, Sell Products or Services, and Fulfill Order.

  In SOA terms, a business process consists of a series of operations which are executed in an ordered sequence according to a set of business rules. The sequencing, selection, and execution of operations is termed service or process choreography. Typically, choreographed services are invoked in order to respond to business events.

From a modeling standpoint, the resulting challenge is how well-designed operation, service, and process abstractions can be characterized and constructed systematically. The related issues currently are among the most frequently discussed ones in industry and academia. We are not aware of any recent SOA project or workshop in which such service modeling aspects have not been a major topic, giving fuel for numerous debates. So let us take a closer look.

Problemas de diseño orientado a objetos para la orientación a servicios:

The main issue with current OO design practices in relation to SO is that its level of granularity is focused at the class level, which resides at too low of a level of abstraction for business service modeling. Strong associations such as inheritance, create a rather tight coupling (and, consequently, a dependency) between the involved parties. In contrast, the SO paradigm attempts to promote flexibility and agility through loose coupling. There, currently, is no cross-platform inheritance support and first-class notion of a service instance in SOA in order to avoid having to deal with service lifecycle housekeeping issues such as remote garbage collection.
These considerations make OO difficult to align with the SO architectural style straightaway. However, OO still is a valuable approach for design of the underlying class and component structure within a defined service. Furthermore, many OOAD techniques such as classes, responsibilities, and collaborations (CRC) cards can be leveraged for service modeling, if elevated up to a higher level of abstraction.

La solución propuesta es un híbrido, Service-Oriented Analysis and Design (SOAD):

The basic concepts of Service-Oriented Architectures (SOAs) and Web services are becoming part of our everyday language and recognized as a suitable architectural style for crafting modern enterprise applications. In this context, the underlying issues of: what makes good services are becoming increasingly critical for ensuring the successful implementation of SOAs.
Existing modeling disciplines such as Object-Oriented Analysis and Design (OOAD), Enterprise Architecture (EA) frameworks, and Business Process Modeling (BPM) provide us with high-quality practices that can go a long way in assisting with the identification and definition of appropriate abstractions within an architecture. However, experience shows that these practices fall short when being applied independent of each other.
In this article, we will investigate suitable elements from OOAD, EA, and BPM. We will also motivate the need for a hybrid approach that combines elements of all of the disciplines, with a number of distinct, new elements. The resulting, interdisciplinary OOAD method facilitating successful SOA deployments, which we refer to as Service-Oriented Analysis and Design (SOAD), has yet to be formally defined. We merely take first steps into the SOAD space.

(...) The SOA vision is accepted rather easily, as its technical foundation is well-known. For example, applying general software architecture principles and OO techniques is a valid start in any SOA effort. However, as already stated, the question most frequently asked by early adopters is how to identify the right services. As stated earlier, OOAD, EA, and BPM cannot supply a satisfying answer when applied in isolation from each other, as we will explain now.
The OOAD methodology introduced in the seminal books from Booch and Jacobson (issued about a decade ago), provides an excellent starting point in defining SOAs. As such, OOAD is concerned with micro-level abstractions such as classes and individual object instances, although applying OOAD techniques and the Unified Modeling Language (UML) notation on the architectural level has been common practice for many years. As a standalone use case model is frequently created per problem domain, and consequently, application development project, the enterprise-wide big picture gets blurred in many cases. Furthermore, for various reasons the use case models are not always synchronized with their BPM counterparts.
EA approaches, such as Feature-Oriented Domain Analysis (FODA), and Zachman add a city-planning level viewpoint on top of solution architectures, but do not address how enterprise-wide abstractions of quality facilitating reuse and longevity can be found.
While BPM approaches such as BPMI do provide an end-to-end view on functional units of work, they typically do not reach into the architecture and implementation domain. For example, until the arrival of languages such as the Business Process Execution Language for Web Services (BPEL), BPM notations were missing operational semantics. Moreover, we have seen many cases in which the process modeling and the development initiatives were separated from each other.
Finally, none of the existing disciplines address how existing applications can be enabled for SOA; a top-down process is employed most of the time. Existing systems typically hold large amounts of critical data and business logic, and cannot simply be replaced. Hence, a bottom-up analysis of these systems also has to be conducted in order to investigate wrapping and refactoring strategies. Taking existing applications into account, therefore, leads to a meet-in-the-middle process.
A hybrid SOAD modeling approach is required for these reasons. The approach comprises elements from OOAD, BPM, and EA in a best-of-breed fashion, and complements them with certain innovative elements.

Este resumen es sólo introductorio, con el propósito de destacar aspectos de la arquitectura, y las exigencias que deben resolverse al pensar el diseño. El artículo es insustituíble, tanto en sí, como por su bibliografía.