Extending Service-Oriented Architectures with XForms

Transcription

1 Extending Service-Oriented Architectures with XForms November 2005 Cayce Marston, Senior IT Specialist, Worldwide Technical Sales Software Group, Workplace Portal and Collaboration 1

2 Executive Summary Contents 2 Executive Summary 2 Audience 3 Today s E-Form Technology 9 Web-based E-Form Applications 12 Composite E-Form Applications 16 Host Language Needs Assessment 17 Host Language Feature Considerations 20 Conclusions 20 Contact Us 21 Appendix A Technical Foundations of XForms and SOAs Service-Oriented Architecture (SOA) has become a mainstay of solution architecture. The benefits are broad, ranging from reduced integration costs, improved component reusability, and the ability to leverage existing infrastructure investments. A World Wide Web Consortium (W3C) standard for the next generation of Web-based forms, XForms has generated enormous interest and industry support. In this whitepaper, we ll define E-forms, identify typical e- solutions, and examine how XForms extends SOA. We ll then look at why supports XForms as an enabling technology that can be used to help extend the benefits of SOA into your Web- and Portal-based e-form solutions. Audience Suggested Readings SOA H SOA H SOA Migration [Part 1] H SOA Migration [Part 2] HWikipedia Article XForms HW3C XForms Site HW3C Schools Tutorial HXForms and Cause & Effect Programming This whitepaper is intended for those who are interested in building Web- or Portal-based e-form applications using Service-Oriented Architecture (SOA) and modern design principles. The expected audience for this whitepaper includes but is not limited to Software and IT Architects, Solution Architects, Technology Evangelists, Software or Systems Engineers, IT Professionals, Forms Managers, Forms Professionals and Consultants. For additional background information, check out the Suggested Readings links provided in this section. P. 2/24

3 Today s E-Form Technology As background for discussions within the context of this paper, let s first define E-Forms, E-Forms Solutions, and XForms. E-Forms Defined For the purposes of this discussion, an e-form is an electronic document that presents information and gathers responses to that information. The electronic document has intelligent behavioral aspects and is not just a static countenance as is typical of paper forms. These capabilities enable e-forms to provide a rich user experience and to deal with the dynamic information presentation and complexity of the responses. A number of the key aspects of modern e-forms include: Presentation Layer Widgets: Text entry fields, check boxes, combo-boxes, date pickers, navigation and print controls, buttons, etc. Dynamic Behavior: The ability to present fields, sections, pages, or otherwise alter behavior based on data and business logic. Also, unbounded support for expanding tables, fields, supplementary form pages. Flexibility of Look-and-Feel: Precision layout, color support, font support, icons/logos, and image support for branding. Internationalization: Support for a broad range of international languages. Accessibility: Support for screen-readers, visual preferences, etc. W3C Web Accessibility Initiative (WAI) guidelines and Section 508 compliance in the USA. Attachments: The means for users to attach supporting documents or data (of any type images, video, word processor documents, spreadsheets, etc.). Digital Signatures: Provide a range of capabilities including the ability to add digital-certificate-based signing that provides authentication as well as the option to add digital wet signature -based signing P. 3/24

4 using signature pad hardware. Flexibility of signature technology can be important, including the ability to perform out-of-order sectional signing, to add overlapping signatures, and to validate signatures on both the client and server side. Role-Based Behavior: The ability to integrate users role information with business logic to control access to pages, sections, specific data, etc. Declarative Business Rules: The ability to declare business rules without the use of scripting, similar to using a spreadsheet. This allows business users and non-programmers to implement and modify validation logic and business rules. Suspend and Resume: The ability to halt and then later resume data entry during any stage of the form-filling experience. This term may also be used to indicate support for the persistence of data, business logic, and state to enable offline or support non-persistent connectivity, also referred to as disconnected or offline form use. E-Forms Terminology For the purposes of our discussions, let s use the following definitions: E-Form Document Model: This term refers to the internal architecture and structure of an E-Form. The e-form document model describes the means by which data and presentation information are described within a form. Depending on the technology used for an e-form (HTML, PDF, XForms, etc.), the internal structure of a form can vary greatly. Differences in this fundamental approach can have significant implications on solution architecture and integration with existing systems. The separation of data and presentation as well as the use of open standards are key considerations when selecting an e-form technology. Data Model: This term refers to how data is stored within an E-Form. The data model for an E-Form can vary from proprietary and binary (in legacy PDF forms, for example) to support for multiple, arbitrary XML data instances. P. 4/24

