Classical Process diagrams and Service oriented Architecture

Abstract

SOA (Service Oriented Architecture) has played in the last two decades a very useful role in the design philosophy of the target software. The basic units of software for which the mentioned philosophy is valid are called services. Generally it is counted that the advance implementation of services is given by using so–called Web services that are on the platform of the Internet 2.0. Naturally, there has been counted also with the fact that the services will be used in software applications designed by professional programmers. Later, the concept of software services was supported by the enterprise concept of the SOE type (Service oriented Enterprise) and by the creation of the SOA paradigm.Many computer scientists, including Thomas Erl – doyen of SOA, do not understand SOA either as an integrated technology or as a development methodology. Proofs of this statement are in the following definitions.SOA is a form of technology architecture that adheres to the principles of service – orientation. When realized through the Web services technology platform, SOA establishes the potential to support and promote these principles throughout the business processes and automation domains of an enterprise (Erl, 2006). Thomas Erl (Erl, 2007) has expressed the idea of SOA implementation using the following definition.SOA establishes an architectural model that aides to enhance the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing. Nevertheless the key principles, on which SOA is constructed (Erl, 2006), are not significantly reflected in any of the previous definitions. Some of the mentioned principles are still included at least in the more free definitions of SOA, for example (Barry, 2003).A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data or it could two or more services coordinating some activity. From the above mentioned we can pronounce a brief description of SOA. “SOA is an architectural style for consistency of business process logic and service architecture of the target software.”It is a complex of means for solution of special analysis, design, and integration of enterprise applications based on the use of enterprise services. The service solutions of the classic business process logic are, of course, based on the application of at least seven key principles of SOA (free relations, service contract, autonomy, abstraction, reusing, composition, no states). Key attributes of SOA are verbally described in (Erl, 2006). They are so important that a separate article should be devoted to their nature and formalization. On the other hand, there is also clear that each service solution of business logic should respect the principles published in SOA Manifesto, 2009, which are essentially derived from the key principles of SOA.In many publications there are given the SOA reference models usually composed of several layers (presentation layer, business process layer, composite services layer, application layer) giving a meta idea of SOA implementation. Perfect knowledge of the business process logic is a necessary condition for the development of a proper service solution. The different types of business processes should be described in the necessary details and contexts.Interestingly, the SOA paradigm does not provide its own method of finding and describing business processes by giving a layered transparent business process diagram. On the other hand, the methodology provides deep understanding of not only the characteristics of services, but also their functionality and implementation of the key principles of SOA (Erl, 2006).Let us assume that the required process diagrams can be achieved by using some of the advanced methods and descriptions. Among many other methods and description, we can introduce for example methods as Eriksson–Penker Business Extensions, ARIS, BORM (Business Object Relation Modeling) and description as BPMN (Business Process Modeling Notation).This offers the idea of using these methods and descriptions for the SOA paradigm for the purposes of process models conversion into schemes of services with built-in orchestration. Conversion of transformations should be based on the knowledge of two artifacts. The first is the output artifact – everything what diagram process provides for the target service scheme and the second is the input artifact – all what service schemes need.The issue of conversion transformations is the main topic of this contribution. Their implementation will allow software companies to move forward in the creation of service production and it gives a new view of the enterprise functionality in a service solution to company management.