« Reasoning about SOA statements | Main | ReSharper 2.0 has been released! »
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 31.05.06 14:39
Trackback Pings
TrackBack URL for this entry:
http://www.innoq.com/movabletype/mt-tb.cgi/1919