From SOA to Semantic Service Provisioning

Today’s enterprises have to adapt to the ever changing world to face competitors from all over the world. Well adapted business processes are a key factor leading to improved competitiveness. However, these processes are embedded in an entire Enterprise Architecture. Adaptation of business processes towards new challenges usually mean that an adaptation of the existing Enterprise Architecture is needed. For this reason is flexibility of existing Enterprise Architectures an issue when it comes to business competition.

When speaking of Enterprise Architectures (EA), we do not mean architectures of enterprise application systems, which more precisely can be referred to as Enterprise Application Architectures. Indeed, the proper definition of an EA seems useful in order to facilitate a common understanding for the subsequent sections of this page. The following definition is slightly adapted from [WPEA]:

Enterprise Architecture is the current or future structuring of an organization’s processes, information systems, personnel and organizational sub-units, so that they align with the organization’s core goals and strategic direction.

As an enterprise’s core competence is based on its EA, the whole enterprise is sentenced to function inefficiently if the enterprise’s architecture is inefficient. Of course, enterprise architectures, especially those of large companies, may become extremely complex. Mastering the EA and its complexity is a non-trivial challenge. Therefore, it is the concern of the ASG project to provide an architecture that overcomes drawbacks in current EA.

Important criteria an architecture should follow:

• Flexibility: the ability to easily implement a change in a business process
  
• Maintainability: the easiness of operation of the architecture
  
• Openness: the ability to easily integrate (technically) a new system/function
  
• Adaptability: the ability to easily integrate new functionality
  

Service-oriented Architecture (SOA)

Service orientation is the state of art in Enterprise Architecture. In contrast to previous approaches like EAI that were mainly technology-driven, service orientation focuses on services and business processes. But still, many efforts for the introduction of SOAs are solely focussed on technology. SOA is considered as an integration approach on a technological level rather than on a business process one. The following principles should be considered during a shift to SOA. The following figure shows how a SOA should look like.

The grey box on the right symbolises the SOA infrastructure responsible for the management and provision of services. It contains an EAI server, a service registry, a process engines, a portal server, and a web application server for service wrappers and proxies for legacy systems. As you might have noticed SOA requires a complex infrastructure. The number of infrastructure systems increased by 50% and the number of interfaces by 13%. Forrester Research already elaborated that SOA is not well suited for consolidation projects. Furthermore, a huge amount of efforts has to be spent making business applications service-ready (service enablement). But what you can see on the figure below is that the SOA has a huge impact on how business process are managed and enacted.

As all the functionality needed for business process activity implementation have been isolated in services, it is possible to centrally manage and govern the entire process life-cycle.

This brings us to the following SOA assessment table:

SOA Drawbacks

A deeper look into the elements of the SOA-related systems is presented in the figure above. This architecture has some significant drawbacks. Each business process variation needs to be defined, published and maintained in the business process management component. Considering a large number of process variations and their versions this can become a very hard task. If a new service is published in the service registry it is not used automatically. It needs to be referenced by process definitions. Think of a service that replaces another one. In this case all the process definitions need to be checked if they have to be modified. It is also difficult to manage a very large landscape of services. Having only a name and maybe a natural language description of the service it is very hard to find which services suites best for a certain process activity. The following table summarizes these drawbacks.

• Manual implementation of service enabling proxies
• Technology-driven transformations in the EAI server detract from business logic
• Complicated maintenance of process variations
• Newly appearing services are not automatically used in static process definitions.
• Difficult service discovery in large service landscape

Semantic Service Provisioning with ASG

With the help of semantic annotations for service provisioning an ASG compliant architecture implementation provides the following key features for service provisioning:

1. Seamless integration of heterogeneous external services
2. On-demand creation of service compositions
3. Reliable service provision with assured quality of service

With seamless integration not only the technical but also the functional integration of external services is addressed. An ASG compliant architecture exposes different technical protocols in a homogenous way to the higher-level ASG components.

An ASG compliant architecture is able to compose services to reach a user goal. Automated semantic-enabled service composition allows the creation of new services by composing existing services on-demand and at run-time for individual user requests.

ASG supports the description, negotiation, and realisation of non-functional service quality parameters. In cases of service failures or violations of agreed quality parameters, the platform reacts adaptively through re-enactment, re-binding or re-composition activities.

Relation to SOA Drawbacks

These ASG key features address all of the aforementioned drawbacks of "traditional" SOA. Let us examine those in more detail:

• Manual implementation of service enabling proxies: Service proxies can be implemented using service proxy development tools that wrap external services as ASG compliant web services.
  
• Technology-driven transformations in the EAI server detract from business logic: Transformations are described based on an ontology (business-driven).
  
• Complicated maintenance of process variations: No manual process definitions needed, as they are automatically and dynamically composed.
  
• Newly appearing services are not automatically used in static process definitions: Used automatically through automated run-time composition.
  
• Difficult service discovery in large service landscape: Services can be discovered using functional descriptions based on an ontology rather than keyword search.

ASG Reference Architecture

The figure above shows the ASG architecture that implements the key features for semantic service provisioning. Starting with a semantic service request issued by the service consumer, the Facade controls the handling of this request. It is first given to Dynamic Service Composition where a service composition for this request is created. For this purpose Dynamic Service Composition uses the matchmaking facilities of Semantic Service Discovery. The resulting service composition is then handed over to Adaptive Process Management for enactment. Prior to enactment, Adaptive Process Management creates an executable WS-BPEL process out of the service composition. It sub-component Negotiation therefore exchanges the semantic specifications of services inside the service composition by invocations of Web services. It selects these service based on QoS? parameters that can be provided statically or that can be negotiated at run-time. Resulting service level agreements are then stored and monitored during enactment. All invocations inside the WS-BPEL process are directed at the Service Infrastructure. It contains proxies for external services that are not necessarily Web services. These proxies transform the invocations to the correct protocol and data format of the external services. Service proxies are either developed manually or are generated during service integration by the Service Integration Tool.

Summary

More about the relationship between ASG and SOA is explained in the ASG Animation.