Web applications are nowadays prevalent software systems in our every-day's life. A lot of these applications have been developed for end-users only. Thus, they are not designed by considering future extensions that would be developed by third parties. One possible and interesting solution for opening these applications for such kind of extension development is to create and deploy Web services starting from these applications. In this paper, we present a method and a tool for semi-automatically creating Web service implementations from applications having Web interfaces. The proposed method generates operations that are published in Web services for each functionality provided by a Web application. In addition, it generates new operations starting from Web interfaces. Our approach goes further in the creation of services by generating executable orchestrations, as BPEL processes, starting from navigations in the Web interfaces of these applications and by providing BPMN choreography specifications starting from the collaborations between the generated Web services. We implemented and experimented our solution in the migration of three realworld Web applications towards Web service-oriented systems.

A large component and service-based software system exists in different forms, as different variants targeting different business needs and users. This kind of systems is provided as a set of "independent" products and not as a "single whole". Developers use ad hoc mechanisms to manage variability. However, for deriving new product variants that are built upon existing ones, the presence of a single model describing the architecture of the whole system with an explicit specification of commonality and variability is of great interest. Indeed, this enables them to see the invariant part of the whole, on top of which new functionality can be built, in addition to the different options they can use. We investigate in this work the use of software product line reverse engineering approaches, and in particular the framework named But4Reuse, for recovering an architecture model that enables us to build a Software Architecture Product Line (SAPL), from a set of software variants. We propose a generic process for recovering an architecture model of such a product line. We have instantiated this process for the OSGi Java framework and experimented it for building the architecture model of Eclipse IDE SPL. The results of this experimentation showed that this process can effectively reconstruct such an architecture model.

A large component and service-based software system exists in different forms, as different variants targeting different business needs and users. This kind of systems is provided as a set of "independent" products and not as a "single whole". The presence of a single model describing the architecture of the whole system may be of great interest for developers of future variants. Indeed, this enables them to see the invariant part of the whole, on top of which new functionality can be built, in addition to the different options they can use. We investigate in this work the use of software product line reverse engineering approaches, and in particular the framework named BUT4Reuse, for reconstructing an architecture model of a Software Architecture Product Line (SAPL), from a set of variants. We propose a generic process for reconstructing an architecture model of such a product line. We have instantiated this process for the OSGi Java framework and experimented it for building the architecture model of Eclipse IDE SPL.

Most of the time a large software system implies a complex architecture. However, at some point of the system's execution, its components are not necessarily all running. Indeed, some components may not be concerned by a given use case, and therefore they do not consume/use or register the declared services. Thus, these architectural elements (components and their services) represent a "noise" in the architecture model of the system. Their elimination from the architecture model may greatly reduce its complexity, and consequently helps developers in their maintenance tasks. In our work, we argue that a large service-oriented system has, not only one, but several architectures, which are specific to its runtime use cases. Indeed, each architecture reflects the services, and thereby the components, which are really useful for a given use case. In this paper, we present an approach for recovering such use case specific architectures of service-oriented systems. Architectures are recovered both through a source code analysis and by querying the runtime environment and the service registry. The first built architecture (the core architecture) is composed of the components that are present in all the use cases. Then, depending on a particular use case, this core architecture will be enriched with only the needed components.

No abstract