Semantically enabled Service Oriented Architecture-Concepts Technology and Application
Semantically-enabled Service Oriented Architecture focused around principles of service orientation, semantic modeling, intelligent and automated integration deﬁnes grounds for a cuttingedge technology which enables new means to integration of services, more adaptive to changes in business requirements which occur over systems’ lifetime. We deﬁne the architecture starting from a global perspective and through Web Service Modeling Ontology as its semantic service model we narrow down to its services, processes and technology we use for the reference implementation. On a B2B integration scenario we demonstrate several aspects of the architecture and further describe the evaluation of the implementation according to a community-agreed standard evaluation methodology for semantic-based systems.
The design of enterprise information systems has gone through a great change in recent years. In order to respond to requirements of business for ﬂexibility and dynamism, traditional monolithic applications are being challenged by smaller composable units of functionality known as services. Information systems thus need to be re-tailored to ﬁt this paradigm, with new applications developed as services and legacy systems to be updated in order to expose service interfaces. The drive is towards a design of information systems which adopt paradigms of Service Oriented Architectures (SOA). With the goal of enabling dynamics and adaptivity of business processes, SOA builds a service-level view on organizations conforming to principles of well-deﬁned and loosely coupled services services which are reusable, discoverable and composable. Although the idea of SOA targets the need for integration that is more adaptive to change in business requirements, existing SOA solutions will prove difﬁcult to scale without a proper degree of automation. While today’s service technologies around WSDL, SOAP, UDDI and BPEL certainly brought a new potential to SOA, they only provide partial solution to interoperability, mainly by means of uniﬁed technological environments. Where content and process level interoperability is2 T. Vitvar et al. to be solved, ad-hoc solutions are often hard-wired in manual conﬁguration of services or work- ﬂows while at the same time they are hindered by dependence on XML-only descriptions. Although ﬂexible and extensible, XML can only deﬁne the structure and syntax of data. Without machineunderstandable semantics, services must be located and bound to service requesters at design-time which in turn limits possibilities for automation. In order to address these drawbacks, the extension of SOA with semantics offers scalable integration, that is more adaptive to changes that might occur over a software systems lifetime. Semantics for SOA allow the deﬁnition of semantically rich and formal service models where semantics can be used to describe both services offered and capabilities required by potential consumers of those services. Also the data to be exchanged between business partners can be semantically described in an unambiguous manner in terms of ontologies. By means of logical reasoning, semantic SOA thus promotes a total or partial automation of service discovery, mediation, composition and invocation. Semantic SOA does not however mean to replace existing integration technologies. The goal is to build a new layer on the top of existing service stack while at the same time adopting existing industry standards and technologies used within existing enterprise infrastructures. In this article, we describe the Semantically-enabled Service Oriented Architecture (SESA), building on a number of governing principles which underpins the analysis, design and implementation of architecture, its middleware, services and processing logic. We ﬁrst deﬁne the architecture from the global perspective and through underlying service model we narrow down to its services, processes and technology. We describe in detail service and process types which are provided and facilitated by the architecture as well as technology used for building the architecture, its middleware and service infrastructure. We also illustrate various parts of the architecture on a running example from the Business-to-Business (B2B) integration domain and ﬁnally describe evaluation of the architecture implementation with respect to this example.