1,047 research outputs found

    An Autonomous Engine for Services Configuration and Deployment.

    Full text link
    The runtime management of the infrastructure providing service-based systems is a complex task, up to the point where manual operation struggles to be cost effective. As the functionality is provided by a set of dynamically composed distributed services, in order to achieve a management objective multiple operations have to be applied over the distributed elements of the managed infrastructure. Moreover, the manager must cope with the highly heterogeneous characteristics and management interfaces of the runtime resources. With this in mind, this paper proposes to support the configuration and deployment of services with an automated closed control loop. The automation is enabled by the definition of a generic information model, which captures all the information relevant to the management of the services with the same abstractions, describing the runtime elements, service dependencies, and business objectives. On top of that, a technique based on satisfiability is described which automatically diagnoses the state of the managed environment and obtains the required changes for correcting it (e.g., installation, service binding, update, or configuration). The results from a set of case studies extracted from the banking domain are provided to validate the feasibility of this propos

    Supporting Semantically Enhanced Web Service Discovery for Enterprise Application Integration

    Get PDF
    The availability of sophisticated Web service discovery mechanisms is an essential prerequisite for increasing the levels of efficiency and automation in EAI. In this chapter, we present an approach for developing service registries building on the UDDI standard and offering semantically-enhanced publication and discovery capabilities in order to overcome some of the known limitations of conventional service registries. The approach aspires to promote efficiency in EAI in a number of ways, but primarily by automating the task of evaluating service integrability on the basis of the input and output messages that are defined in the Web service’s interface. The presented solution combines the use of three technology standards to meet its objectives: OWL-DL, for modelling service characteristics and performing fine-grained service matchmaking via DL reasoning, SAWSDL, for creating semantically annotated descriptions of service interfaces, and UDDI, for storing and retrieving syntactic and semantic information about services and service providers

    Precise service level agreements

    Get PDF
    SLAng is an XML language for defining service level agreements, the part of a contract between the client and provider of an Internet service that describes the quality attributes that the service is required to possess. We define the semantics of SLAng precisely by modelling the syntax of the language in UML, then embedding the language model in an environmental model that describes the structure and behaviour of services. The presence of SLAng elements imposes behavioural constraints on service elements, and the precise definition of these constraints using OCL constitutes the semantic description of the language. We use the semantics to define a notion of SLA compatibility, and an extension to UML that enables the modelling of service situations as a precursor to analysis, implementation and provisioning activities

    Progress of Library Management Softwares: an Indian Scenario

    Get PDF
    This paper discusses the development of library management softwares over the past decades, traces out the characteristics and trends of softwares with special reference to packages available in Indian environment and compares services and facilities incorporated in library automation packages available in India against various checklists and with the help of tables and appendices

    A Cloud-Edge Orchestration Platform for the Innovative Industrial Scenarios of the IoTwins Project

    Get PDF
    The concept of digital twins has growing more and more interest not only in the academic field but also among industrial environments thanks to the fact that the Internet of Things has enabled its cost-effective implementation. Digital twins (or digital models) refer to a virtual representation of a physical product or process that integrate data from various sources such as data APIs, historical data, embedded sensors and open data, giving to the manufacturers an unprecedented view into how their products are performing. The EU-funded IoTwins project plans to build testbeds for digital twins in order to run real-time computation as close to the data origin as possible (e.g., IoT Gateway or Edge nodes), and whilst batch-wise tasks such as Big Data analytics and Machine Learning model training are advised to run on the Cloud, where computing resources are abundant. In this paper, the basic concepts of the IoTwins project, its reference architecture, functionalities and components have been presented and discussed

    Influencing the run-time behaviour of complex services using contexts

    Get PDF
    Service oriented architecture (SOA) and web services make it possible to construct rich and complex distributed systems which operate at internet scales. However, the underlying design principles of SOA can lead to management problems for processes over web services. This thesis identifies several potential problems with the management of processes over web services, and proposes the use of explicit context as a possible solution. The available options are explored, and the WS-Context specification is implemented and evaluated. The SOA design principles of loose coupling, interaction at an interface, autonomy, and composablity can lead to management problems for processes over web services. Processes over web services where one composite service invokes other composite services which in turn invoke other composite services can lead to complex invocation trees. These invocation trees may be different at different times due to the shifting effect of loose coupling, as new services are swapped in to replace those in previous invocations. In such an environment how well can we define the interface of the top level service in a static document such as a WSDL? Because there is a separation between the ultimate service consumer, and the ultimate service provider how can the service consumer correctly assign fault when a service fails? When concurrency is used, and encouraged, how can we deal with the inevitable race conditions and deadlock? In distributed systems where portions of processes execute on systems beyond our organizational control, how can we pause, or kill these processes? Many of these systems model long-running business processes. How do we communicate changes in process requirements? The use of an explicit context is a potential solution to these types of problems. The abstraction context provides an environment in which the process participants can describe their requirements, query those of other process participants, and react to changes in the environment. A sample context server, based on the WS-Context specification, was implemented using the Erlang language. The sample context server provides the basic operations required to manage and store contextual information about a process. The sample context server was evaluated to determine the cost of employing a context as part of a web service based software system. The performance of the sample server was also evaluated. Test were conducted on the time costs of the basic operations of the context server, and they were found to have a constant time cost. The operations for getting and setting the contents of the context were found to have a time cost dependant on the size of the context. The cost of propagating the context along a chain of service invocations was tested and found to have an overhead which increased linearly with the length of the service invocation chain. The context server was stress tested using a closed loop test which simulated the interaction of a number of concurrent clients, and an open loop test which simulated bursts of arriving requests. The open loop testing showed that the context server could handle 75 concurrent clients. Beyond 75 concurrent clients, the response times of the context server began to slowly increase. The closed loop testing showed that the context server had a maximum throughput of 190 requests per second for bursts of 200 requests with an interarrival time of 4 milliseconds
    corecore