Architectural pattern for service collaboration

The aim of this paper is to propose a modeling framework, tailored to build efficient, elastic and autonomous applications from tasks and services. It includes integrated services to develop the software products, reusing on demand in-house services with specific requirements and flexible the representational state transfer (REST) services. The idea is to decouple authorization for reduced service dependency and to provide a possibility for developing the whole application by increasing the existing application flexibility. Based on the fact that there are different web application platforms that serve to offer services to users but they are not integrated; we propose a framework with high flexibility degree, especially integrating the most used services such: e-learning, administrative, and library services, as University services are concern. This is an open access article under the CC BY-SA license.


INTRODUCTION
The new economy is marginalizing the value of legacy software applications.Traditional software involves significant up-front acquisition costs and requires recurring maintenance and support.Organizations soon find that while traditional software can be customized, it often leads to version-lock and the inability to preserve changes through an upgrade.Simple upgrades become costly, resource-intensive reimplementation projects [1].The discipline of service integration is quite new and in the focus of many research groups in different institutions and around the world.It is presented during different software's and application implementations and the idea come for something new, innovative, and contemporary around the world.In addition, it offers a new possibility of implementing web applications reusing existing applications providing data accessibility of existing applications without having to request permission from the systems administrators within the company.
The traditional e-services (applications), (such university services) as our case study are different web application platforms that serve to offer services to users but they are not integrated.They are isolated in psychical and business process aspects, and require specific authorization for rebuilding.In addition, the existing system has several problems such as lack of mobility, accessibility, service flexibility and portability apart from the necessity of physical presence of the administrator to ménage authorization when rebuilding applications (services) is concerned.
As service integration is the biggest problematics and challenge which tends the use of software or computer system architectural principles by linking in-house services (applications) of a single organization in order to share date, exploring how we can incrementally integrate existing web applications to use the same data, by exporting all the applications as simple services.While exporting them as basic services, the next problem is service authorization.We are resolving it using our proposed framework.

13
The proposed and implemented framework provides integration of all in-house (existing) university e-services by proposing a model/framework for web based application (services) integration.This model will reuse the existing services (applications) achieving reduced service (application) dependency by decoupling authorization framework and providing integration of registered in-house services such as university services.This will lead to, increasing service flexibility; preserving stability of services (applications) and increasing portability and service (application) interoperability.The paper is composed in four sections, starts with background, proposed framework/model, its implementation/results and a conclusion.

BACKGROUND 2.1. RESTful services
Representational state transfer ful (RESTful) services are an architectural style (collection of principles), lighter than simple object access protocol (SOAP)-based web services, due to their simplicity, heterogeneity and web-based format.Entities/resources are identified by unique universal resource locator (URLs).Including how resource states are addressed and transferred over hypertext transfer-transfer protocol (HTTP) by a wide range of clients written in different languages.A RESTful design constrains web architecture for the purpose of simplifying usage, development, and deployment to the web.Firstly, this design requires the use of a client-server architecture that separates the user interface from the data storage concerns, and the biggest benefit is that development of components can proceed independently.The stateless constraint requires application state to be maintained exclusively by the client [2].
The REST architectural style contrasts the remote procedure call (RPC/SOAP) architectural style, since the great advantage of the REST, compared to other web services technologies, is that the message exchanged is transmitted directly over the HTTP protocol without encapsulation need and without use of envelopes.In this architecture, the focus is on resources and not on the call to the procedure/service.This approach is interesting for applications where the focus on interoperability is greater than the formal contract between the parties [3].Fielding [4] REST architectural style describes six constraints which define the basis of RESTful-style: i) the uniform interface is the interface between clients and servers, simplifying the architecture, enabling each part to evolve independently; ii) stateless, as the key of REST services, refers to the necessary state to handle the request whether as part of the uniform resource identifier (URI), querystring parameters, body, or headers; iii) cacheable, as clients cache responses, eliminating some client-server interactions further improving scalability and performance; iv) client-server-clients not concerned with data storage, which remains internal to each server, so that the portability of client code is improved and servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable; v) layered system-a client cannot ordinarily tell whether it is connected directly to the end server or to an intermediary along the way and code on demand; and vi) the optional constraint [5].
These operations are defined directly in the HTTP method and are also known as HTTP verbs.In the literature, there is a common association with the acronym create, retrieve, update, and delete (CRUD) which means creates (POST), read (GET), update (PUT), and delete (DELETE).Create to add new entries, read to retrieve existing entries, update to update existing entries and delete to remove entries [3].

