![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (16)
Ähnlich wie Webform Server 351 Architecture and Overview
Ähnlich wie Webform Server 351 Architecture and Overview (20)
Mehr von ddrschiw
Mehr von ddrschiw (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Webform Server 351 Architecture and Overview
- 1. Webform Server 3.5.1 Overview and Architecture
- 4. What’s New in 3.5.1
- 13. How does it look?
- 17. How does Webform Server work? Logging Service Shared File Space C L I E N T Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Webform Server Translator
- 18. How does Webform Server work (Request HTML)? Logging Service Shared File Space GET request HTML response C L I E N T Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Webform Server Translator
- 19. How does Webform Server work (Request Form)? Logging Service Shared File Space XFDL response GET request DHTML DHTML C L I E N T Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Webform Server Translator
- 20. How does Webform Server work (Submit Form)? Logging Service Shared File Space XFDL response Post DHTML DHTML XFDL request DHTML C L I E N T DHTML Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Webform Server Translator
- 21. How does Webform Server work (AJAX Updates)? Logging Service Shared File Space C L I E N T Ajax User Event Ajax Client Forwarder Ajax User Event Change list returned (Ajax) User Event Forwarder ‘ Running’ Form notified of event Change list retrieved and sorted XML change list created Change list (Ajax) Changes made to HTML Form Cache (Memory) Access Control DB Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Translator
- 22. How does Webform Server work (XForms Submit)? C L I E N T Ajax User Event Ajax Client Forwarder Ajax User Event Change list returned (Ajax) User Event Forwarder ‘ Running’ Form notified of event Form Updated with New Data XML change list created Change list (Ajax) Changes made to HTML Web Service Or XML over HTTP Request Response Do XForms Submit Portal/Application Server Portlet/Servlet Framework XFDL Forms Portlet/Servlet WPF API Application Server Translator
- 25. Webform Server Architecture Browser Optional Cluster Server Optional Cluster Server Logging Service Shared File Space How does it scale? Access Control DB Access Control DB Portal/Application Server Webform Server Translator Portal/Application Server Webform Server Translator Portal/Application Server Portlet/Servlet Wrapper XFDL Forms Portlet/Servlet PE API Portal/Application Server Portlet/Servlet Wrapper XFDL Forms Portlet/Servlet PE API Portal/Application Server Portlet/Servlet Wrapper XFDL Forms Portlet/Servlet PE API Portal/Application Server Webform Server Translator
- 47. Differences Between Viewer and Webform Server
- 84. Questions?
Hinweis der Redaktion
- Webform Server’s toolbar only includes 6 buttons: open, save, print, refresh, accessibility mode, and about. (These are discussed later.) Webform Server removes the need for the Viewer by providing a central site that can serve HTML versions of XFDL forms to users. While there are some minimum browser requirements (discussed later), this can include the general public or any computer-based audience.
- Group 0 = (1 language, 12 locales) English (12 locales) en Australia = en-AU Belgium = en-BE Canada = en-CA Hong Kong = en-HK India = en-IN Ireland = en-IE New Zealand = en-NZ Philippines = en-PH Singapore = en-SG South Africa = en-ZA United Kingdom = en-GB United States = en-US Group 1 = (9 languages, 38 locales) French (5 locales) fr Belgium = fr-BE Canada = fr-CA France = fr-FR Luxemburg = fr-LU Switzerland = fr-CH German (4 locales) de Austria = de-AT Germany = de-DE Luxemburg = de-LU Switzerland = de-CH Italian (2 locales) it Italy = it-IT Switzerland = it-CH Portuguese (1 locale) Brazil = pt-BR Spanish (20 locales) es Argentina = es-AR Bolivia = es-BO Chile = es-CL Colombia = es-CO Costa Rica = es-CR Dominican Republic = es-DO Ecuador = es-EC El Salvador = es-SV Guatemala = es-GT Honduras = es-HN Mexico = es-MX Nicaragua = es-NI Panama = es-PA Paraguay = es-PY Peru = es-PE Puerto Rico = es-PR Spain = es-ES United States = es-US Uruguay = es-UY Venezuela = es-VE Simplified Chinese (2 locales) zh-Hans China = zh-Hans-CN Singapore = zh-Hans-SG Traditional Chinese (2 locales) zh-Hants Taiwan = zh-Hant-TW Hong Kong = zh-Hant-HK Japanese (1 locale) ja Japan = ja-JP Korean (1 locale) ko South Korea = ko-KR Group 2 = (12 languages, 13 locales) Czech (1 locale) cs Czech Republic = cs-CZ Danish (1 locale) da Denmark = da-DK Dutch (2 locales) nl Belgium = nl-BE The Netherlands = nl-NL Finnish (1 locale) fi Finland = fi-FI Greek (1 locale) el Greece = el-GR Hungarian (1 locale) hu Hungary = hu-HU Norwegian Bokmål (1 locale) nb Norway = nb-NO Polish (1 locale) pl Poland = pl-PL Portuguese (1 locale) pt Portugal = pt-PT Russian (1 locale) ru Russia = ru-RU Swedish (1 locale) sv Sweden = sv-SE Turkish (1 locale) tr Turkey = tr-TR Group 3 = (4 languages, 4 locales) Croatian (1 locale) hr Croatia = hr-HR Slovak (1 locale) sk Slovakia = sk-SK Slovenian (1 locale) sl Slovenia = sl-SI Romanian (1 locale) ro Romania = ro-RO
- Platform support has been expanded for the 2.6 version to include AIX and Solaris. The installer has also been improved, and will do a lot of the WAS setup for you. Even setup database if installing in Cloudscape. Webform Server no longer supports the use of Tomcat (as it did in 2.5).
- Webform Server requires you to write either a servlet or a portlet application. In either case, this application must both serve the form to the user and process the user’s response. The servlet/portlet extends the framework that is provided by Webform Server (rather than the normal servlet and portlet classes). As a result, Webform Server is able to automatically convert the form between XFDL and HTML when necessary. The servlet/portlet will automatically query the end-user’s computer to see if they have the Viewer installed. If they do, Webform Server will not translate the form – it will send XFDL so that the user can work in the more fully-featured Viewer. If they do not have the Viewer, Webform Server will send HTML for their browser. Webform Server also provides support for accessibility needs. This includes the enhanced focus indicator that the Viewer uses (a small black box that appears at the upper-left corner of the item that has the focus) and screen reading support for the JAWS screen reader.
- Forms that are translated to HTML look almost exactly as they do in the Viewer. There are some slight differences because Webform Server uses standard HTML widgets, and in some cases those widgets differ slightly from the XFDL versions. However, for the most part it is difficult to tell the difference between the two forms. Just like the Viewer, Webform Server adds a toolbar to the form. However, because Webform Server has more limited functionality than the Viewer, this toolbar only has 6 buttons (described later). It’s worth noting that this duplication in appearance is entirely intentional. While it may be useful to render slightly different appearances in HTML, or to allow user’s to apply their own style sheets, this would defeat the “sign what you see” philosophy that underlies Workplace Forms. Essentially, forms that are signed in Webform Server should look exactly the same when inspected in the Viewer, and vice versa. If they did not, the overall security and authenticity of the form could be called into question.
- Even complex forms look just like they would in the Viewer.
- The toolbar offers the following functionality: Open Form – this opens a form from the local file system. In this case, Webform Server uploads the XFDL version of the form to the server. It then translates the form into HTML, and sends the user the first page. Save Form – this saves the form to the local file system. In this case, Webform Server sends the entire XFDL form to the user. This does not save HTML. Print Form – this prints the form to a local printer. In this case, Webform Server generates a PNG image of the form from the XFDL version, then sends the PNG to the end-user. The end-user then uses the normal browser print dialog to print the image. Toggle Accessibility Mode – this enables the enhanced focus indicator and screen reader support. The enhanced focus indicator is a small black square that appears at the top-left corner of the item that currently has the focus. Screen reader support is limited to the JAWS screen reader. About – this opens a dialog that provides version information for Webform Server.
- The Pieces: Client – This is the end-user. In a typical scenario, they use a web browser to surf to a website that has forms they can work with. Portal/Application Server – This is the application server that hosts the servlet/portlet application you have built for Webform Server. Your application runs within the Webform Server framework, and may make calls to the Workplace Forms API. Application Server – This is the application server that runs the Translator component of Webform Server. This is the part that does the actual translation of XFDL to HTML. It can run on the same server as your portlet/servlet, but is more commonly placed on a second server. Access Control Service – This provides fail-over support for the system. The Access Control Service tracks which users are using which form instances, and ensures that in a clustered environment, the user can fail-over successfully. Logging Service – The logging services is used both by all other components: your portlet/servlet, the Translator, and the Access Control Service. It provides basic logging capabilities through log4j. Shared File Cache – This is simply a file area that is used by the Translator to store temporary files. When a form is opened by Webform Server, the original XFDL is stored and maintained in the Shared File Cache.
- When you first try to open a form through Webform Server, the Framework first tries to determine whether you have the Viewer installed. This process follows these steps: A bounce mechanism sends a small piece of JavaScript to the client. This JavaScript contains a small XFDL form. The JavaScript asks the client browser to open the form. If the post is successful, then the Viewer is installed. If the Viewer is installed, the JavaScript examines the headers of the post to see if the right version of the Viewer is installed. The JavaScript sends the results to the Framework, which sets its own session flags accordingly. Once these flags are set for the session, no further attempts to detect the Viewer are attempted.
- Next, the Framework carries out the original request as follows: The get request goes to the portlet/servlet. The portlet/servlet loads an XFDL form and sends it as the response. The Framework intercepts the XFDL response and forwards it to the Translator. The Translator converts the form to DHTML, and sends it back to the Framework. The Framework sends the response to the user.
- When a form is submitted the following actions occur: The DHTML form is submitted to the portlet/servlet. The Framework intercepts the form when it comes in and passes it to the Translator. The Translator transfers the data from the DHTML form to the original XFDL form, then sends an XFDL response back to the portlet/servlet. The portlet/servlet processes the form and loads a response forms, which it sends back to the user. The Framework intercepts the response form and sends it to the Translator. The Translator converts the response form to DHTML and sends it back to the Framework. The Framework passes the DHTML form to the client.
- Webform Server uses Ajax (Asynchronous JavaScript And XML) to communicate with the Translator for small updates. This allows dynamic updating based on formatting, type checking, computed changes to the form, and so on, without redrawing the form in the client browser. When an update event occurs, the following steps are taken: Ajax recognizes a user event on the client that requires an update, and sends an update request to the framework (or Forwarder Servlet in Portal). The request is read in by the Framework (or Forwarder) and forwards it to the Translator. The Translator replicates the event in the copy of the XFDL form it is running in memory, and retrieves the list of changes that need to be made. The Translator then creates a list of XML changes that are required, and sends that list back to the Forwarder. The Forwarder passes the change list through the Framework and back to the client. Ajax updates the HTML form as required.
- Webform Server uses Ajax (Asynchronous JavaScript And XML) to communicate with the Translator for small updates. This allows dynamic updating based on formatting, type checking, computed changes to the form, and so on, without redrawing the form in the client browser. When an update event occurs, the following steps are taken: Ajax recognizes a user event on the client that requires an update, and sends an update request to the framework (or Forwarder Servlet in Portal). The request is read in by the Framework (or Forwarder) and forwards it to the Translator. The Translator replicates the event in the copy of the XFDL form it is running in memory, and this time sees that an XForms submit needs to occur. The Translator extracts the appropriate instance data from the form, and submits the data to the appropriate URL. The Translator receives the response, and places any new data in the form. The Translator then creates a list of XML changes that are required, and sends that list back to the Forwarder. The Forwarder passes the change list through the Framework and back to the client. If changes effect layout (create more items, remove items, etc), then page refresh is done. If changes are only to data, then no page refresh is done. Ajax updates the HTML form as required.
- Multiple Shared File Cache’s helps limit the effects of a possible single point of failure. Where if the Shared File Cache went down in a single Shared File Cache architecture, the entire system goes down – compared to a system with 3 boxes, each box has 3 translators running, and each box had its own shared file cache (shared between the 3 translators on that box). If one of the shared file cache’s went down, the other 2 translator boxes would remain active and receive any new requests. Any current session in the failed file cache box would be lost
- Typical scaling of Webform Server allows for replication of the servlet/portlet server, as well as replication of the Translator Server. For example, you could have one Portal backed by 3 Translators, or 3 Portals and 3 Translators, or any other combination. The Access Control Database may also be replicated. The Logging Service and Shared file cache are not typically replicated (although the Logging Service could be).
- There are a few portions of this servlet that are not used by the example form. The code to handle an xforms-replace-all, for example, is not used by this form. If time permits, it is worthwhile to find or create a form that uses this code to demonstrate what it does.
- In a normal Portal, you have several different portlets, some of which may need to communicate with each other. This is fairly easy to achieve using session beans. Each portlet can write to or read from these session beans as necessary, allowing them to pass information between each other. This is especially useful with forms. For instance, one portlet may need to tell another portlet which form to load. Or one portlet may need to pass some data to another portlet, which then populates the form it’s displaying with that data.
- Opening forms from the local file system actually uploads the XFDL version of that form to Webform Server’s shared file cache. The form in the cache is then translated into HTML and sent back to the user so that they can work with it in their browser. Saving forms to the local file system actually downloads the XFDL version of that form to the user’s computer. The XFDL version is updated based on the user’s most recent changes to the HTML, then sent down as a single, up-to-date file. This allows users to route the form via email to other people, who can then re-open the form in Webform Server if required.
- Form Layout : Forms may look slightly different in Webform Server than they do in the Viewer simply because the HTML widgets used to the draw the form may have slight differences from our standard XFDL widgets. However, in general it’s very difficult to tell the difference between the two forms. Webform server does not support certain widgets: Calendar widgets are replaced with date fields. The slider widget is not supported at all. RTF fields are replaced with plain text fields. Printing : When a form is printed, Webform Server first returns the HTML and updates the XFDL version based on the user’s most recent changes. Webform Server then uses the XFDL version of the form to create a PNG image. This image reflects what you would see in the Viewer. This image is then sent to the user, who sees the browser print dialog open. Because browsers impose their own margins on a printed page, the form might be scaled slightly to account for this, and may be a slightly different size than it would if it had been printed from the Viewer.
- Type checking : All type checking in Webform Server is passive. This means that the checks are applied after the user tries to move the focus to the next item. Incorrect data is flagged as an error with a red color and a dialog that informs the user of the error. Attachments : Because you can only attach one document at a time, you may need to redesign your form to account for this. Forms that require the user to attach 20 documents may become very tedious through this interface.
- Actions : Very limited, as described. Computes : Computes have been greatly improved over the 2.5 version. Through Ajax, they can now update automatically without a compete page redraw. However, this sort of update is not always possible, so those computes that still require a redraw will trigger the redraw automatically.
- Submissions : Submissions will only send data to one URL. Version 6.0 through 6.5 of XFDL offered support for multiple URLs, but Webform Server does not reflect this. Version 7.0 XFDL restricts submissions to a single URL anyway. If you are computing URLs, make sure that your computes result in appropriate destinations. If using a servlet, your computed URL must go back to the same server that is hosting the servlet. If you are using a portlet, you cannot compute the URL. Email : Webform Server does offer direct support for email. There is no email button in the toolbar, and email buttons in the form itself (eg. Submit buttons with an email URL) will not work. If user’s need to email a form, they must save the form to their local file system, then attach the form a regular email.
- Smartfill : You can write user data to/from disk using an XForms submit. This can replicate the behavior offered by Smartfill, but will not include the same user warnings that the Smartfill feature provided. For example, the user will not be warned that data is being written to disk or read from disk, unless you take special measures to replicate these sorts of warnings through other XForms functionality.
- Web Services : Web Services are only supported in XForms forms. The submission data for a web service is wrapped into an XForms submit, complete with the soap envelope. When a response is received, Webform Server will replace a portion of the data model with that response, which will automatically populate the form with that data. Viewer Extensions : Viewer extensions are only supported on the client-side. This means that the extensions cannot perform tasks that would directly affect the user interface. For example, an extension cannot open its own dialog box. However, they can perform functions that indirectly affect the UI, such as setting values in the form that are displayed to the user.