5 W3C XFDL Note Hhttp:// XML Data Instance: A data instance is an XML data structure that typically conforms to the rules in a data model or XML Schema. One analogy is that an XML Schema is the blueprint or plan for a data structure, and an XML instance is a structure that complies with the rules in the XML Schema. A data model is typically comprised of one or more data instances. XFDL: An XML vocabulary initially published in 1998 as a W3C Note (see link provided in this section), informing the W3C community of the need to standardize a set of features for the next generation of secure, intelligent Web-based applications. XFDL was co-authored by PureEdge Solutions (acquired by in July, 2005) and Tim Bray, the co-author of XML. Since this time, XFDL has continued to evolve and is an XForms host language (this concept is covered later in the paper) well suited for XForms, providing pixel precision, robust security, and a range of additional features. E-Forms Solutions Most commonly, e-forms are accessed by end-users via a Web or Portal application or, alternatively, from one s desktop when in a disconnected mode of operation. When we refer to an e-forms solution, the level of integration with other systems can vary greatly based on the results of a standard needs assessment for a given project. Whenever possible, pre-population is used to insert data into form templates, reducing redundant data entry and improving efficiency. Inclusion of schema into e-forms enables client-side data validation, ensuring that invalid or incomplete data does not enter users systems, also reducing errors and rework. Upon form completion and submission, data extracted from e-forms can be used to populate tables in databases, drive back-end processes such as workflow, or provide integration with line-ofbusiness systems. These same systems often provide the data schema from which our e-form data models are derived, enabling straight-through data integration. P. 5/24

6 XForms provides a cause and effect programming paradigm by backing user input and event-based action sequences with schema validation and a declarative business rules engine. HXForms and Cause & Effect Programming Dr. Dobbs Journal Dr. John Boyer, XForms XForms 1.0 is the W3C recommendation for the next generation of Web-based forms. The recommendation provides an XML vocabulary for describing a business processing model. Please refer to HXForms and Cause & Effect Programming, by Dr. John Boyer () for additional information about XForms. XForms is not a free-standing document type but is intended to be integrated into other markup languages such as XHTML, OASIS OpenDocument, SVG, or XFDL. As a W3C standard, XForms is intended to build on and extend the repertoire of open-standards-based technologies. This means that you can develop XFormsbased solutions by using standard software development skills, maximizing skill reuse and reducing the investment in learning, deploying, and maintaining additional proprietary technologies. An important point is that the XForms model relies on a host language to implement the actual form layout, Web Services Description Language (WSDL) support, Web Service calls, addressing, and HTTP. Capabilities of host languages can vary greatly in this regard. As such, the above should be considered when selecting a host language. In much the same way that XForms-based forms can natively contain XML data instances and can submit them to Web Services, they can also consume Web Services for pre-population or for loading real-time data into an e-form (see figure 1). P. 6/24

7 Figure 1: Conceptual Diagram of XML Instance Insertion/Extraction The same insurance industry XML message enclosed within, and populated with data by a life insurance form can be consumed by an underwriting system asis, eliminating the need for translation. Data model and schema standardization is accelerating across a range of industries (insurance, banking, healthcare, etc.), making cross-system data integration possible without the need for data translations. When you consider that data instances can be incorporated into--and referenced by--the business logic within a form, you begin to realize the potential of the technology and the inherent strength of the XForms document model architecture. XForms Terminology: Let s use the following definitions for our discussion: XForms Model: The XForms Model defines the data structure and bindings describing business logic within an XForms-based e-form. The XForms Model does not contain any layout information as this is the responsibility of the host language. The separation of presentation from data and input controls allows us to host an XForms Model within different languages, for example, XHTML or WML, thus allowing delivery to a range of end-user devices. XForms Binds: Within the XForms Model, XForms uses binds to relate XForms properties to XForms data and describes business rules associated with the data. XForms binds are based on XPath expressions. P. 7/24

