BASS: Business Application Support through Software Services

Download PDF
4 downloads 175476 Views 50KB Size Report
Comment
Department of Computer Science ... business logic description of the applications from the sup- ... Software services can be used in different application do-.
BASS: Business Application Support through Software Services

∗

Mateus B. Costa∗,† CEFETES – Federal Center for Technological Education of Espírito Santo Serra, ES, Brazil [email protected] ?

†

Rodolfo F. Resende† Federal University of Minas Gerais Department of Computer Science Belo Horizonte, MG, Brazil [email protected]

Eduardo F. Nakamura? FUCAPI – Research and Technological Innovation Center Manaus, AM, Brazil [email protected]

Abstract In this paper, we introduce a software framework called Business Application Support through Software Services BASS. BASS supports the development of information system applications. BASS support aims at decoupling the business logic description of the applications from the supporting implementation, e.g. software services. BASS also allows us to define service access elements without programming activities. By using the BASS framework, target applications can dynamically select and specify service invocations according to the execution of the supported business processes.

1. Introduction Information systems integration, driven from increasing demands for collaborative activities, must consider important interoperability aspects and, at the same time, should not impose hard technological or business constraints [22]. Therefore information systems development must be supported by software solutions considering such interoperability aspects. Service Oriented Computing (SOC) is considered a major paradigm to support their development [19]. In the SOC paradigm, a software service is an element with functions available to other networked software elements. A software service can also be seen as a software element that encapsulates one or more business functions [8]. An application supporting an information system can play the role of service provider or service client. A client application can use a business function available through a service once guaranteed the integration at the message exchange level, at the application architecture level, and by the supported business processes [13].

Marcelo V. Segatto‡ Federal University of Espírito Santo Department of Electrical Engineering Vitoria, ES, Brazil [email protected] ‡

Nahur Fonsecaψ Boston University Department of Computer Science Boston, MA, USA [email protected] ψ

Web Services are one of the important sets of technologies that implements the software service concept. Web Services technologies provide a high degree of interoperability at the message exchange level and among different development platforms, facilitating the integration at these levels [8]. However, the interoperability aspects that remain at business process level must be considered in the development of the involved applications. Applications that provide services are developed to enable run time service discovery [21] and composition [16] to be performed by unknown client applications. Client applications should therefore deal with service discovering, selection and execution driven by their business processes, Business Transaction support [6, 18], and several other aspects, e.g., vocabulary mediation [9]. In this work, we present the Business Application Support through Software Services - BASS, a software framework [11], for developing the software infrastructure for information system integration. BASS provides an Application Programming Interface (API) that simplifies the mapping of the business process level onto the application’s architecture level, allows the definition of the application business logic to be independent from the software services aspects and encapsulates the complexity of dealing with the software services and the service’s business functions idiosyncrasies in the application development. The use of BASS also permits the definition of service access aspects without the need of program encoding. One important contribution of BASS is to show that a service can be treated during software development as a logical and physical element absent from the conceptual models. The remainder of this paper is organized as follows. In Section 2, we discuss the aspects of applications, which are client of software services, that can be developed by using

BASS. In Section 2 we also introduce our running example. In Section 3 we discuss the application development using BASS. In Section 4, we present some related work. Section 5 presents future directions and concludes the paper.

2. Client Applications Software services can be used in different application domains, such as scientific applications and information systems for E-Commerce. The development of BASS is focused on the information system domain. To illustrate the use of BASS we adopt as an example the development of a simple Business-to-Business application to manage orders among a client and several suppliers. Despite its simplicity this example follows some ideas presented by Papazoglou [18]. The Order Management includes the following functionalities: • Create Order. The client creates an order following the main flow: 1. Create an order; 2. Place the order. • Verify order. The client verifies an order following the main flow: 1. Get the order ID; 2. Retrieve the order; 3. Present the order. • Cancel an order. The client cancels an order following the main flow: 1. Get the order ID; 2. Cancel the order. • Update an order. The client updates an order following the main flow: 1. Get the order ID; 2. Retrieve the order; 3. Update the order data; 4 Re-place the order. • List a set of orders. The client queries the orders following the main flow: 1. Get the order list selection criterion; 2. Retrieve the order list based on the selection criterion; 3. Present the order list.

