| Abstract | Cilj predložene disertacije je umanjiti rizike izazvane negativnim stavom korisnika prema uvođenju uslužno usmjerene arhitekture. Prepoznat je zazor korisnika od kompleksnosti koju uslužno usmjerena arhitektura donosi sa svojim slojevima. Ispunjenje nužnih uvjeta za uspjeh kod uslužno usmjerenih sustava teže je nego kod tradicionalnih informacijskih sustava pa se želi pronaći postupke za uspješno uvođenje uslužno usmjerene arhitekture, ali na razini za praktičnu primjenu kao i okvir za upravljanje pogreškama u sustavima zasnovanima na uslužno usmjerenoj arhitekturi. Prvo će se analizom literature pružiti podloga za vezu između uslužno usmjerene arhitekture i modela zrelosti te predstaviti referentni model zrelosti uslužno usmjerene arhitekture. Zatim će se upotrebom komparativne analize predloženi modeli zrelosti svesti na referentni model zrelosti. U formuliranju glavnih postupaka u implementacijama uslužno usmjerene arhitekture koristit će se kvalitativna analiza sadržaja. Kroz analizu čimbenika koji utječu na strategiju rukovanja pogreškama može se sažeti da je potreban okvir koji će moći rukovati pogreškama koje nastaju na pozivu servisa, bilo da je uzrok na klijentskoj ili poslužiteljskoj strani, za sinkrone i asinkrone procese upotrebljavajući dostupne akcije oporavka uz uključenje potrebnih uloga u organizaciji. Provjera predloženoga okvira za rukovanje pogreškama provjerava se kao dokaz koncepta. Glavni koncepti koji predstavljaju postupke za uspješno uvođenje uslužno usmjerene arhitekture proizašli iz ovoga istraživanja su: slojevi servisa, poslovni objekti servisa, integracijski centar, okvir za rukovanje pogreškama, sigurnost, upravljanje verzijama i bazno upravljanje. Predloženi okvir za upravljanje pogreškama zasniva se na mogućnostima posredničkoga softvera, a obilježje mu je da uključuje zajednički ljudski rad. Kroz raspravu sa stručnjacima iz domene uslužno usmjerene arhitekture i usporedbu rezultata s radovima koji su opisani kao relevantni radovi na temu uspjeha uslužno usmjerene arhitekture pokazano je da se identificirane čimbenike u tim radovima može preslikati na koncepte koji su proizašli iz ovoga istraživanja. Kroz dokaz koncepta na izgrađenom procesu primijenjen je okvir za rukovanje pogreškama i pokazalo se da je moguće djelotvorno rukovati pogreškama nastalima na pozivu servisa. |
| Abstract (english) | Service-Oriented Architecture (SOA) has become a widespread architecture and integration means in companies due to increased use and maturing of standards, technologies, tools and platforms. In order to achieve balance between long-term goals and short-term business needs, companies have to establish an appropriate organizational and operational mode from the beginning of service-oriented architecture initiatives. The backbone of an SOA roadmap development process is the maturity model. However, maturity models cannot provide a concrete roadmap because they are focused on a concise description of the most important information about the architecture and not on the complex interaction of multiple factors. To start the transformation to a service oriented architecture successfully, precisely these factors, namely practices, need to be identified. Therefore, a reference maturity model is defined to which various maturity models will be compared. This enables us to analyze the capabilities that belong to the first level of maturity since our goal is to identify and overcome those practices in order to achieve an opportunity for a higher level of maturity. In the first step of the research, the maturity models are compared in order to determine which levels are compatible with the first level. The literature review in this paper is focused primarily on service-oriented architecture maturity models as the most commonly used and available maturity models. In addition, their capabilities are described adequately and in detail. A comparative analysis approach is used to transfer the analyzed service-oriented architecture maturity models to the proposed reference maturity model. The second step of the research includes the analysis of capabilities from the maturity levels of the analyzed service-oriented architecture maturity models that correspond to the first level. In formulating common practices in SOA implementation, it is used relational content analysis method to select the core practices. A domain-independent analysis of capabilities is conducted since different maturity models have differently defined capability domains. The most difficult part was to identify practices concealed behind the description capability and to detect at which knowledge or application level they can be expected. Moreover, the same practice was described in several capability domains and it was often applied at a higher maturity level in the broad enterprise segment. The key practices derived from the analysis of maturity capabilities at the stability level of maturity are: service layers, business object services, integration center, error-handling framework, security, versioning and basic governance. One of the key practices, error-handling framework, was identified as most important in SOA-based systems. Composite applications must be reliable and available, in the same manner as traditional applications. Due to the multi-layered architecture of the service oriented architecture, however, this may appear more difficult to achieve. It is necessary to use an effective error-handling method in order to increase system fault tolerance. The aim of the second part of this research is to present an error-handling framework by means of the platform properties that are used for building the service-oriented architecture platform. Taking into account the analysis of the factors that influence the error-handling strategy, we can summarize that we need a framework that will be able to handle runtime errors deriving from the partner service call (whether the cause be on the client or the server part), and for synchronous and asynchronous processes using available recovery actions and including the necessary roles in the organization. One of the main requirements is to avoid writing a code for error handling inside the BPEL process, preferably any such code. Furthermore, such framework should minimize the number of terminated processes and recovery time. The framework is based on the capacity of the SOA platform that enables the BPEL engine to intercept an error before it occurs in the process and recovery actions. The proposed framework is built using service-oriented architecture platform as a proof-of-concept. The implementation relies on middleware and BPEL engine capabilities. The current generation of middleware enables handling of some errors outside the process definition, which provides us the possibility to write process and focus on the business problem without the burden of error-handling code. An error framework such as this has a limitation that depends on middleware APIs that are not standardized. At least, users will be acquainted with properties and features of middleware when selecting SOA products. We expect in future that more platform features will be as “out of the box” as those we have created in this framework. Finally, we need improved transaction control to completely control a business process. Future study could provide a case study analysis in order to confirm or disprove these practices. |