8 XForms Document Model: As we can see in the conceptual diagram in figure 2, the XForms document model is standards based, with each technology building on the foundation of XML. This makes the e-forms platform independent, consumable by Web Services, and able to be manipulated using the programming language and tools of your choice. XForms Host Languages capabilities vary greatly in their support for Web Services, layout, and security. Figure 2: XForms Document Model and Foundational Standards Service-Oriented Architecture SOA is being accepted as the next evolutionary step in solution architecture. The benefits are broad, ranging from reduced integration costs, improved reusability, and the ability to leverage existing infrastructure investments. A reason for its increasing adoption is that you can incrementally adapt existing systems to use an SOA approach, allowing you to leverage existing infrastructure and solution investments within the context of new projects and modernization initiatives. As is the case with other Web and Portal applications, Web Services is an important technology that we can leverage within E-Form applications. For the purposes of this paper, we ll consider the most common implementation of SOA, that is, Web Services using Simple Object Access Protocol (SOAP) and WSDL. The standard means of service modeling, discovery, and management apply when delivering service-oriented e-form solutions. P. 8/24

9 Let s now examine a practical example of a web-based e- form application, before drilling down further into technical details and host language considerations. Web-based E-Form Applications When building Web-based applications, you are faced with a range of challenges and design-decision trade-offs. The same holds true when developing e-form applications. Historically there have been two main options for delivering e-forms on the Web: 1. HTML e-forms 2. Proprietary technology To set the context for the rest of our discussions, let s take a closer look at each. HTML E-Forms Although HTML forms have been used for some time and are well suited to simple data capture via Web-based solutions in which little-to-no integration is required with back-end systems, the pains associated with implementing enterprise HTML e-form applications include: Poor separation of data and presentation Data-centricity (versus document-centricity) Difficulty of componentization and reuse No offline usability Limited UI capabilities Extremely difficult to reproduce paper forms exactly Complexity of scripting and transformations In general, these issues have been significant barriers to the efficient delivery of HTML form-based solutions. Proprietary E-Forms P. 9/24

10 The use of proprietary e-form technology can result from either a build or buy decision. A critical juncture in these decision-making processes is often the could vs. should assessment. Sure, technically speaking our IT department could build a custom e-forms application. You need to ask whether electronic forms is a core competency of your IT department and, furthermore, whether you are willing to continue to invest in product improvements to avoid being at a competitive disadvantage. Challenges of Traditional Approaches to E-Form Delivery The issues associated with basing your e-form solution on HTML vs. using proprietary approaches to e-forms are often similar and include: High integration costs Poor document model architecture (separation of data, presentation and business logic, extensibility) Poor security and digital signature support Increased costs for training staff on proprietary and non-transferable technologies Lack of portability to different devices Poor range of platform support Inextensibility of features/capabilities (due to either cost of implementation or technical limitations) High development costs, poor reuse Lack of e-form domain expertise by developers Companies and entire industries have been struggling with the above issues for years, often devoting large amounts of resources to solving technical issues unrelated to their own internal processes and core business. P. 10/24

11 A Partial List of XForms Contributors H HPureEdge Solutions* HOracle HSun HNovell HMozilla *Acquired by Introducing XForms The New Standard Eventually, it was recognized that organizations had been repeatedly faced with the above set of challenging issues. In response, the W3C drafted and published the XForms 1.0 Recommendation with the goal of standardizing the next generation of forms for the Web. The W3C XForms working group spent four years in design sessions before recommending the 1.0 version of the standard. The contributors have invested a great deal of effort to ensure the right blend of technology standardization, ease of deployment, and use. If you choose to implement your own e-form technology, there are some challenges your architecture team must address (see figure 3). Figure 3: XForms Compared with Traditional E-Form Solution Approaches Put into perspective, the scope of what you need to architect and develop if choosing to build an e-form application from the ground up (i.e., without XForms) is daunting. Sure, it s all still technically possible; however, one s time and resources could be better focused on higher-level application features. These features include those that are core to your own business processes, rather P. 11/24

