A metadata for Web services architecture: A framework for service-oriented software development Youcef Baghdadi Department of Computer Science, SQU, PO Box 36 – PC 123, Al-Khoud, Oman E-mail:
[email protected] Abstract — Computing paradigms such as object and component have emphasized the reuse through separation of concerns and information hiding. The concept of service is an evolution of these paradigms to emphasize loose-coupling in order to develop software as composition of reusable, loosely coupled units of software. The service-oriented computing (SOC) is working to principle the service towards the realization of service-oriented software (SOS). Meanwhile, Web services use the Internet and standards such as XML to challenge the realization of SOC. Yet, we still need a comprehensive Web services architecture that captures the properties of all the layers of the Web services stack, from wrapping, describing, deploying, registering, managing, monitoring, and discovering basic software units to recursively composing software. This work proposes a metadata for such architecture that represents the Web services with respect to four perspectives: service specification, service deployment, service as wrapper of legacy systems, and service as a unit of composition of software supporting business processes. The metadata is then used as framework and guidance for SOS development life cycle, where each perspective is considered as a level of abstraction towards the development of the SOS.
I. INTRODUCTION Design methods of software are generally devised around software architecture, namely: (i) the way software systems are structured and built from basic building blocks (or units) such as subroutine/function, object, component, and (ii) the models and mechanisms these basic units use to interconnect and communicate. These units have been principled in different computing paradigms such as structured [5]-[7]-[16], object-oriented [3]-[14], or component based [5]-[11]-[18]. The principles focus on the properties of the units, namely their expression power, the way they are defined to be identified, the different types of relationships between them, the mechanisms of their interconnection and communication, the design decisions (e.g. cohesion and coupling), and their patterns (if any). Each paradigm has made a breakthrough in challenging software development. The paradigms of subroutine/function, object, and component have emphasized reuse through mainly separation of concerns and information hiding [7][16]. Software reuse is about methods and techniques that enhance the reusability of software [5]-[11]-[18]. The concept of service [1]-[6]-[12]-[15] constitutes an evolution of these computing paradigms. It mainly
emphasizes the loose-coupling in order to develop software by composing existing, heterogeneous, reusable, loosely coupled units of software. Loose coupling means that when a software unit needs to reuse some functionality realized by another software unit, this need is separated from its realization. The software units agree on reusing each other only through a semantically defined, machine-readable contract without being concerned with their respective know-how and infrastructure. The key benefit of delivering software as service include the potential for increased business agility through loose coupling and the ability to evolve as business requirements change [9]. Web services, instances of service, use the Internet and the standards such as XML to challenge the development cost, the time to market, and the interoperability. Indeed, Web services are pervasive and have multiple usages due, namely to: (i) the machine-readable standard format (XML) of their functional and non-functional specifications), (ii) their messaging protocols built on top of the Internet protocols [6]-[13], and (iii) their ability to integrate with semantic Web [17]. However, the paradigm of service is not mature enough. It is the role of both computing and software engineering to respectively explore and apply this paradigm the same way they are doing for the other paradigms. That is, we still need a comprehensive Web services architecture (WSA) that captures the properties of all the layers of the Web services stack. Only such a Web services stack can provide guidance towards the development of an Internet, standard-based realization of SOS. This work first proposes a metadata of the WSA to sketch out its properties with respect to four perspectives, namely: (P1) service description, (P2) service deployment, (P3) service as wrapper of legacy systems, and (P4) service as a unit of composition of software implementing business processes. The metadata is then used as a framework and guidance for SOS development life cycle, including their identification, specification, description, deployment, organization and management. II. SERVICE-ORIENTED SOFTWARE SOS is hereby defined as “software composed out of building blocks or units called services, where the most
important property, in addition to their reuse, is the loosely coupled nature”. That is, when unit U1 needs functionality from another unit U2, this need is separated from its realization. Yet, the units use each other through semantically defined and agreed upon machine-readable contracts without being concerned with their respective know-how and infrastructure. A. Service Definitions A service may be defined from different perspectives. In this work, we use SOS development perspective to define a service as: “a functionality (or well-formed, aggregation of related functionality1), implemented in software system (which may be a legacy system), wrapped with a formal, well documented, semantically defined, machine-readable interface, whereby the interface is registered to be discoverable with the intention to be reused in composing other software concerned only with the outcome achieved by the functionality”. Therefore, a service represents a wrapping of a single distinct functionality so that it can be reused in composing software. Its functional and non-functional specifications are semantically defined in a standard machine-readable format, publishable, discoverable and exchangeable via communication mechanisms. B. Web Service Definitions A Web service is a special service from a software perspective, i.e. a Web service inherits all the aforementioned properties of service that are added to its specific Web/Internet related properties. The three underlying standard technologies that are: (1) Web Service Description Language (WSDL), a machinereadable standard format (XML) of their functional and non-functional specifications, (2) Simple Object Access Protocol (SOAP), a protocol based on Internet protocols such as HTTP, SMTP and FTP, and used as messaging protocol to exchange XML messages (request, response, and fault), and (3) Universal Description, Discovery Interface (UDDI), along with other technology standards such as BPEL4WS (Business Process Execution Language for Web Services) allow Web services to be loosely coupled, reusable units of composition of software. That is, Web services are software units provided by organizations, located on the Web, and accessible from any Web-connected application using a set of standard messaging protocols based on the Internet. However, to be used as a realization of the SOS that conforms to the service-oriented architecture (SOA), Web services should be comprehensibly principled, which role is dedicated to SOC. 1
This depends on the granularity of the service.
C. SOA, SOC and SOS SOA is a set of principles to re-architect the IT infrastructure emphasizing the loose coupling. SOS is software development technique mainly based on the composition of units called services and compliant with SOA. The paradigm of service is principled by the new computing paradigm that is SOC in the same manner as object is principled by object orientation (OO) paradigm. D. Web Services: Main Building Blocks of SOC SOC is intended to be a middleware for intra- and inter-enterprise applications integration [12]-[15]. In this paradigm, services become the fundamental building blocks upon which new applications are created. Services are intended to provide higher abstraction-level or a new architecture (e.g. SOA) of applications based on reuse in the context of autonomy and heterogeneity of software units to improve productivity and quality of applications Moreover, services are self-describing, open software units that support rapid, low-cost composition of distributed applications [8]-[12]-[15]. SOC is intended to provide a Web services stack and a set of principles for Web services in order to facilitate the development of SOS. However, to make SOC a middleware that provides capability such as automated discovery, dynamic selection, binding, composition, and choreography, services must satisfy the following properties: x Self-description, i.e. a service should be able to describe its public interface. It is also possible to retrieve the information from the executing service itself. Moreover, services should: (i) define the semantics of their functional (e.g. capabilities) and nonfunctional (e.g. quality of service) requirements in a machine-readable standard ontology such as XML or OWL [17], and (ii) communicate through messaging protocols built on top of the Internet protocols [6]-[13]. x Self-contained, i.e. a service can run independently of the state of any other service or any other software x Implementation hiding, i.e. a service hides its implementation so that it can change its implementation (for many reasons) without affecting its clients. x High cohesion, i.e. the degree of the functional relatedness of the functionality of the service, which increases the clarity of the design, simplifies maintenance and future enhancements, achieves services granularity; and often supports loose coupling. The service granularity can be fine or coarse grained. x Service abstraction, which should be cohesive, complete and consistent x Well-defined interfaces, i.e. service interaction must be well defined through improved WSDL. x Stateless service, i.e. which does not require information or state from the requester. That is, services
should not be dependent on the context or state of other services. x The semantics of Web services, i.e. what they do and what is the meaning of data elements they manipulate and communicate is a critical issue. The reuse of Web services must be based on the fact that Web services do the right thing to be effective. x Organization of Web services, the paradigm should provide artifacts to organize and manage [4] Web services for a very large internal and external reuse. x Management of Web service, the paradigm should provide mechanisms for management and a monitoring to enable mastering the evolution of Web services [2]-[15]. Without such mechanisms, services performance and stability will degrade, and software composed out of them will degrade. These properties facilitate: x Reuse, i.e. a service should always be specified with its reuse (in other software units) in mind in order to bring flexibility and agility to the software. x Loose coupling, i.e. the ability of a service to change its implementation without any impact on its client applications. x Interoperability, i.e. services can possibly request each other from any platform without any knowledge of how they are implemented. x Composition of software out of services is the most important objective of the paradigm of service. Therefore, services principled by SOC would be a realization of SOS if we provide techniques to: 1 Develop services mainly by wrapping candidate functionalities. Generally these functionalities exist in the legacy systems, however if some functionalities do not exist, we need to develop them as services. The services are then deployed and registered in a private/public registry. 2 Check the compliance of the wrapped Web services with the SOC principles. 3 Compose software out of the deployed and registered services principled by SOC. The aforementioned properties can be summarized by a metadata for Web service architecture (WSA).
from their generation, notably by wrapping existing software units, verification of specification, and deployment to their reuse in composing new software. For a WSA metadata (Fig. 2 in the next page) to be used as a framework and guidance towards the development of SOS that emphasizes the wrapping and composition techniques, it needs to capture the properties of the Web services (WS) from different perspectives, namely: (P1) WS description and specification (P2) WS deployment (P3) WS as wrappers of legacy systems (P4) WS as units of composition of software implementing business processes (BP)
III. METADATA FOR WEB SERVICES ARCHITECTURE
Fig. 1. WS: Specification Perspective.
A. WS: Specification Perspective The description and specification of a Web service should be specified with a language that is readable by machine. It concerns with: (a) the functional and non-functional requirement of the Web service, i.e. what functionality a Web service provides, (b) the communication style, i.e. how it communicates, and (c) its locations on the Web, i.e. where to find it. Accordingly, a description language such as WSDL expresses three distinct parts as shown in Table 1 and sketched out in the UML diagram of Fig. 1 (a subset of the metadata described in Fig. 2): (1) the abstract part expresses the functionality, (2) the concrete binding part expresses the communication, and (3) the implementation part expresses the location of the service. WSDL
Abstract part
Binding Part
Type
Implementation Part
-data type
Port Type -name
Binding
Part
output
-name
1..* Port
Message -name
Service
-name -XML encoding -protocol -message struct -header block
-name
fault
Operation
implements
-name input
The WSA metadata, described in this work, is intended to summarize the Web services as pieces of software TABLE I THE THREE PARTS OF WS Part Abstract Interface
Concrete Binding Implementation
Aspect What Functionality? How to communicate? Where Is it located?
Content
Relationship between parts //
Includes the Abstract Interface Includes Concrete Binding
-name -URI
Standalone
Web server
Application server
WS Deployment perspective Business Process Composition
Running server
Web services server +generate WSDL() Business Process
WS Container
Wrapping perspective
+manage lifecycle() runs inside
Database Client
Proxy
Web service
System
Legacy
-name -language SOAP engine
Application +process message() +generate proxy() +convert() +route()
UDDI +register() +find()
WSDL WS Description Perspective
Implementation Part Abstract part
Binding Part
Type -data type
Service -name Port Type -name Part 1..*
Binding
-name
-name -XML encoding -protocol -message struct -header block
output Message -name
fault
Port
implements
-name -URI
Operation -name
input
Fig. 2. UML Class diagram for WSA summarizing the four perspectives.
B. WS: Deployment Perspective
D. WS: Perspective of Composition of Software for BP
The UML diagram of Fig. 3 is a subset of the metadata that distinguishes the Web services deployment perspective. Web services are deployed within a Web services server, i.e. the run-time server. A Web service server can run standalone, a Web server, or within an application server provided by an environment such as J2EE or .NET. A Web services server consists of a Web service container that manages the life cycle of the application implementing the services, and a SOAP processor that processes the exchanged messages.
Reusability is one of the major properties of Web services since services can be reused instead of being rewritten in the Web service environment. Therefore WSA can be viewed from a usage point of view to provide a flexible software composition implementing business processes. The UML diagram of Fig. 5 is a subset of the metadata that distinguishes the Web services composition perspective, where software implementing business process is presented, with respect to SOA, as consumer (client) of Web services registered in a registry (UDDI) by provider. The consumer and provider of Web services use SOAP to communicate with each other.
Standalone
Web server
Application server
Business Process
WS Container Running server +manage lifecycle() runs inside
Proxy Web service
Client
-name -language Web services server +generate WSDL()
Web service -name -language
Fig. 3. WS: Deployment Perspective.
C. WS: Legacy Systems Wrapping Perspective In SOS development, designing and developing a service mainly consists of wrapping candidate functionalities. Generally these functionalities do exist in the legacy systems, however if some functionality do not exist, we need to develop them as services. These services are then registered in a private/public registry. The majority of software applications that made up the enterprise is already built and considered as legacy software applications. These software applications are still in use and need to communicate with distributed heterogeneous applications. The UML diagram of Fig. 4 is a subset of the metadata that distinguishes the Web services wrapping perspective.
Fig. 4. WS: Wrapping Perspective.
SOAP engine UDDI +register() +find()
+process message() +generate proxy() +convert() +route()
Fig. 5. WS: Composition Perspective.
The metadata for WSA provides guidance towards SOS development mainly based on three techniques: (1) Wrapping of legacy systems into Web services. (2) Checking the compliance of the wrapped Web service with the SOC principles (3) Composing service-oriented software out of the Web services. IV. SERVICE-ORIENTED SOFTWARE DEVELOPMENT In addition to the WSA metadata that highlights properties of the main building of SOA, the development strategy includes: (1) Guidance architecture (with multiple interfaced, abstraction levels) that decouples the technologyindependent usage of Web services from their technology-dependent deployment. The higher levels allow a specification of Web service requirements, usages, and building blocks from the business model with respect to a development strategy independently of any technology platform, which allows: (i) alignment of the IT with the business, (ii) guided development process, (iii) decision making regarding the suitable and adequate implementing technology, and (iv) set of cohesive, loosely coupled, well-interfaced, and well-organized Web
services. The lower levels deal with the wrapping, implementing, and deployment technologies. (2) Models, languages, tools, and notations that support the steps of the development process. The SOS development is a step-by-step process. Each step in the development process: x Reflects the three aforementioned techniques that are (1) wrapping of legacy into Web services, (2) checking compliance with SOC paradigm, and (3) composing software out of Web services. x Reflects the multiple interfaced, abstraction levels, whereby there is at least one level for wrapping legacy into Web services, one level for composing software out of Web services, and one interface for checking the compliance. x Reflects the identification, specification, design, deployment, usage and management of Web services with respect to SOC. x Is supported by models, languages, tools used for wrapping, expressing the composition (e.g. BPEL4WS), and checking the compliance. That is, the main steps of such a process would be: x Decide the SOA architecture x Specify the architecture of the software x Identify the pieces of software candidate to be Web services x Wrap legacy applications that fulfill the requirments x Deploy the Web services
V. RELATED WORK Perspectives development of Web services have been nearly tackled by different works related to analysis and design of Web services, where approaches attempt to raise the level of abstraction to identify and design Web services with respect to well-known design decisions, namely cohesion and loose coupling. For instance, MDA presents function-centric approach as top-down process [10]. Our approach has reused and extended the main strengths of these different approaches and tools to guide a SOS development guided by a comprehensive multilevel abstraction architecture that considers the desirable properties and perspectives of Web services principled by the SOC and sketched out in a WSA metadata. VI. CONCLUDING REMARKS AND FUTURE WORK The main contribution of the approach is to take into account different perspectives of the Web services development with respect to the principles of SOC in order to make them an efficient realization of SOS. Indeed, the approach uses a metadata that sketches out all the properties of a Web services stack with respect to
SOC paradigm, which provides a framework and guidance for SOS development process. The usage of the proposed approach will: x Allow a development of different categories of Web services for multiple usages and different software systems for business and industry sectors x Reduce the effort, the time and the cost required to develop Web services This work can extend by developing models, languages and notations having in mind that the philosophy behinds SOC and SOS is completely different from any OOAD. For instance, the latter use CASE tools to mainly generate codes, whereas the former needs CASE tools to compose agile business processes out of the well-specified Web services REFERENCES [1] D. Austin, et al., Web Services architecture requirements, W3C Working Group Draft 14, 2002. [2] Y. Baghdadi, Specification of a tool for monitoring and managing Web services architecture, Proceedings of ICEIS’0 (2007), Madeira, Portugal, 12-16 June, 2007 [3] G. Booch, J. Rumbaugh, and I. Jacobsen, Unified Modeling Language User Guide. Addison Wesley, 1998 [4] F. Casati, et al., Business-oriented management of Web services, Communications of the ACM 46(10) 55-60, 2003 [5] P. C. Clemens, From subroutine to subsystems: component-based software development, The American Programmer 8(11) (1995) (November), 1995 [6] F. Curbera, et al., The next step in Web Service, Communications of the ACM 46(10) 29-34, 2003 [7] E. W Dijsktra, The structure of "THE"-multiprogramming system, Communications of the ACM 11(5) 341-346, 1968 [8] S. Dustdar, and W. Schreiner, A survey on web services composition, International Journal of Web and Grid Services 1(1) 1–30, 2005 [9] A. Elfatatry. Dealing with Change: Components versus services, Communication of the ACM 50(8). 35-39, 2007 [10] D. Frankel, and J. Parodi, Using model-driven architecture to develop Web services, http://www.omg.org/attachments/pdf/WSMDA.pdf. [11] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995 [12] M. N. Huhns, and M. P. Singh, Service-oriented computing: Key concepts and principles, IEEE Internet Computing (January-February) 75-81, 2005 [13] H. Kreger, Fulfilling the Web services Promise, Communications of the ACM 46(6) 29-34, 2003 [14] B. Meyer, Object-Oriented Software Construction , 2nd Edition, Prentice Hall, 1997 [15] M. P Papazoglou, and D. Georgakopoulos, Serviceoriented computing, Communications of the ACM 46(10) 25-28, 2003 [16] D. L. Parnas, On the criteria to be used in decomposing systems into modules, Communications of the ACM 15(1) 1052-1058, 1969 [17] C. Sycara, et al., Automated discovery, interaction and composition of Semantic Web services, Journal of Web Semantics 1(1) 27-46, 2003 [18] C. Szyperski, Component software: Beyond objectoriented programming, Addison-Wesley, MA 1997