Herein we consider a software development process based on the Unified Process [15]. The Unified Process prescribes the use of Object Oriented Modeling and Design, UML notation and Use Case based development. In order to represent the functional requirements of the Order Management, its functionalities can be translated in terms of an use case diagram. One aspect of using the Unified Process is the development of: a) an analysis model, represented by diagrams that include the elements of the problem domain; b) a design model, with diagrams representing, in high level, the elements of the solution domain for the chosen development platform; and c) an implementation model that details the solution described by the design model. Here we consider a process based on the Unified Process and customized for the BASS framework, but we focus on the design model aspects. A preliminar design model for Order Management could be represented in terms of local software elements, without

Order (from entity)

OrderCollection

OrderManager

(from entity)

(from control)

OrderInterface (from Boundary)

Figure 1. Classes involved in the Order Management.

considering software Services. Figure 1 presents a possible class diagram of the Order Management design model including these elements. To support the Order functionality, the OrderManager class can implement the operation saveOrder(Order order). Similarly, the remaining functionalities can be supported by operations that form together a set of operations much like the CRUD (Create, Retrieve, Update, and Delete) operations set [5]. Such operations would be: retrieveOrder(OrderId id), listOrders(OrderCriterion criterion), saveOrder(Order order), deleteOrder(OrderId id), and updateOrder(Order order). We refer to this set as RLSDU operations (Retrieve, List, Save (create), Delete, and Update). In a local implementation, such operations can be supported by a persistence layer [1, 14] that encapsulates the adopted storage mechanism and allow these operations to be performed exclusively by means of operations involving application objects. To illustrate how these RLSDU operations are implemented in terms of software services, we consider herein that the orders are sent the suppliers’ information systems through software services. In the development based on software services, services are usually accessed by elements, called stubs, and local representations of the data types defined by the services. The majority of Web service platforms provide a tool to automatically generate these elements (stubs and data types) from the service interface descriptions. This style allows client applications to be developed using the operations available in the stubs and abstracting the adopted service access platform. Let us consider the layered architectural style [20] where we define two layers: an Application and an Integration layer. In the application layer, we have the application local elements and representations of elements external to the application. In the integration layer, we have elements to

support the service access. Figure 2 presents a diagram containing the Application and the Integration layers represented as packages. The package representing the Application Layer has the subpackages Entity, Control and Boundary as derived from the Analysis Model following the prescription of the Unified Processs. In the Application layer we have also the stubs corresponding to the services of each supplier. The integration Layer presents a high level API built with APIs such as the one defined by Apache AXIS[2].

(from entity)

SupplierABindingStub makeInvoice(invoice : Invoice)

OrderInterface

OrderManager SupplierBBindingStub

(from Boundary)

saveOrder()

control

makeOrder(order : Order) : String

SupplierCBindingStub Order number description price date employee

makeRequest(request : Request)

Invoice id description price

Application Layer (from Logical View) entity

OrderCollection

Order orderId specification amount orderDate

Request number goods value date

boundary

Figure 3. Class Diagram for the Order Management Application Layer. serviceStubs (from Integration Layer) supplierA (from serviceStubs)

supplierB (from serviceStubs)

3. Using BASS to develop applications supplierC (from serviceStubs)

Integration Layer (from Logical View) Software service access API (from Integration Layer)

Figure 2. Order Management Layered Architecture

Figure 3 presents the class diagram for the Order Management considering the use of stubs. In this example, we consider one client and three suppliers. Each supplier has its own stub and its data type set. To represent an order, SupplierA uses the Invoice data type, SupplierB uses the Order data type, and SupplierC uses the Request data type. All these data types differ, in terms of attributes, from the Order data type defined in the client application. The implementation of the saveOrder(Order order) and the other RLSDU operations imposes specific logical elements (stubs and data types) dependencies to represent the business logic. These dependencies introduce complexity in the development of the business process driven service selection and execution support. This approach also introduces difficulties for application change management, scalability and flexibility [12].

