VEC-Hub Architecture

The Virtual Enterprise Collaboration Hub, VEC-Hub, Concept specifies how a number of “services” provide collaborative and shared data functionality to a set of partners working together [1]. The VEC-Hub is defined to be a neutral, partner managed platform and a core concept to realise this without specifying details about which application/ system/tool is providing it, is the use of W3C’s
Web Services [2].

Vec-Hub Logical Architecture

The VEC-Hub is a Service Oriented Architecture (SOA) which is a paradigm describing how to organize and utilize distributed capabilities that may be under the control of different ownership domains.
Visibility, interaction, and effect are key concepts for describing the SOA paradigm [3]:

• Visibility refers to the capacity for those with needs and those with capabilities to be able to see each other;
• Interaction refers to the activity of using a capability;
• Effect refers to the return of information or the change in the state of entities (known or unknown) that are involved in the interaction.

The SOA paradigm does not itself address all the concepts associated with ownership, ownership domains and actions communicated between legal peers. To fully account for concepts such as trust, business transactions, authority, delegation, etc., additional conceptual frameworks and architectural elements are required.
The VEC-Hub specialises the SOA paradigm by defining:

• VEC-Hub Portal services – providing access management and security management to ensure control over services, and service management to provide visibility of and interaction with services;
• VEC-Hub Core services – providing services described and accessed in a standardized way enabling partners to share product data, organizational data, reference data and processes, including workflows;
• Supplementary services – providing the means to enable access to services outside of the core set yet complying with the interface requirements for the VEC-Hub. An example is partner supplied services that enable partners to open an on-line interface into their own internally running processes and data storage while maintaining control of the access and usage of those services;
• Standardized interfaces – providing one standardized Application Programmable Interface for applications to access the VEC-Hub services and one Graphical User Interface to enable access the VEC-Hub services using commodity tools like a web-browser.

Figure 1. The VEC-Hub logical architecture separates the
infrastructure from the actual services interface.

The logical architecture, which can be seen as a classical
multi-tier architecture, is divided into four layers:

• Presentation layer: providing a secure interface to the VEC-Hub where the VEC-Hub services are exposed;
• Business layer: organizing all the services provided by the VEC-Hub, i.e. providing the visibility of the services along with the Presentation layer;
• Messaging middleware: mediating the communication between the services interfaces in the Business layer and the corresponding infrastructure in the Data and Infrastructure layer, i.e. enabling the interaction with the service;
• Data and infrastructure layer: hosting the networks and applications, etc., necessary for storing data and executing services, i.e. delivering the effect of a service.

By separating the service interface in the Business layer from the actual infrastructure, which delivers the effect of a service in the infrastructure layer, the VEC-Hub Architecture enables agile addition, removal and swapping of service providers. This requires two things:
The description of the service needs to be represented in a standardized way. For the VEC-Hub WSDL is used for describing the services.
The service interface needs to be standardized for the capability that it represents. For access to and handling of product data the PLCS Web Services interface [6] is used in the VEC-Hub Core Services.

Web Service Technology Benefits

Main benefits achieved by using web service technology:

• Standards-based – Web services are built upon standard protocols with universal support, such as XML (eXtensible Markup Language), WSDL (Web Services Description Language) and HTTP (Hypertext Transfer Protocol);
• Loosely coupled – A number of systems can be dynamically connected only when needed, which leads to increased modularity and flexibility in complex and distributed environments. Loosely coupled also have the positive effect that Web Services and the programs that invoke them can be changed independently of each other, without requiring a redesign of all involved components;
• Encapsulated – The actual implementation of the web service is invisible from outside the web service. Its functionality is known only by the interface it exposes, this also protects internal data and methods
  used to produce service results;
• Interoperability – A web service layer can be used to eliminate the long-standing friction between heterogeneous systems and platforms;

Figure 2: By the use of web services an abstraction layer
is provided between the service provider and service consumer

• Reuse – Web services provide the functionality of service reuse, not reuse as of copying of code / implementation. One service might be utilized by several clients, all of which employ the operations provided to fulfil different business objectives. Instead of having to create a custom service for each unique requirement, portions of a service can simply re-used as necessary. This facilitates greater standardization, reducing costs, with no loss of flexibility;
• Contracted – A web service’s behaviour, how to connect to as well as its input and output parameters, are available to its potential consumers.

Vec-Hub Access Patterns

There are different ways of accessing the services in the VEC-Hub. A person would access the VEC-Hub through the Graphical User Interface, GUI, while an application, like a workflow engine, would access the VEC-Hub through the Application Programming Interface, API.

• Manual interaction using the GUI to access VEC-Hub core services – this interaction provides simple web browser access to a VEC-Hub without the need for any specific client application software. Typically this type of interaction will make the Product
  data services accessible, red-dotted area in Figure 3;
• Application interaction using the API to access VEC-Hub core services – this interaction utilizes a standardised interface, i.e. Web Service interface, for applications to access the core services offered by a VEC-Hub. Typically this type of interaction will make the VEC-Hub Core services visible, blue-dotted area in Figure 3;
• Application interaction using the API addressing a supplementary service – this interaction utilizes a standardized interface, i.e. Web Service interface, for applications to access the supplementary services offered by a VEC-Hub. Typically this type of interaction will make all the VEC Hub Partner Supplied Services visible, green-dotted area in Figure 3.

References

[1] VEC-Hub dissemination portal:
[2] W3C Web Services:
[3] OASIS Reference Model for Service Oriented Architecture
V 1.0 : http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf
[4] VIVACE origin:
[5] VIVACE public results :
[6] OASIS: http://www.oasis-open.org/committees/plcs