12 XForms provides a portable, standardsbased, platform- and device-independent data model for e-forms. XForms natively supports use by heterogeneous, disparate systems across multiple enduser environments. than low-level architecture and implementation of the basic building blocks of e-forms solutions. The bottom line: industry leaders are investing thousand of hours of their domain expertise to standardize architectural e-form best practices; can any of us afford to ignore this body of knowledge? XForms as an Extension of SOA In the sections below we ll see that, in addition to standardizing an e-form document model, XForms technology has excellent alignment with both the principles and technical requisites of service-oriented architectures. Subsequently we ll drill down into the underlying technical details, but first let s examine a real-world example to ground our discussions. E-Form Applications At a functional level, one often sees a similar set of activities occur throughout different forms applications and forms-based processes. Let s consider some of the most common interactions that take place in Web and Portal e-form applications. Standard E-Form Solution Interactions Standard interactions in e-form applications include: Server-side form pre-population, i.e., the merging of an empty form template with data Submission of a form into a Content Management system at various stages of a process or workflow Submission of a completed, signed form to a Record Management System as a transaction record at the conclusion of a process Presentation of a form to users on laptops, tablet or handheld devices both in online and offline modes Storage of form data into a database (often for reporting or for use by other systems) P. 12/24

13 Transmission of form data into one or more Line-of- Business (LOB) systems Validation of digital signatures as part of an approval process. The previously noted interactions tend to arise as essential parts of processes or workflows. Note that this is not intended to represent a complete list; instead, it is a representation of common activities. SOA DRY Principle Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. An Example Composite E-Form Application At a solution architecture level, SOA gives us a great story. The Don t Repeat Yourself (DRY) Principle (see text box in this section) is one of the keys to deriving the benefits of SOA. This same principle should be adhered to when dealing with e-forms. Based on the interactions discussed above, let s now consider figure 4. Figure 4: An example composite e- form solution architecture. Note that figure 4 is intended to be used as an example and does not represent a complete or exhaustive set of use-cases. In practice, Web and Portal applications vary greatly in functionality and implementation. P. 13/24

14 As you can see, a number of the services within the business tier are encapsulations of specific formapplication-related functionality, designed for reuse across multiple applications. Recalling the e-form solution interactions discussed previously, it makes sense to extend the example solution shown in figure 4 by designing and implementing a Digital Signature Certificate Validation Service that encapsulates and abstracts interactions with one s Public Key Infrastructure (PKI). Another point worth mentioning is that, within the Client Tier one can assemble composite applications that leverage one or more e-forms. An example of this would be to combine a client-list Portlet with a new account application form. One could potentially use click-to-action on the client list to populate an empty form template with client data. Making this all possible (or impossible), the technology underlying the e-forms themselves is essential to extending SOA architectural principals into your e-forms. A word of caution: Some binary-inside or proprietary e- form document models result in tight coupling with monolithic server products. This has a number of implications, ranging from dependency on proprietary server products to imposed solution architecture and the inability to use the platform and programming language of your choice. XForms, on the other hand, provides us with a high degree of freedom, made possible by a common foundation of standards-based technologies and the ability to componentize functionality. Coming full circle, table 1 shows how the XForms + SOA approach addresses the business challenges discussed above. Table 1. Summary of How XForms + SOA Approach Addresses Business Challenges Challenge XForms + SOA Approach High integration costs Native support for arbitrary XML instance payloads for integration to multiple database P. 14/24

