scholarly journals On the Need for a General REST-Security Framework

2019 ◽  
Vol 11 (3) ◽  
pp. 56 ◽  
Author(s):  
Luigi Lo Iacono ◽  
Hoai Nguyen ◽  
Peter Gorski
Keyword(s):  
Service Oriented Architecture ◽  
Cloud Services ◽  
Service Systems ◽  
Message Authentication ◽  
Security Framework ◽  
Architectural Style ◽  
Representational State Transfer ◽  
State Transfer ◽  
Service Oriented ◽  
Software Services

Contemporary software is inherently distributed. The principles guiding the design of such software have been mainly manifested by the service-oriented architecture (SOA) concept. In a SOA, applications are orchestrated by software services generally operated by distinct entities. Due to the latter fact, service security has been of importance in such systems ever since. A dominant protocol for implementing SOA-based systems is SOAP, which comes with a well-elaborated security framework. As an alternative to SOAP, the architectural style representational state transfer (REST) is gaining traction as a simple, lightweight and flexible guideline for designing distributed service systems that scale at large. This paper starts by introducing the basic constraints representing REST. Based on these foundations, the focus is afterwards drawn on the security needs of REST-based service systems. The limitations of transport-oriented protection means are emphasized and the demand for specific message-oriented safeguards is assessed. The paper then reviews the current activities in respect to REST-security and finds that the available schemes are mostly HTTP-centered and very heterogeneous. More importantly, all of the analyzed schemes contain vulnerabilities. The paper contributes a methodology on how to establish REST-security as a general security framework for protecting REST-based service systems of any kind by consistent and comprehensive protection means. First adoptions of the introduced approach are presented in relation to REST message authentication with instantiations for REST-ful HTTP (web/cloud services) and REST-ful constraint application protocol (CoAP) (internet of things (IoT) services).

Enterprise Integration With the Structural Services Architectural Style

2019 ◽  
pp. 352-392 ◽  
Author(s):  
José Carlos Martins Delgado
Keyword(s):  
Service Oriented Architecture ◽  
Architectural Style ◽  
Enterprise Integration ◽  
Representational State Transfer ◽  
Advantages And Disadvantages ◽  
Architectural Styles ◽  
State Transfer ◽  
Enterprise Applications ◽  
Service Oriented ◽  
Structural Compliance

The Service-Oriented Architecture (SOA) and Representational State Transfer (REST) architectural styles are the most used for the integration of enterprise applications. Each is more adequate to a different class of applications and exhibits advantages and disadvantages. This chapter performs a comparative study between them. It is shown that SOA and REST are dual architectural styles, one oriented towards behavior and the other towards state. This raises the question of whether it is possible to combine them to maximize the advantages and to minimize the disadvantages. A new architectural style, Structural Services, is proposed to obtain the best characteristics from SOA and REST. As in SOA, services are able to offer a variable set of operations and, as in REST, resources are allowed to have structure. This style uses structural interoperability, based on structural compliance and conformance. A service-oriented programming language is also introduced to instantiate this architectural style.

Improving Application Integration by Combining Services and Resources

2019 ◽  
pp. 197-226 ◽  
Author(s):  
José Carlos Martins Delgado
Keyword(s):  
Service Oriented Architecture ◽  
Application Integration ◽  
Architectural Style ◽  
Representational State Transfer ◽  
Architectural Styles ◽  
State Transfer ◽  
Fixed Set ◽  
Service Oriented ◽  
Application Developers ◽  
Bare Minimum

The main application integration approaches, the service-oriented architecture (SOA) and representational state transfer (REST) architectural styles, are rather different in their modeling paradigm, forcing application developers to choose between one and the other. In addition, both introduce more application coupling than required, since data schemas need to be common, even if not all instantiations of those schemas are used. This chapter contends that it is possible to improve this scenario by conceiving a new architectural style, structural services, which combines services and resources to reduce the semantic gap with the applications, allowing to tune the application integration between pure service-based and pure resource-based, or an intermediate mix. Unlike REST, resources are not constrained to offer a fixed set of operations, and unlike SOA, services are allowed to have structure. In addition, compliance is used to reduce coupling to the bare minimum required by the actually used application features.

Bridging Services and Resources with Structural Services

2016 ◽  
Vol 7 (4) ◽  
pp. 83-110 ◽  
Author(s):  
José C. Delgado
Keyword(s):  
Service Oriented Architecture ◽  
Architectural Style ◽  
Representational State Transfer ◽  
Advantages And Disadvantages ◽  
Architectural Styles ◽  
State Transfer ◽  
Fixed Set ◽  
Service Oriented ◽  
Media Types ◽  
Structural Compliance

The most used approaches for distributed application integration are based on the Service-Oriented Architecture (SOA) and Representational State Transfer (REST) architectural styles. Each is more adequate to a different class of applications and exhibits advantages and disadvantages. This paper not only shows that they are dual architectural styles, SOA oriented towards behavior (services) and REST towards state (structured resources), but also contends that it is possible to combine them to maximize the advantages and to minimize the disadvantages. A new architectural style, Structural Services, is proposed and described. Unlike REST, resources are not constrained to offer a fixed set of operations and, unlike SOA, services are allowed to have structure. To minimize resource coupling, this style uses structural interoperability based on the concepts of structural compliance and conformance, instead of schema sharing (as in SOA) or standardized and previously agreed upon media types (as in REST).

Structural Services