Similarly to persistence layers tools, BASS provides an API that allows the development of the Application layer design model without logical and physical dependencies of the services’ access. The RLSDU operations are the substitutes for the direct service access. In our example, an order is represented by an instance of a class called Order. The RLSDU operations deals with instances of classes such as Order. Classes such as Order are referred to as a proxy entity. BASS implements RLSDU operations for proxy entities. Each proxy entity has a corresponding external representation and the set of values associated to external representations define an external state. The semantics of these operations is specified as follows: • Retrieve: retrieves the entity proxy external state. This external state is retrieved and converted into an entity proxy instance; • List: retrieves the external state of a set of entity proxy instances; • Save: Saves the state of an entity proxy instance into an external representation. The representation is created if it still does not exists; • Delete: Removes the external representation associated with an entity proxy instance; • Update: Updates the state of an existing entity proxy instance based on the state of its corresponding external representation. The Update operation is provided, except for inexistent objects, as a convenient option to the pair retrieve and save.

The semantics for the RLSDU operations does not define the concrete actions that will be performed out of the application bounds. As we will see later, this task is part of the configuration of BASS. In the context of a layered architecture with an Application layer and Integration layer, by using BASS, the development of the Application layer does not depend on the stubs and data types used to access software services. Figure 4 illustrates this architecture and also shows the dependency relations among the elements of the Application and Integration layers. The elements of the Integration layer referred to in the Application layer are the Session and OCLExpression classes.

Application Layer (from Logical View) control

boundary

arguments used to perform the RLSDU operations will be defined based on the class or object that executes the operation and on the business rules expressed using the Object Constraint Language (OCL) [17]. OrderCollection (from entity)

Session

OrderInterface

OrderManager

(from boundary)

saveOrder()

loadBindFilter() loadBindMap() retrieve() save() list() update() delete()

Order

OclExpression

number description price date employee

OclExpression() getConstraints() getDynamicParameters() getStatements() setConstraints() setStatements()

entity

Figure 5. Class Diagram for the Order Management Application Layer by using BASS. Integration Layer (from Logical View) bass (from Integration Layer)

To save an order, an OrderManager object will perform the following steps: 1. Instantiate an object of Order class and set its values;

Session

OclExpression

(from core)

(from ocl)

2. Choose the target supplier; 3. Specify the supplier in terms of an OCL expression;

Dependency achieved by using reflexion

serviceStubs (from Integration Layer)

Software service access API (from Integration Layer)

Figure 4. A Layered Architecture using BASS. Figure 5 depicts the elements of the Application layer and the elements of BASS used to implement the Order Management. The RLSDU operations will be performed taking an Order proxy entity (a class or an instance, depending on the operation) and a set of business rules. The Session class implements the generic RLSDU operations. The OCLExpression class supports the specification of the business rules that will be used to perform those operations. The services, services’ operations, and operations’

4. Invoke the save operation by using a Session object and by passing the Order and OCLExpression objects as arguments. The supplier choice is a decision made during the business process execution and can be guided by the user interaction with the objects of the OrderInterface class. This aspect forces the software service interactions to be automatically guided by the business process of the client application. Another task performed by BASS is the vocabulary mediation. As we can see in the example, the application Order class differs, in term of attributes, from the equivalent suppliers’ classes. Mediation between these vocabularies is automatically performed by BASS. The configuration of the Integration layer involves two main tasks: Specify the bindings of every proxy entity: In the context of this work, binding is an implementation of an abstract data type that encapsulates an association between an entity proxy and a software service and the details of such an association. Specify the application vocabulary: The application vocabulary includes the definition of a set of terms and mor-



Figure 6. Excerpt of a binding file related to class Order showing the {Order,save} binding.

