Background
Background
“Web Services – The Basic Idea”
A basic, 2-page primer on Web Services and Service-oriented computing
“Software Services Lifecycle Primer”
A short background on software service specification, configuration, deployment, monitoring, and management
“Web Services”
A thorough review of Actors, Participants and Interactions
Architecture
Motivation
Limitations of the Current Web Services Model
Limitations of the Current Web Services Model
Limitations of the Current Web Services Model
Two central limitations in the Web Services model negatively affect all stages of the Web Service lifecycle.
Firstly, the Web Service addressing model is rigid and only suited to highly reliable networked environments with highly reliable hosts. It does not take into account the intrinsic dynamism and fallibility of hosts on the Internet, and applications which aim to be robust to the failure of hosts become littered with failure-recovery code.
Secondly, an over-burdened and under-specified Service Provider role has led to the development of proprietary deployment systems and closed-world environments where the use of Web Services is only incidental. Saddled with these two drawbacks, the wide adoption of the Web Services model has resulted in a landscape of software services that is highly populated by applications which expose Web Service interfaces, but which are largely incompatible in terms of their required deployment systems and hosting environments.
Conviction
Our work is driven by the conviction that isolating the tasks and separating the concerns of participants in a distributed Web Services framework allows for abstractions over location and technology which enable the provision of pervasive Web Services which can be reliably addressed, bound to, and utilized, at any time and from any location.
Further, it is proposed that mechanisms can be developed to provide reliability and reduce complexity for users of Web Services, and that these mechanisms can be equally applicable to static, homogeneous computing environments as to dynamic environments composed of heterogeneous Web Service implementations and Web Service-hosting technologies. [S2]
Current Downsides for Service Providers
The Service Provider role, as currently defined, involves high cognitive complexity and has high barriers to entry, discouraging participation by individuals due to the cost and complexity involved in fulfilling all the responsibilities of the role. It is argued that the Service Provider task list is too long, incorporates too broad a set of fields, and necessitates a significantly greater amount of domain-specific knowledge than should be required of any one actor. A modularization of the service provider role into multiple sub-roles, specifying their responsibilities, and defining concrete interfaces for interacting with them, will allow the sub-role tasks to be automated, outsourced or replaced within their environment – enabling service providers to progressively and transparently mature their systems and lowering the barriers to participation in the provision of Web Services.
This work rests on the belief that the traditional Web Service model has many entangled concerns which are in fact distinct, independent tasks. Implementing the business logic of a Web Service, for example, is very different from hosting a Web Service, requires a completely different skill-set, and a completely different set of software and hardware technologies. Similarly, while Web Services are developed for particular application servers (software applications which expose interfaces to Web Services’ operations) the consideration of the target application server is very different from the tasks of preparing a host environment and deploying an instance of the Web Service – and even further removed from the decision of when and where a Web Service should be deployed.
Current Downsides for Application Developers
From the point of view of application developers, it is argued that the task of implementing the business logic of an application is different than handling Web Service implementation- and distribution-related errors, and that a mechanism should be developed which abstracts over the location of a service while still preserving the current Service Consumer actor’s view upon the system – factoring out redundant failure detection and recovery code while maintaining compatibility with existing client applications.
It is argued that the rigid addressing model forces the entanglement of application business logic with remote-invocation failure recovery techniques, is detrimental to the usability and reliability of applications, adds significant time and complexity to the creation of client applications, and is a serious drawback to the adoption of the existing Web Services model. It is also argued that the over-burdened and under-specified Service Provider role has fostered the development of progressively insular, closed-world environments composed of Web Services and client applications for which the use of Web Services is only incidental. It is finally argued that the goals of universal interoperability, loose-coupling and platform-independence espoused by Web Services and service-oriented computing are worthwhile goals, that they are currently undermined by the traditional Web Services model, and that a new, next-generation model can be developed which better facilitates the realization of these goals.
Requirements
Requirements
Limitations of the Current Web Services Model
This section defines a set of requirements that a next-generation architecture must meet, based on the previously-identified drawbacks of current approaches. These requirements aim to encourage a separation of concerns between participants in the architecture, to advance the creation of mechanisms which can accommodate heterogeneous technologies, and to promote the development of architectures which are resilient to various types of failure. Although some of the existing architectures address some of the individual requirements, the satisfaction of this complete set of requirements is unique to this next-generation model.
Architecture
Architecture
Based on the previously defined Requirements, the following page describes ActiveAether: a next generation architecture for web services on the internet including patents and high-level architectural review. To request more detail click here.
U.S. Patent 1
U.S. Patent #9,055,026
“Systems and Methods for the Demand-driven Deployment of Location-neutral Software”
Techniques for providing and consuming web services, including a service library configured to store one or more web services and a host directory connected to service hosts, configured to store data related to the service hosts. The service hosts are a network and adapted to receive and fulfill deployment requests for the web services stored in the service library by instantiating one or more endpoints of one of the web services. A manager is configured to query the host directory and the service library, generate a deployment plan, and transmit deployment requests to the one or more service hosts.
Priority: September 20, 2011
31 Claims (5 Independent)
Issued: US,EU,CN,IN,JP + others
U.S. Patent 2
U.S. Patent #9,542,466
“Systems and Methods for Distributed Storage”
Techniques for distributed storage using a plurality of computing devices connected to a network can include storing an electronic file in a local storage layer of one of the computing devices. The stored electronic file can be asymmetrically transmitted, in portions, over the network to other computing devices to store the file across the other computing devices in a distributed storage layer. The electronic file can be asynchronously transmitted over the network to a cloud storage layer such that the electronic file is mirrored in the cloud storage layer. The local storage layer of each computing device can store, for each electronic file stored in the distributed storage layer, metadata having pointers to locations of the portions the electronic files stored in the local storage layer and distributed storage layer. The electronic files stored in the distributed storage layer can be displayed as stored in a single logical drive.
Priority: April 10. 2012
24 Claims (3 Independent)
Issued: US,EU,CN,IN,JP + others
ActiveAether: A Next-generation Architecture for Web Services on the Internet
The model belongs to a class of architectures defined by their use of abstraction layers between various stages of the traditional process of Web Service deployment, location, binding and use for the purpose of introducing further functionality or desirable properties, such as reliability and scalability. The presented model takes an end-to-end or ‘holistic’ approach to addressing the previously-identified shortcomings of the traditional Web Services model. It also reduces complexity for participants in the Web Service lifecycle by partitioning the responsibility of providing a Web Service into multiple independent roles, reducing the amount of overlapping domain-specific knowledge required by each actor and lowering the barriers to participation in a distributed Web Services framework. Once decomposed, the tasks and responsibilities are re-structured and assigned to independent and autonomous functional entities, creating a loosely-coupled modular architecture which itself embraces the ideals of service-orientation.
The presented model also represents a break from the traditional approach to Web Service deployment by separating service substantiation from realization. Rather than being deployed explicitly, Web Service implementations are published into the infrastructure – with potentially many implementations of the same service. Hosts register their willingness to host Web Services, describing their available resources and joining a shared pool of latent hosting resources. The reference implementation utilizes this separation by applying the latent hosting resources to dynamically deploy Web Service endpoints as necessary to meet varying levels of demand. When usage levels drop, rarely-used Web Service instances are undeployed automatically in order to re-claim resources; aside from a passive bootstrapping process, an infrastructure with no demand will consume no hosting resources.
Service invocations are performed upon a client-side daemon - an indirection mechanism which transparently locates, binds to, and invokes Web Service operations on behalf of the user. The mechanism programmatically detects and recovers from endpoint failure, requesting a new endpoint from the infrastructure which returns an existing alternate or deploys a new one on demand. The model defines a failure model which, after exerting a ‘best effort’ to fulfill the request, returns users only non-recoverable errors which indicate that it is simply not possible to fulfill the request given the current state of the infrastructure.
ActiveAether eases the creation and publication of Web Services by consuming deployment and management tasks. It eases the use of Web Services by letting clients program against what a service does, not where it is or whether it is currently deployed. It extends the platform-independent ethos of Web Services by providing deployment mechanisms which can be used irrespective of implementation and deployment technology. Crucially, it maintains the Web Service goal of universal interoperability, preserving each actors’ view upon the system so that existing users and hosts can participate without any modifications to service implementation or client application code.
For more read here:
A Next Generation Architecture for Web Services on the Internet