15 Poor document model architecture (separation of data, presentation and business logic, extensibility) Poor security and digital signature support Increased costs for training staff on proprietary and nontransferable technologies Lack of portability to different devices Poor range of platform support Inextensibility of features / and LOB systems. Entire form document is XML based, and can consume XML either server-side or client-side via Web Services without requiring translation or transformation. Strong architecture developed by e-form industry leaders. Natively consumes arbitrary XML data instances. Designed to support a range of presentation languages, each with different features. Range of host languages from which to choose, with varying levels of security, ranging from minimal to Department of Defense (DoD) tested and certified. Composed of 100% standardsbased technologies. Developers can use the platform, software tools, and programming language of their choice. Range of host languages from which to choose (XHTML, SVG, OASIS OpenDocument, WML, XFDL, etc.). Server-Side E-Form Processing 100% open standards and XML-based forms (data, presentation layer, and XForms model) ensure complete platform independence for processing with the tools and language of your choice. Client-Side Form Interaction Broad range of host language options. Ability to perform server-side translation into HTML + script for display in standards-compliant Web browsers. Extensible document model; P. 15/24

16 capabilities Lack of e-form domain expertise by developers variety of host languages with varying capabilities. Key design challenges addressed by XForms model and document architecture.. Because of these capabilities, XForms delivers on the same principles as SOA by providing a single, standardsbased encapsulation of form technology, thus delivering great value to architects and application developers alike. For a more in-depth discussion of the technical foundations of XForms and SOA, please refer to Appendix A. Now let s look more closely at the key points to consider when selecting a host language. Host Language Needs Assessment By separating the host language (presentation layer) from data instances, the XForms model gives us great flexibility in the delivery of our forms to end users. An important step in any e-form project is to perform a needs assessment for the selection of a host language. The features of your form come from a combination of the capabilities of the e-form document model, which in this case is the XForms model plus the capabilities of the host language. The XForms model is wrapped and extended by the host language, as depicted in figure 5. P. 16/24

17 Figure 5: Potential XForms Host Languages XForms Model + Data + Host Language = E-Form Let s examine some of the key factors considered when selecting a host language. Host Language Feature Considerations Now that we ve taken a look at the advantages of XForms, it s also important to understand upon what XForms relies the host language to provide. Depending on your business needs, a combination of the following is typically required: 1) Presentation Layer XForms requires a host language; it is not intended for stand-alone use. Instead, XForms can be coupled with different presentation layers, thus enabling support for a range of client devices (PC, Mac, PDA, mobile phone, etc.). The same XForms model may be reused within a variety of presentation layers. Different presentation layers provide different capabilities, strengths and weaknesses. It is important to understand that, at this time, you cannot typically auto-generate a usable presentation layer. Some XForms design tools, such as the Workplace Forms Designer, do provide model-driven P. 17/24

18 design capabilities, enabling you to generate sets of controls based on XML schema or data instances. However, the caveat is that you must still: Lay out these presentation layer elements in accordance with user-interface design and best practices Add additional business logic that was not conveyed in the schema Enhance submission of the form with conditional logic for delivery or routing, page navigation, and dynamic user experience, as well as enforce rules around attachment handling Add digital signatures Customize the form with branding / look-andfeel. 2) Precision Layout To expand on the above point, layout of form elements is the responsibility of the presentation layer, not the XForms model. Precision layout is the ability to reproduce existing paper-based forms exactly. Achieving pixel precision is often impossible or very difficult with HTML or flow-based layout host languages. In industries where paper forms are regulated, such as government, insurance, and financial services, paper forms must be faithfully reproduced for compliance. 3) Client-Side Web Service Support Support for client-side Web service support is not part of the XForms 1.0 specification; rather, it is the responsibility of the host language. If you wish to take an SOA approach for client-side form data prepopulation, real-time data, or business-rule parameter look-up or submission, then it is critical to select a host language that can provide this capability. For example, HTML and XHTML do not provide client-side Web Service support. On the other hand, XFDL provides native support for Web Services. In Appendix A, we discuss the technological foundations of XForms and SOA. Let s now take the host language into consideration with regard to P. 18/24

