The SOA4All framework supports a world where a massive number of parties expose and consume services by realizing a coherent and domain independent platform. The overall architecture of SOA4All can be structured into four main parts:
* *SOA4All Studio*: A rich Web platform that provides users with a unified view covering the whole lifecycle of services, including design-time, run-time and post-mortem analysis.
* *SOA4All Distributed Service Bus*: The infrastructural backbone around which all the SOA4All components communicate and collaborate by combining Semantic Spaces and Enterprise Service Bus.
* *SOA4All Platform Services*: The group of services that provide the basic SOA4All functionality and activities, such as Service Ranking and Selection, Service Discovery, Service Adaptation, Service Composition, Service Execution, and the Reasoning Engine.

In the very center, there is the *SOA4All Distributed Service Bus*. The Distributed Service Bus (DSB) serves as infrastructure service and core integration platform and is a direct evolution of the open-source PEtALS Enterprise Service Bus (ESB) that is promoted by the OW2 Consortium. The DSB delivers the necessary extensions and developments of the project to augment PEtALS towards large scale, open, distributed and hence Web-scale computing environments, as the one targeted by SOA4All. These extensions and consequently novelties of service bus infrastructures include ease of deployment, openness, scalability in terms of internal repositories, amongst others. To realize these extensions, the DSB will benefit from the internal use of the ProActive distributed programming language also promoted by OW2.

Problems to be solved to augment existing ESB technology as required are of similar nature as those raised when programming, deploying, securing, monitoring, adapting a distributed application on a computing grid infrastructure. Furthermore, the DSB is enhanced to incorporate a scalable Semantic Space infrastructure. The Semantic Space infrastructure is used as a shared memory to build repositories, as cooperative access to monitoring data, and as communication infrastructure to enhance the traditionally message-oriented bus towards a publication infrastructure for anonymous and asynchronous service communication with a notion of event-driven architecture; something currently neither available from openly-accessible ESB technology. In addition, the Deployment Facility provides a uniform, declarative, user-friendly, and automatic support for the management and distributed deployment of all software composing the whole SOA4All service computing environment (i.e., DSB, Studio, and platform services). Finally, the Monitoring Platform of the SOA4All DSB collects monitoring data about the usage of SOA4All Platform Services and traditional 3rd party Web services.

h2. Studio and Platform Services

Around the integration platform, the SOA4All Distributed Service Bus, there are the *SOA4All Studio{*}and the *SOA4All Platform Services*. These are the components that are delivered by other research and development work packages in the project. The SOA4All Studio is defined in WP2 and delivers a fully Web-based user front-end that enables the creation, provisioning, consumption and analysis of the platform services and various 3rd party business services that are published to SOA4All. The studio supports different types of users at different times of interaction.

SOA4All knows two major groups of users: i) a large group of service consumers that use SOA4All for the consumption of functionality that is provided by either platform services or by business services, and ii) a significantly smaller group of (administrative) users that exploits the capabilities of the platform services (via the SOA4All Studio) to annotate, select and compose Web services. The platform services are products of the SOA4All project and deliver service discovery, ranking and selection, composition and invocation functionality, respectively. These components are exposed to the SOA4All Distributed Service Bus as Web services and hence consumable as any other published service. Their functionalities are used by the SOA4All Studio to offer clients the best possible functionality, while their combined activities (i.e., discovery, selection, composition and invocation) are coordinated via the DSB. The ensemble of DSB, SOA4All Studio and platform services delivers the innovative, fully Web-based and Web-enabled service experience of the SOA4All project: global service delivery at the level of the bus, Web-style service access via studio, and advanced state-of-the-art service processing, management and maintenance via platform services.

h2. Business Services (Web Services) and Processes

The figure also shows the *semantic service descriptions and processes* (composed services) that are created and processed by means of the SOA4All infrastructure. First, there are available Web services that are exposed either as traditional RESTful services, or as traditional WSDL-based services (lower parts of the figure). These are invokable third-party business services that SOA4All enhances in terms of automation, composition and invocation. Second, the top-left of the figure depicts the semantic annotations of the business services, so-called Semantic Web services. The semantic descriptions are published in the Service Registry, and used for reasoning with service capabilities (functionality), interfaces and non-functional properties, as well as context data. These semantic descriptions are the main enablers of the automation processes related to Semantic Web services. Third, in the top-right corner, light-weight processes and mash-ups are shown that are the basis for the definition and execution of composed services. Both, mash-ups and semantic descriptions of service compositions are published to the globally distributed and shared Semantic Spaces infrastructure, and become a public good for automated large-scale service computing.{children:excerpt=true}