1Usability Challenges for Enterprise Service-Oriented Architecture APIs Jack Beaton, Sae Young Jeong, Yingyu Xie, Jeffrey Stylos, Brad A. Myers Carnegie Mellon University [email protected] Abstract An important part of many programming tasks is the use of libraries and other forms of Application Programming Interfaces (APIs). Programming via web services using a Service-Oriented Architecture (SOA) is an emerging form of API usage. Web services in a business context (called enterprise SOA or E-SOA) add an additional complexity in terms of the number of the services, the variety of internal data structures, and service interdependencies. After altering existing Hu-man-Computer Interaction (HCI) methodologies to address the unique context of software development for SOA, we evaluated a large E-SOA API and identified many usability challenges. Our findings are grouped into three categories: usability breakdowns deriving from the API design itself, from the client-side web service tools, and from the documentation. Prominent results include difficulties developers without business backgrounds encounter in navigating the documenta-tion, and how existing code generators create APIs that confuse developers. Possible solutions include the redesign of documentation to match user browsing expectations, and a tolerance for unspecified objects in automatically-generated web service proxy code. 1. Introduction The informed design of Application Programming Interfaces (APIs) is important to ensuring the effec-tiveness of developers. Design choices can affect the levels of efficiency and rates of adoption of APIs, but without objective and empirical data to justify design decisions, API usability is a difficult goal. “Service-Oriented Architecture” (SOA) is a way to divide software into components, where the compo-nents communicate over a network with the client and with other services, and where the services can be combined into composite applications. Enterprise SOA (E-SOA) is focused specifically on supporting busi-ness processes. E-SOA, as supplied by many companies through web services technology, is a new development para-digm whose usability aspects have not yet been stud-ied. The introduction of business semantics can cause a tremendous increase of complexity, in addition to the existing usability issues with web service technology. Previous research has shown that programming using object-oriented APIs has interesting and unique chal-lenges with respect to usability and API design [2, 3], but the usability implications of large SOA API frame-works for developers are interesting and unstudied. The sheer size of a business application platform presents unique usability challenges. Even if every effort is made by the E-SOA service provider to ensure compliance with best practices in the E-SOA APIs, there is no existing precedent for how to create such a large SOA framework, and it is not known whether the “best practices” result in usable APIs. The complexity of enterprise applications is com-monly cited as being caused by the vast number and variety of services required to meet all the needs of customers’ varied business scenarios. Corporate cus-tomers vary across industry and many have unique requirements, and must all be supported in a standard-ized infrastructure. To respond to customer needs, business application vendors face the choice of adding many new services, or making existing services more versatile and therefore more internally complex. Users of E-SOA APIs therefore experience certain unique usability challenges that have not yet arisen in APIs for other domains. A common “anti-pattern” cited as dangerous for usability is a fine-grained design with too many services, making finding the correct service difficult [4]. On the other hand, providing a coarse-grained design of just a few, multipurpose ser-vices makes them difficult to maintain and understand, since they will have many parameters controlling variations of behavior. However, because of the exten-sive nature of the customer base, not only must busi-ness process vendors provide a constantly increasing array of many hundreds of services, but many of these are also internally complex to support a variety of cus-tomer actions. As a result, vendors simultaneously face both the challenges associated with fine-grained ser-vices and those associated with coarse-grained ser-vices. New solutions to reduce complexity and in-crease usability of SOA APIs are needed that may be generalizable across other SOA API design efforts. Submitted for Publication – do not cite or distribute2We present the results of two user studies to iden-tify challenges when using documentation and coding to create a composite application which uses a large SOA API framework provided by a real company. In summary, our results are that when navigating E-SOA API documentation, users with business backgrounds experienced the most benefit from business process component diagrams, and all users avoided sites with inconsistent visual designs. When implementing com-posite applications, the difficulty of understanding the complex structure of objects to send as a service pa-rameter caused a cycle of errors. We conclude with SOA usability recommendations which can be fol-lowed to avoid the usability breakdowns described here. 2. Enterprise SOA Model of Use Web services are provided by a service provider, and used by developer that wants to create an applica-tion that provides the service to end users. We call the developer a “consumer” of the web service. Services are controlled through a specification, usually in XML, used by both service provider and service consumer. The typical steps when accessing web services us-ing the common SOAP protocol include (see Figure 1): first finding the appropriate service in the online docu-mentation, downloading the requisite Web Service Description Language (WSDL) file using a Universal Description, Discovery, and Integration (UDDI) stan-dard-compliant service registry, entering the WSDL file into automated tools which generate a code refer-ence “stub”, and finally writing and debugging the application code using the stub. Running this code calls the service by sending and receiving SOAP XML messages generated by the stub. The WSDL file de-scribes the parameter information for the messages. Note that the application can be written in any lan-guage that supports SOAP, including Java, C#, Ruby,
or
We will never post anything without your permission.
Don't have an account? Sign up