RESTful service components
RESTful service includes the following components: i) RESTful service provider, it is the software system that processes the request and provides data; ii) RESTful service client, the client that accesses the RESTful service; iii) resource, fundamental concept of RESTful service; iv) URI, the URI that identifies a domain resource; v) uniform interface, simplifies and decouples the architecture as a fundamental part to the design of any REST service; and vi) HTTP, RESTful systems communicate over HTTP verbs (GET, POST, PUT, and DELETE).

PROPOSED ARCHITECTURAL PATTERN
Since all REST traffic is HTTP using the standard operations, it is easy to view the data returned by the services using a web browser, which is very useful when debugging.In addition, the short development time and large freedom when coding, allows for a short time span from idea to implemented system as an important factor [6].The idea is to integrate the existing services by exporting applications as basic services using open authorization (OAuth 2.0) [5], [7]- [11] and REST services with the aim of resolving service authorization since while exporting applications as basic services the next problem that needs to be resolved is service authorization.Using our proposed framework clients will request access token using its client credentials when the client is requesting access to the protected resources under its control.

velopment time and large freedo
when coding, allows for a short time span from idea to implemented system as an important factor [6].The idea is to integrate the existing services by exporting applications as basic services using open authorization (OAuth 2.0) [5], [7]- [11] and REST services with the aim of resolving service authorization since while exporting applications as basic services the next problem that needs to be resolved is service authorization.Using our proposed framework clients will request access token using its client credentials when the client is requesting access to the protected resources under its control.

A client application will need a separate token for each service it accesses.Otherwise, a service might misuse the clients token to access another service for which only the client has been authorized.Another service may also be co A client application will need a separate token for each service it accesses.Otherwise, a service might misuse the clients token to access another service for which only the client has been authorized.Another service may also be considered as a client application (clients are also services) [2], [6], [12]- [14].Each service should provide a possibility for developing the whole application before even being given any permission.Once the application has been tested, then we may require the permissions and switch to the real endpoints, with these steps: i) endpoints should be versioned for greater flexibility.It should be possible to deploy newer versions without affecting the existing services; ii) discuss the scaling (load balancing and similar) issues.Leaving this responsibility to the services it might be more flexible; iii) the proposed sequence of execution is narratively explained in the steps below and further graphically represented in the diagram in Figure 1; iv) the client(s) requires tokens to the coordinator for accessing one service (or more services); v) the coordinator generates tokens (and saves them) and returns them to the client.One token is valid for one client, for many services, as defined in the roles list of the coordinator; vi) the client makes a request to a service using the token he has received for that service from the coordinator; and vii) before granting the execution to the client, the service verifies the token by calling the coordinator.
sidered as a client application (clients are also services) [2], [6], [12]- [14].Each service should provide a possibility for developing the whole application before even being given any permission.Once the application has been tested, then we may require the permissions and switch to the real endpoints, with these steps: i) endpoints should be versioned for greater flexibility.It should be possible to deploy newer versions without affecting the existing services; ii) discuss the scaling (load balancing and similar) issues.Leaving this responsibility to the services it might be more flexible; iii) the proposed sequence of execution is narratively explained in the steps below and further graphically represented in the diagram in Figure 1; iv) the client(s) requires tokens to the coordinator for accessing one service (or more services); v) the coordinator generates tokens (and saves them) and returns them to the client.One token is valid for one client, for many services, as defined in the roles list of the coordinator; vi) the client makes a request to a service using the token he has received for that service from the coordinator; and vii) before granting the execution to the client, the service verifies the token by calling the coordinator.

Figure 1 represents the sequence diagram [15], where the client initiates the request to the centralized coordinator for service access.The client includes its client identifier, requested service and the local state.The coordinator authenticates him and sends him back, once access is granted (or denied), based on the request.In order to speed up the step 4 and avoid multiple calls to the coordinator, the service can also locally cache the token lifetimes, thus allowing multiple requests by client without invoking the coordinator at all.Firstly all services should be registered to the coordinator in order to get access token for authentication.


Coordinating services

The proposed authorization flow between two communicating services and the coordinator handling the authorization between them is defined below.Note that in this architecture, the trusted party is the coordinator and e Figure 1 represents the sequence diagram [15], where the client initiates the request to the centralized coordinator for service access.The client includes its client identifier, requested service and the local state.The coordinator authenticates him and sends him back, once access is granted (or denied), based on the request.In order to speed up the step 4 and avoid multiple calls to the coordinator, the service can also locally cache the token lifetimes, thus allowing multiple requests by client without invoking the coordinator at all.Firstly all services should be registered to the coordinator in order to get access token for authentication.

