Concept and Project Objectives
These days, semantics make up the most relevant line of investigation in the Information and Communication Technology (ICT) area. Semantics take ICT to the next level, transforming data into knowledge, and operations into functionalities, as well as offering the possibility of automated information processing.
One of the most interesting areas, within the application of Semantics, is Semantic Web Services. A lot of work currently carried out by developers and administrators is done by hand, or with the use of certain computer programs. Semantic Web Services focus on providing Web Services the ability to carry out this kind of work automatically (i.e. Web service discovery, Web service composition, Web service orchestration, Web service mediation, etc.). Semantics can also be used to organize full catalogues of available Web Services of a given organization and by developers, to program new business logic of a given system (whether or not they are exported as Web Services to the rest of the organization).
Web Services have been recognized as one of the fundamental technologies that will help to implement a Service Oriented Architecture (SOA). The central concept of SOA is the existence of services which provide access to capabilities by well-defined interfaces to be exercised following a service contract with constraints and policies. The major components of a basic SOA are: a service provider that publishes its service interface via a service registry which can be found by a service requester/consumer and can subsequently be bound to the service provider. Web Services constitute a widely accepted technology that enables the definition of service interfaces and protocols to exchange requests/responses between service providers and consumers. The use of semantics to characterize Web Services has introduced novel and powerful ways to publish and find services within a SOA.
Another important principle of SOA is to support highly flexible and dynamic ways of leveraging business processes. Organizations employing an SOA must take into consideration the fact that business processes can be defined over existing services orchestrated using scripting/process management technologies. This means that business processes must be characterized by the separation of the hard coded behaviour of basic components/systems exporting services from the software that automates business processes across these components/systems.
Process Management/Orchestration Technologies have emerged as important tools within SOA, particularly for businesses. These technologies aim to easily and flexibly allow changes to be made to process definitions, answering to the time-to-market requirements of current businesses. They also support the idea of minimizing programming as a way to reduce process development cycles.
Relying on Web Service as the basis technology to support the definition and invocation of services, as well as providing runtime support has led to the development of several technologies that support the idea of service oriented process management, as envisaged in SOA. BPEL (Business Process Execution Language), for example, is one of the most well known and most popular business process management technologies used within large IT companies. It is defined by OASIS and XPDL (XML Process Definition Language), which, in turn, is defined by the Workflow Management Coalition. However, despite BPEL’s popularity, existing business process management technologies have not been widely accepted by companies because of the fact that the promise to support simple and flexible creation of, and introduction of changes to, business management processes has not yet been delivered.
In our opinion, this is due to the fact that existing business process management technologies are program-centric rather than user-centric. These technologies rely on defining businesses processes by orchestrating invocations to available back-end services in a similar way to how any structured program invokes functions in available modules/libraries. Although it is true that business processes may support parallel invocation of services, synchronization points and even automatic compensation mechanisms, it is also true that these mechanisms are provided by some programming languages supporting concurrent programming. Complexity of programming is presumably hidden by means of visual process design tools that are intended to ease the definition of business processes by people who have little or no IT skills. However, business processes are not so different from structured programs. For example, its graphical process definition idea, supported by the visual process design tools associated with this technology, used to be quite similar to programming flowcharts. This has two implications. Firstly, the promise of enabling users with little or no IT skills to easily design processes is broken: the fact is that structured programming skills are essential. The second implication is that processes designed through programming flowcharts face several problems: for example, interaction with the user becomes hard to program and, due to the rigid structure of flowcharts it becomes difficult to make frequent minor changes to the execution flow, even by skilled analysts/programmers.
Pages: 1 2