2015 ◽  
pp. 50-91
Author(s):  
Jose Delgado
Keyword(s):  
Programming Language ◽  
Service Oriented Architecture ◽  
Semantic Gap ◽  
Architectural Style ◽  
Enterprise Integration ◽  
Representational State Transfer ◽  
Architectural Styles ◽  
State Transfer ◽  
Distributed Service ◽  
Service Oriented

This chapter compares the Service-Oriented Architecture (SOA) and Representational State Transfer (REST) architectural styles and contends that both have advantages and limitations for enterprise integration. SOA, based on behavior, has a lower modeling semantic gap for complex applications but lacks support for structured resources common in lower-grained applications. REST is based on structure and hypermedia but has a higher semantic gap in complex applications and, as this chapter contends, does not entail a lower resource coupling than SOA. A new architectural style, Structural Services, is proposed to get the best of both worlds, while reducing coupling with structural interoperability based on the concepts of compliance and conformance. Unlike REST, resources are able to offer a variable set of operations, and unlike SOA, services are allowed to have structure and use hypermedia. A distributed service programming language is briefly described to illustrate how this architectural style can be instantiated.

Beyond SOA and REST for Distributed Application Integration

2018 ◽  
pp. 228-257
Author(s):  
José Carlos Martins Delgado
Keyword(s):  
Service Oriented Architecture ◽  
Fundamental Problem ◽  
Application Integration ◽  
Distributed Application ◽  
Representational State Transfer ◽  
Architectural Styles ◽  
State Transfer ◽  
Service Oriented ◽  
Structural Compliance ◽  
Application Specific

The fundamental problem of distributed application integration is reducing application coupling as much as possible while still meeting the minimum interoperability requirements. Service-oriented architecture (SOA) and representational state transfer (REST) are the most used architectural styles to deal with this problem. This chapter performs a comparative study of these styles and shows that, while both solve basic interoperability, neither of them minimizes coupling, since data description schemas are shared by the interacting applications (symmetric interoperability). SOA is oriented towards behavior (services) and REST towards state (structured resources). Services have no structure and resources have a fixed service. This chapter proposes a new architectural style, structured services, that combines the best characteristics of SOA and REST (services can have structure and resources can implement application-specific services), while using asymmetric interoperability (schema compatibility is based on structural compliance and conformance) to minimize application coupling.

A Theoretical Foundation of Demand Driven Web Services

2015 ◽  
pp. 392-422
Author(s):  
Zhaohao Sun ◽  
John Yearwood
Keyword(s):  
Web Services ◽  
Social Services ◽  
Service Oriented Architecture ◽  
State Of The Art ◽  
The State ◽  
Cloud Services ◽  
Pivotal Role ◽  
The Internet ◽  
Service Oriented ◽  
The Web

Web services are playing a pivotal role in business, management, governance, and society with the dramatic development of the Internet and the Web. However, many fundamental issues are still ignored to some extent. For example, what is the unified perspective to the state-of-the-art of Web services? What is the foundation of Demand-Driven Web Services (DDWS)? This chapter addresses these fundamental issues by examining the state-of-the-art of Web services and proposing a theoretical and technological foundation for demand-driven Web services with applications. This chapter also presents an extended Service-Oriented Architecture (SOA), eSMACS SOA, and examines main players in this architecture. This chapter then classifies DDWS as government DDWS, organizational DDWS, enterprise DDWS, customer DDWS, and citizen DDWS, and looks at the corresponding Web services. Finally, this chapter examines the theoretical, technical foundations for DDWS with applications. The proposed approaches will facilitate research and development of Web services, mobile services, cloud services, and social services.

An Introduction to Service Choreographies (Servicechoreographien – eine Einführung)

2008 ◽  
Vol 50 (2) ◽  
Author(s):  
Gero Decker ◽  
Oliver Kopp ◽  
Alistair Barros
Keyword(s):  
Business Processes ◽  
Service Oriented Architecture ◽  
Global Perspective ◽  
Software Systems ◽  
Architectural Style ◽  
Service Oriented

SummaryService oriented architecture (SOA) is an architectural style for building software systems based on services. Especially in those scenarios where services implement business processes, complex conversations between the services occur. Service choreographies are a means to capture all interaction obligations and constraints from a global perspective. This article introduces choreographies as an important artifact for SOA, compares them to service orchestrations and surveys existing languages for modeling them.

Service Identification and Specification with SoaML

2012 ◽  
pp. 102-125 ◽  
Author(s):  
Michael Gebhart
Keyword(s):  
Business Processes ◽  
Service Oriented Architecture ◽  
Cloud Services ◽  
Legacy Systems ◽  
Model Driven ◽  
Service Identification ◽  
Service Oriented ◽  
Service Components ◽  
Business Process Execution ◽  
Architecture Modeling

This chapter focuses on the identification and specification of services based on prior modeled business processes and legacy systems. The resulting service interfaces and service components formalized by using the Service oriented architecture Modeling Language (SoaML) describe the integration of legacy systems into a service-oriented application landscape. The legacy systems provide services for integration purposes and represent the implementations of service components. Additionally, the resulting architecture allows functionality of legacy systems to be replaced with functionality provided by external cloud services. According to model-driven development concepts, the formalized service interfaces and service components as part of the service designs can be used to automatically derive service interface descriptions using the Web Services Description Language (WSDL). These descriptions enable the technical integration of legacy systems. If necessary, service implementations based on the Service Component Architecture (SCA) and the Business Process Execution Language (BPEL) can be generated.

Sign in / Sign up

Export Citation Format

Share Document