« April 2006 | Main | Juni 2006 »
31.05.06
Reasoning about SOA statements - 1 Service-oriented architecture
As announced here I (will) comment and elaborate on Stefan’s 10 SOA statements. In this issue I start with an examination of the concept of SOA.
I will not try to give a concrete definition of SOA or Service. Others have failed miserably and I don’t intend to join the club ;-). I will rather present my view of these concepts and the conclusions I’ve drawn.
In order to arrive at a definition or understanding of a complex term it is advisable to decompose it. I start with breaking up “Service-oriented architecture” (SOA) into “Service-oriented” and “architecture”. Wikipedia give a good enough definition of “Software architecture”:
Software architecture or software systems architecture can best be thought of as a representation of an engineered (or To Be Engineered) software system, and the process and discipline for effectively implementing the design(s) for such a system. Such a software system is generally part of a larger system encompassing information and general and/or special purpose computer hardware.
It is a representation because it is used to convey the information content of the related elements comprising a system, the relationships among those elements, and the rules governing those relationships.
It is a process because a sequence of steps is prescribed to produce or change the architecture, and/or a design from that architecture, of a system within a set of constraints.
It is a discipline because a body of knowledge or a general set of principles of (software) architecture is used to inform practitioners as to the most effective way to design the system within a set of constraints.
The important part of this definition is that “[…] architecture can best be thought of as a representation of an engineered (or To Be Engineered) software system, and the process and discipline for effectively implementing the design(s) for such a system […]” according to “[…] a general set of principles […]”. In short architecture
- defines how a design will be implemented (in respect of the representation and the process)
- adheres to a set of principles
The second part is “Service-oriented”. In the context of software development “oriented” is closely linked to “paradigm”. Thus “Service-oriented” represents a paradigm centered around “Services”. You might compare this to “Objects” within “Object-oriented”. In short Objects are described by their behavior, which is controlled by its state (internal structure). Objects interact with each other and react to events from the outside. Object-oriented analysis/design/programming provide suitable means for modeling (analyzing, designing, implementing) real world artefacts according to the OO paradigm, which is defined by a set of principles (-> Classes, Objects, Methods, Events, Inheritance, Polymorphism, …). The Service-oriented paradigm provides concepts such as Services, contracts, messages and documents. These concepts will be described in the following issues. At the moment the point is that “Service-orientation” represents a set of principles (-> paradigm), which are used to model real world artefacts in terms of software Services.
By reconstructing the term “Service-oriented architecture” from its decomposition we arrive at the following statement: Service-oriented architecture represents a means of implementing software systems, which adheres to the concepts of Services, contracts, messages and documents (among others). In other words Service-oriented architecture described a software architecture (template), which is based on the Service-oriented paradigm. Several conclusions can be drawn from this statement:
- There isn’t a single “Service-oriented” architecture. Within the boundaries of the Service-oriented paradigm several alternatives are thinkable.
- Every means or process of analyzing, designing, implementing and maintaining a system adhering to the Service-oriented paradigm should provide suitable means for constructing Services, contracts, messages and documents.
- Service-oriented architecture is a concept. It is by no means a product. Thus you cannot buy a SOA in terms of a product!
And a multitude of questions:
- What’s modeled by a Service?
- What’s the relation between Services, business process management and objects?
- What do I gain by introducing a SOA (on the management and development level)?
- How do I implement a SOA? Best practices?
- Many others, which will hopefully be answered in future entries …
I will present my ideas and views on these topics in future entries. Stay tuned.
Posted by Hartmut Wilms at 14:39 | TrackBack
Reasoning about SOA statements
While talking about Service design and implementation with Stefan some time ago, I felt the urge to reason about his 10 SOA statements, which he published half a year ago. As he pointed out himself the most interesting points are presented, discussed respectively, in the accompanying comments.
I will present my musings on the following statements within the next weeks (that’s the plan …):
- The word meanings of the three components within “Service-oriented architecture” in order to arrive at an understanding what Services and SOA are all about. In a way I will be referring to statements 1, 7 and 10.
- Statement 5 and 6, which discuss the relationship between SOA and Web services.
- Statement 3 in respect of the meaning of messages and documents and their relationship (in the context of a SOA).
- Statement 3 and 4 in respect of Service contracts and interfaces.
- Loose coupling, its dimensions and their impact on or correlation with service layers/types.
A lot of stuff for the next month(s)!