Coordinating services
The proposed authorization flow between two communicating services and the coordinator handling the authorization between them is defined below.Note that in this architecture, the trusted party is the coordinator and each service delegates its authorization concerns to the coordinator.As a prerequisite, each service should be registered in the coordinator.We leave out the aspects of registration and generation of authentication credentials, since these aspect are not relevant to the coordination.The only important aspect is that each service disposes its own credentials which are used to authenticate the service when it accesses the coordinator.We illustrate this authentication using basic authentication principles, but any relevant authentication method can be used in this context.In addition, tokens and similar data are abbreviated for easier reading.a.In order to access a resource, the client services (A) need to acquire a token from the coordinator.Since the access to each service requires a separate token, the service for which we require a token should be specified in the request.c.If the service 1 (A) is not authorized for specific service that was requested, the response will be as follows:

h service delegates it
authorization concerns to the coordinator.As a prerequisite, each service should be registered in the coordinator.We leave out the aspects of registration and generation of authentication credentials, since these aspect are not relevant to the coordination.The only important aspect is that each service disposes its own credentials which are used to authenticate the service when it accesses the coordinator.We illustrate this authentication using basic authentication principles, but any relevant authentication method can be used in this context.In addition, tokens and similar data are abbreviated for easier reading.a.In order to access a resource, the client services (A) need to acquire a token from the coordinator.Since the access to each service requires a separate token, the service for which we require a token should be specified in the request.c.If the service 1 (A) is not authorized for specific service that was requested, the response will be as follows:

HTTP/1.1 403 Forbidden ... { "reason": "Access to this service is not allowed " } d.After having retrieved a valid token, service 1 (A) requires a resource from the service 2 (B) by authenticating using the previous token:

POST /courses HTTP/1.1 Authori HTTP/1.1 403 Forbidden ... { "reason": "Access to this service is not allowed " } d.After having retrieved a valid token, service 1 (A) requires a resource from the service 2 (B) by authenticating using the previous token: POST /courses HTTP/1.1 Authorization: Token 802057ff762hdk3936... ... { "code": 1234, "name": "Service Oriented Applications", ... } e.The service 2 (B) validates the token by calling the coordinator, together with information about the concrete required resource.
ation: Token 802057ff762hdk3936... ... { "code": 1234, "name": "Service Oriented Applications", ... } e.The service 2 (B) validates the token by calling the coordinator, together with information about the concrete required resource.

GET /authorization HTTP/1.1 ... { "token": "802057ff762hdk3936...", "method": "POST", "resource": "/courses" } f.It is the coordinator's responsibility to decide whether service 1 (A) is allowed to access this particular resource on service 2 (B).If not authorized, it will send back a code 403 response: i.In this case the service 2 (B) should continue with processing the original request and eventually return the corresponding res GET /authorization HTTP/1.1 ... { "token": "802057ff762hdk3936...", "method": "POST", "resource": "/courses" } f.It is the coordinator's responsibility to decide whether service 1 (A) is allowed to access this particular resource on service 2 (B).If not authorized, it will send back a code 403 response: i.In this case the service 2 (B) should continue with processing the original request and eventually return the corresponding response.

Figure 2. Coordinator REST interface-protocol
rface-protocol

As we can see in the previous flow, the coordinator can define different policies for service access.It can give permissions to a service for accessing all resources on a second service, or use a more fine-grained policy in which he associates a list of resources to be accessed for any given service.This possibility, allows permissions to be managed on a centralized level by authorized parties while developer's responsibility is reduced to calling the coordinator before As we can see in the previous flow, the coordinator can define different policies for service access.It can give permissions to a service for accessing all resources on a second service, or use a more fine-grained policy in which he associates a list of resources to be accessed for any given service.This possibility, allows permissions to be managed on a centralized level by authorized parties while developer's responsibility is reduced to calling the coordinator before each access.
each access.

A second important remark is that this flow is systematic.This allows implementing libraries for managing the authorization on specific development technologies.In this way, the development of RESTful services can be greatly simplified and reduced to declaratively importing a library.The usage of libraries further diminishes the security risks related to incorrect implementations of the above A second important remark is that this flow is systematic.This allows implementing libraries for managing the authorization on specific development technologies.In this way, the development of RESTful services can be greatly simplified and reduced to declaratively importing a library.The usage of libraries further diminishes the security risks related to incorrect implementations of the above protocol.

EVALUATION AND RESULTS
D RESULTS

As we mentioned previously, our model is implemented in university area, and as cases there are taken three university applications/services: administrator management system, learning management system, and As we mentioned previously, our model is implemented in university area, and as cases there are taken three university applications/services: administrator management system, learning management system, and e-library.

Coordinator implementation
mentation