phological relationships among these terms, such as synonymity. Every pair {proxy entity, RLSDU operation} has a set of bindings. For instance, the pair {Order, save}, has a binding with SupplierA, SupplierB and SupplierC. In our current implementation of BASS, the set of bindings related to an entity proxy is represented by an XML file that we call binding file. Figure 6 presents the set of bindings corresponding to the {Order, save} pair. The specification mechanism of the vocabulary used by the application is a framework hotspot [11]. A hotspot is a customizable (programmable) framework element. This hotspot allows the incorporation of different mechanisms for defining and analyzing the application vocabulary and mediating the vocabularies used by the application and the software services. In our current implementation, the vocabulary mediation mechanism is based on lists composed of: a) one local term, used for conceptual modeling of the client application and b) a set of synonyms from data types and parameters used by the software services. Figure 7 illustrates terms used in our Order Management example.

order invoice request number id orderId description specification price amount value date orderDate empployee

Figure 7. Order Management vocabulary.

3.1. Observed Aspects in the Development using BASS BASS was defined together with a method for designing and implementing applications that are clients of software services. In this method, we observe the following features: 1. The modularization of the application development by separating the design and implementation of software service interactions from the remaining parts. This aspect can be observed in the separation of the design of the Order Management in an Application layer and an Integration layer. Among the benefits of such a separation, we can observe the simplification not only of the work division and testing but also a simplification of the mapping of the application analysis model onto its correspondent design model without the need to consider the aspects of the software services being used. 2. The specification of the service interactions is done without programming activities. In reality, instead of procedural code programming, BASS specifies a type of declarative programming using configuration files. As we showed, the Integration layer is configured by using binding files and the vocabulary definitions. Such configuration, can be aided by a tool that automatically gets the stubs and data types of the associated services, and simplifies the definition of the binding files (e.g., by using a graphical interface). This tool can also aid the vocabulary entry generation based on the business rules and on the application proxy entities, stubs, and data types. 3. The service selection and execution guided by business processes. As we observed, the service selection and execution occurs transparently based on instances of business rules and processes executed in the application layer. For instance, in the execution of an order placement, the determination of which service should be executed is done through user interactions. Based on that choice, a business rule instance containing the supplier specification is created, and BASS determines the bind entry associated to the supplier (see Figure 6).

4. Related Work Software development tools and platforms that support Software Services, such as .NET and J2EE, have been used within development models in which computations that use Web services have been explicitly programmed in the application modules by means of Stubs or remote procedure calls. However, some of the problems resulting from such an approach have been pointed out in the literature. In the remainder of this section we briefly discuss some approaches to these problems.

Eberhart [10] proposes the so called Web Service Description Framework (WSDF) that handles the aspects of the dynamics of service-oriented applications by using an approach based on Web Semantics and ontology. The main purpose of the WSDF is to allow a client application to access a service without knowing its description. Verheecke and Cibran [3] address the problem of the applications’ lack of flexibility caused by the explicit coding of computations, in client applications, that use Web Services. The authors propose an intermediate layer between applications and services called Web Service Management Layer (WSML). The WSML allows the use of Web Services without hard coding the invocation of the services by using Aspect Oriented Programming. Baligand and Monfort [4] present a similar approach, but they focus on including policies for specifying nonfunctional requirements also in the the description and in the invocation of services. We have also experimented, in early work, the use of Aspects for dealing with software services selection and invocation [7]. Our solutions based on Aspects introduced elements nonintuitive to the business logic definition, whereas, the use of Object Oriented frameworks were more appropriate in creating the abstraction view of the integration layer in the application development.