19 technology alignment, using XFDL as an example (see figure 6). Figure 6: Technology Overlay of XForms with XFDL as Host Language and Web Services The result is a complete overlap; that is, the e-form is pure XML, can consume Web services (for prepopulation or submission), and supports not only fulldocument but also data-only submission via HTTP. The degree to which an entire e-form artifact overlays onto and supports these standards indicates the ease with which it can be leveraged from within a SOA. This is not to say that that scenario is not possible by other means, just that your choice of technology can impact the level of development effort required to implement a given solution. Additional Digital Signature Information HXML Digital Signatures HW3C Recommendation 4) Digital Signatures Digital signatures are the responsibility of the host language, not XForms. Standard digital signature considerations when selecting an XForms host language include: Whole-document signing Support for PKI-certificate-based signing Sectional signing Out-of-order sectional signing Signature-pad based signing 5) Document Submission It is important to ensure that the submission mechanism of the host language enables you to submit the entire document. In production systems, a data-centric P. 19/24

20 approach (in which only form data is captured) is often forsaken for a document-centric submission in which the entire form--including the presentation layer--is transmitted. Drivers for whole-document submission include: Compliance: The requirement to retain forms as transaction records is increasingly common for high-value, auditable, or regulated transactions across a wide range of industries Non-Repudiation: Data-only submissions do not retain the context of the user experience. A document-centric approach, in which the entire document is retained (host language, data instances, business rules), combined with digital signature technology, is often preferred. Multi-stage approval or workflow: If a form is to be used throughout several stages of a workflow or approval process, then it is important to retain the entire document. Conclusions "XForms is key to ensuring that electronic Web transactions can be carried out in an open, interoperable manner...it builds on the success of HTML forms to change how companies and individuals do business on the Web." Fellow Rod Smith Today s e-forms give us a means to provide a rich, dynamic user interface for the presentation, collection, and validation of data. Increasingly, this technology plays an important role in business process automation, thus helping improve efficiencies and ease integration. XForms represents a compelling open-standard alternative for developing Web- and Portal-based e-form applications. The document model and technological foundations of XForms make it an excellent choice for standardizing e- forms technology within your service-oriented infrastructure. Contact Us P. 20/24

21 If you are interested in receiving additional information or have feedback for us on this white paper, please contact us at: P. 21/24

22 Appendix A: Technical Foundations of XForms and SOAs As a W3C standard, XForms is intended to build on and extend the repertoire of open-standards-based technologies. This means that you can develop XFormsbased solutions by using standard software development skills, thus maximizing skill reuse and reducing the investment in learning proprietary technologies. The standards-based technologies on which XForms is founded include: HXML HXML Events HXML Namespaces HXML Schema HXPath To provide a consistent visual representation, figure A1 shows a flattened-down version of the three-dimensional representation shown in figure 3 above. Figure A1: XForms Document Model and Foundational Standards In addition to the foundational technologies shown above in figure A1, typical SOAs depend on the following standards (see figure A2): HURI HTTP/HTTPS HSOAP HWSDL P. 22/24

23 Figure A2: XForms Document Model and Foundational Standards You can see that the technical cornerstones of XForms and Web Services (as the most common enabler of SOA) are the same, indicating that the skills and tools employed by your service-oriented application developers are applicable when creating XForms-based solutions. P. 23/24

24 Corporation 2005 Corporation Marketing Communications Systems and Technology Group Route 100 Somers, New York Produced in the United States of America xx 2005 All Rights Reserved This document was developed for products and/or services offered in the United States. may not offer the products, features, or services discussed in this document in other countries. The information may be subject to change without notice. Consult your local business contact for information on the products, features and services available in your area. This information is provided as is without warranty of any kind, express or implied, and is based on s current product plans and strategy, which are subject to change by without notice. shall not be responsible for any damages arising out of the use of, or otherwise related to, this document. Nothing contained in this document is intended to, nor shall have the effect of, creating any warranties or representations from (or its suppliers or licensors), or altering the terms and conditions of the applicable license agreement governing the use of software., the logo and Workplace Forms are trademarks of International Business Machines Corporation in the United States or other countries or both. Other company, product, and service names may be trademarks or service marks of others. The home page on the Internet can be found at Hhttp:// P. 24/24