The role of our proposed coordinator is to maintain the application keys and generate tokens as required.The coordinator will register a list of actions that each service provides.Given an endpoint, it provides a list of possible URL, with allowed HTTP verbs for each of them.The combination of the URL (pattern) and the verb may be used as a description of services and for specifying simple permissions.These tokens will be used by a client application to directly access different services.Services will verify the authenticity of tokens through the coordinator.They may also check on the coordinator whether the client has the necessary permissions to access a given action.The entity relationship diagram (ERD) shown in Figure 3.
The role of our proposed coordinator is to maintain the application keys and generate tokens as required.The coordinator will register a list of actions that each service provides.Given an endpoint, it provides a list of possible URL, with allowed HTTP verbs for each of them.The combination of the URL (pattern) and the verb may be used as a description of services and for specifying simple permissions.These tokens will be used by a client application to directly access different services.Services will verify the authenticity of tokens through the coordinator.They may also check on the coordinator whether the client has the necessary permissions to access a given action.The entity relationship diagram (ERD) shown in Figure 3.

books from
ervice (C) or e-library.In Figure 7 the implemented user interface is presented, such as, that the LMS professor panel which enables professors to see their registered students to specific course using REST architecture and our implemented framework and registered students from service (A) to service (B).


CONCLUSION

The suggested prototye promoted in this paper aimed at managing the technological needs of universities effectively, especially integrating all services in a unique platform and having stable services.The purpose was to demonstrate how to better integrate them, especially the interoperability issues between services concerning their integration reusing existing services and changing one service by not attacking the others.Using it in educational institutions will promote huge benefits such as high available services, scalability, increasing portability, performance/cost and overall reliability improvements.As REST services are a challenging task; improving the way that university services are implemented and maintained as well, in this work we have described our proposed framework to use existing services for decoupling authorization for reduced service dependency.Decoupling authorization from the actual implementation of web services simplifies their development while allowing centralized management of permissions by third party authorities.This allows for more flexibility in serv

CONCLUSION
The suggested prototye promoted in this paper aimed at managing the technological needs of universities effectively, especially integrating all services in a unique platform and having stable services.The purpose was to demonstrate how to better integrate them, especially the interoperability issues between services concerning their integration reusing existing services and changing one service by not attacking the others.Using it in educational institutions will promote huge benefits such as high available services, scalability, increasing portability, performance/cost and overall reliability improvements.As REST services are a challenging task; improving the way that university services are implemented and maintained as well, in this work we have described our proposed framework to use existing services for decoupling authorization for reduced service dependency.Decoupling authorization from the actual implementation of web services simplifies their development while allowing centralized management of permissions by third party authorities.This allows for more flexibility in service implementation and its evolution.Services can be developed and run independently, even when centralized management of permissions is a must.The implemented coordinator handles aspects of registration and authorization of services and he also provides libraries for developers to handle authorization concerns.
ce implementation and its evolution.Services can be developed and run independently, even when centralized management of permissions is a must.The implemented coordinator handles aspects of registration and authorization of services and he also provides libraries for developers to handle authorization concerns.

In this paper we present architecture (protocol) for in-house REST service coordinator for service collaboration, by exporting data as basic services (resources) through SOA approach.Using the defined protocol, resources are shared, based on the requirements, as what this paper is trying to resolve and propose.A large number of services are designed in a manner to offer closed and isolated system interface and resources due to their specific requirements they need to offer to the users.Later on, isolation consequences are considered, taking University services as a typical in-house organization that dispose many data, where students and faculty staff members need to have more freedom and access to different service resources.This is done for developers to build new services and for students and staff to achieve their course activities, duties and services that the faculty might require to apply and organize.The In this paper we present architecture (protocol) for in-house REST service coordinator for service collaboration, by exporting data as basic services (resources) through SOA approach.Using the defined protocol, resources are shared, based on the requirements, as what this paper is trying to resolve and propose.A large number of services are designed in a manner to offer closed and isolated system interface and resources due to their specific requirements they need to offer to the users.Later on, isolation consequences are considered, taking University services as a typical in-house organization that dispose many data, where students and faculty staff members need to have more freedom and access to different service resources.This is done for developers to build new services and for students and staff to achieve their course activities, duties and services that the faculty might require to apply and organize.The SOA approach, especially REST services, offer flexible service solutions, first of all by sharing the computational resources based on the service criteria's where each service delivers its power value based on the environment and the technology designed.It also develops easier and just in time solutions.

Figure 1 .
Figure 1.Proposed framework for flexible REST services-sequence diagram Figure 2 depicts the authorization flow in a case when service 1 (A) wants to access a resource in service 2 (B): Int J Inf & Commun Technol ISSN: 2252-8776  Architectural pattern for service collaboration (Agon Memeti)

Table 1 .
Service requests