5. Conclusion and Future Work The use of technologies based on software services aids the development of applications for different domains, such as E-Commerce, Collaborative Work, and Information Distribution. However, the difficulties for this development are not negligible. In this work we presented BASS, a software framework to support the development of applications that are clients of software services. The use of BASS decouples the business application aspects from the implementation details of software services. The definition of the services related to the application are specified in a customizable way, without the need of programming activities. BASS enables the business process-driven software selection and execution, and eases the services run time configuration. As future work, we plan to extend the current version of BASS with long-running transactions [18]. The support of such transactions aims at allowing the definition of the treatment of possible transaction variations. Other future work includes the definition of a GUI-based configuration tool for BASS and a customization of a software process including BASS. Our current results are very promising and we believe that the benefits obtained by using BASS are similar to the benefits obtained by using a persistence layer instead of hard-coding SQL commands in an application. Nevertheless, we are designing an experiment that will characterize the benefits of using BASS instead of hard-coding a network solution.

References [1] S. Ambler. Mapping Objects to Relational Databases, 2000. [Online] Available: http://www.AmbySoft.com/ mappingObjects.pdf. [2] APACHE. Apache Axis, 2006. [Online] Available: http://ws.apache.org/axis/. [3] M. A. C. B. Verheecke and V. Jonckers. AOP for Dynamic Configuration and Management of Web Services. In ICWS’03), September 2003. [4] F. Baligand and V. Monfort. A Concrete Solution for Web Services Adaptability using Policies and Aspects. In ICSOC ’04, pages 134–142, New York, NY, USA, 2004. ACM Press. [5] A. Cockburn. Writing Effective Use Cases. Addison Wesley, 2001. [6] M. B. Costa, R. F. Resende, M. F. Alves, and M. V. Segatto. Business-to-Business Transaction Modeling and WWW Support. In BPM’2, pages 132–147. LNCS Springer Verlag, June 2004. [7] M. B. Costa, R. F. Resende, P. S. Neto, and M. H. F. Alves. Utilização de Aspectos no Desenvolvimento de Aplicações baseadas em Serviços Web. In WASP’04, 2004. [8] F. Curbera, W. Nagy, and S. Weerawarana. Web services: Why and how. In OOPSLA’01: Proceedings of the Workshop on Object-Oriented Web Services. ACM, 2001. [9] A. Dey, J. Mankoff, G. Abowd, and S. Carter. Distributed Mediation of Ambiguous Context in Aware Environments. In UIST ’02, pages 121–130, New York, NY, USA, 2002. ACM Press. [10] A. Eberhart. Towards Universal Web Service Clients. In Proceedings of the Euroweb, 2002. [11] M. E. Fayad, D. C. Schmidt, and R. E. Johnson. Building Application Frameworks: Object-oriented Foundations of Framework Design. John Wiley & Sons, Inc., New York, NY, USA, 1999. [12] R. B. Grady. Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall Inc, Upper Saddle River, NJ, 1 edition, 1992. [13] W. Hasselbring. Information system integration. Commun. ACM, 43(6):32–38, 2000. [14] Hibernate. Relational Persistence for Java and .Net, 2006. [Online] Available: http://www.hibernate.org/. [15] I. Jacobson, G. Booch, and J. Rumbaugh. The Unified Software Development Process. Addison Wesley, 1998. [16] N. Milanovic and M. Malek. Current Solutions for Web Service Composition. IEEE I. Computing, 8(6):51–59, 2004. [17] OMG. Object Constraint Language Description, 2003. [18] M. P. Papazoglou. Web Services and Business Transactions. World Wide Web: Internet and Web Information Systems, 6(1):49–91, 2003. [19] M. P. Papazoglou and D. Georgakopoulos. Service-Oriented Computing: Introduction. Communications of the ACM, 46(10):24–28, October 2003. [20] M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Discipline. Prentice Hall Publishing, 1996. [21] G. Spanoudakis, A. Zisman, and A. Kozlenkov. A Service Discovery Framework for Service Centric Systems. In SCC ’05, pages 251–259, Washington, DC, USA, 2005. IEEE Computer Society. [22] S. Zang, A. Hofer, and O. Adam. Cross-enterprise business process management architecture- methods and tools for flexible collaboration. In OTM Workshops, volume 3292 of Lecture Notes in Computer Science, pages 483–494. Springer, 2004.