|
(WSXL) Web Service Experience Language Version 2广告 (WSXL) Web Service Experience Language Version 2
To accomplish these goals, all WSXL component services implement a set of base operations for life cycle management, accepting user input, and producing presentation markup. More sophisticated WSXL component services may be specialized to represent data, presentation, and control. WSXL also introduces a new description language to guide the adaptation of user experience to new distribution channels. User experiences that are implemented using WSXL can be delivered to end users through a diversity of distribution channels - for example, directly to a browser, indirectly through a portal, or by embedding into a third party interactive Web application. In addition, WSXL user experiences can easily be modified, adapted, aggregated, coordinated, synchronized or integrated, often by simple declarative means. New applications can be created by seamlessly combining WSXL applications and adapting them to new uses, to ultimately leverage a worldwide pallet of WSXL component services. WSXL is built on widely accepted established and emerging open standards, and is designed to be independent of execution platform, browser, and presentation markup. Status of this Document 1. Introduction The technical challenge common to all of these dynamic business requirements, is to be able to economically establish and maintain a variety of on-line distribution relationships in a way that can flexibly accommodate the demands of multiple business partners that use different business models. This challenge applies equally to producers of physical products and services and to producers of information or virtual products and services. The key differentiator in this arena is the ability to rapidly (re-)configure the core competencies that drive the on-line distribution relationships. In this environment, the core competencies of a business must be reusable for many different applications, including B2B and B2C. In addition, they must be configurable for different deployment scenarios, for example by branches, subsidiaries or business partners with different needs for process and branding.Finally, businesses often need the ability to create new integrated applications and services out of existing applications and services - either to create new product and service revenue streams or to reduce costs by eliminating redundancy and improving the information flow within the enterprise. 1.2. Requirements for a Web Services Experience
Language This new approach must enable enterprises to: Achieve an effective user experience that is appealing, efficient, and appropriately branded within each delivery channel Support business flexibility through rapid reconfiguration, for example to add new distribution partners and application content providers quickly, or to change and update applications both collaboratively (jointly with partners) and autonomously (without being dependent on the partners) Leverage existing skills and infrastructure Moreover, the new approach needs to support: Ease of change: to implement new and rapidly evolving business models, such as cross-selling, joint offerings, and outsourcing Ease of adaptation: to deliver an application through new channels, such as a portals or third party Web sites, and through new business models, such as OEM or co-branding Ease of aggregation: to group several applications into a single point of access, such as a portal Ease of integration: to create a user experience by seamlessly combining several independently created applications Interoperability: between applications and aggregation products such as portals, and between syndicated applications and distribution channels 1.3. Where WSXL Adds Value 1.3.1. Interactive Web
applications 1.3.2. Application
Syndication This approach has the virtue of simplicity, but it does not allow the provider and the distributor to take full advantage of the ability to add value by combining their applications and integrating their business models. For example, the distributor's application is typically unaware of the page content that is delivered to the user, and unable to alter this content or its behavior. Moreover, an application that has been packaged for syndication is typically not interoperable with any portal, which forces needless redevelopment of applications that need to be delivered through a variety of channels. WSXL is designed to contribute to interoperability between syndicated applications and portals, thereby lowering the cost of implementing applications that support new business relationships. WSXL is also designed to facilitate the adaptation of an application to a particular delivery channel, thus enabling distributors to add value to the syndicated applications. 1.3.3. Portals WSXL is designed to contribute to interoperability by providing a technology that can form the basis for standardizing the interface between applications and portals. At the same time, WSXL is designed to provide a growth path for portals in terms of functionality. In particular, portals typically support "side by side" presentation: the applications that are aggregated are each assigned their own rectangular area on the display, and most portals are very limited in the ability of the aggregator to add value by creating a new user experience that tightly and seamlessly integrates the relevant portions of several existing user experiences. WSXL is designed to support a variety of user experiences ranging from simple "side by side" presentation to tightly integrated and interacting applications. 1.3.4. Service Providers and the Utility
Model The Utility-based model adds use-based pricing to the Service Provider model. It creates even greater demand for reconfiguration, by placing even greater pressure on the supplier to be responsive to diverse and changing customer wants and needs. The ability to customize the user or partner experience is a key element of the strategic value of the service provider and utility-based models, and must be accessible throughout the service delivery value chain. With WSXL, service providers, e-utilities, and their distribution partners can rapidly compose new customer experiences, and wire them together to deliver a new experience that meets the requirements of a particular customer. 1.4. The Emerging Web Services
stack Figure 1 describes one view of the emerging web services standards stack. At the bottom layer TCP/IP has become the de facto network communication infrastructure. HTTP version 1.1 serves as the base upon which the IBM proposed HTTPR adds reliability. SOAP provides an XML based messaging protocol that can be deployed on variety of network layers such as HTTP and HTTPR. ' The Web Services Description Language (WSDL) proposes a way of describing software function. WSDL can use SOAP as the messaging protocol for invoking functions. WSFL and XLang describe how web services can be choreographed to model a business work flow. The three elements down the right-hand side have to be considered at all levels of the stack. WSXL uses WSDL to describe interfaces specific to user-facing applications. WSXL application flow and logic is based on WSFL and XML Events. As the world of Web services based solutions evolves, IBM expects this stack to continue to grow to meet the needs of the marketplace. 1.5. Web Services Experience Language By
Example 1.5.1. Syndicated Purchasing of Traveler Checks In the case of syndication, WSXL gives providers the ability to use a single software asset across multiple distribution channels. As depicted in Figure 2, the provider can describe a WSXL application that wraps existing back end functionality. This application can then be adapted, if desired, and used to serve direct client access or embedded within a remote application redistributed by a business partner. In the case of the latter, the distributor would be able to establish a brand centric view of the application for its clientele by adapting the look, feel, content, flow, and functionality of the application as needed. Besides achieving application syndication with WSXL for presentation purposes, the provider's application can also have direct control over events raised by interactions at the browser. Moreover, reliance on widely adopted open specifications will eliminate the need to develop (or purchase) and maintain solutions that do not have as diverse of a usage model as WSXL applications. 1.5.2. Distributed Visualization Services (Remote Portal) Similarly, we have the scenario depicted in Figure 3 whereby a supplier of financial graphics utility services enables the redistribution of these services. A portal company could in this case augment the utility service with a branded data input form. This approach would enable quick enhancements to the portfolio of portal services at a low cost of entry. 1.5.3. Distributed Visualization Services (Local
Portal) 1.5.4. Value Added Reselling of Traveler Checks Our last scenario, depicted by Figure 5, suggests how WSXL could be used to create new revenue generating applications. In this case the application domain represents the selling of Traveler Checks. However, the bank in this case is a value added reseller since it seeks to enhance existing application assets of their business partner (the Traveler Check Supplier) with a new payment instrument, specifically debit. In order to achieve this goal the bank needs to create a new application with a user experience that is unique to the bank. Using WSXL, the bank can achieve this by integrating the remote application of its business partner with a locally available application that addresses the handling of debit transactions from bank member accounts. In this scenario, the Traveler Check Supplier may, but need not, implement a new service operation that allows the purchase of the checks to be captured and settled out of band. WSXL offers a declarative language that allows collections of service interfaces to be grouped into reusable components that produce discrete units of work and can be used for business-to-business and application-to-application integration. WSXL is an enabling technology that makes it possible to achieve the business objectives in a timely and cost effective manner. 1.6. A Standards Initiative for Web Services Experience
Integration Facilitates interoperability among disparate delivery channels. In particular, the approach must not impose a particular runtime model and must enable applications to be deployed easily for delivery through various channels. Supports adaptation of Web applications. In particular, a Web application must be easy to "brand" and "co-brand" for the purposes of syndication. Supports aggregation of Web applications into a larger user experience with no or minimal programming. Provides for tight and fully customizable integration between Web applications, resulting into a seamless user experience. Enables applications to be changed or modified easily. For example, business professionals must be able to quickly deploy and test new business models. Moreover, these objectives must be met by reusing existing and de facto industry standards - in particular, XML based standards such as XPath, XML Events, DOM, XForms and XLink as well as Web Services standards such as SOAP, WSDL and WSFL. We believe that a combination of Web service based function and declarative specification of integration between such services will ensure broad acceptance across a wide range of constituencies. 2. Web Services Experience Language 2.1. Introduction to the WSXL Framework
A WSXL base component has portTypes for basic inquiries, life cycle management, action handling, and the generation of output markup. The life cycle operations can be used to explicitly create and destroy instances of a WSXL base component. Associated with a WSXL base component may be an Adaptation Description, which describes how the markup generated by the component may be adapted to new channels. The intent behind factoring a web application into separate data, presentation, and control components is to facilitate the reassembly of multiple alternative versions of the components in order to meet the requirements of separate channels, users, and tasks as outlined in the introductory requirements section above. As a result, WSXL will support the ability of web developers to assemble applications from data, presentation, and control components provided separately by independent vendors. A couple of key reasons for factoring the overall design into a base component and extensions of that base component are: Facilitating the convergence between WSXL and other web services centric presentation component models. Enable an easy migration path from todays web application frameworks into a Web Service framework using the base component and then into an easily composed Model-View-Controller framework. WSXL interfaces are described using the Web Services Description Language ( WSDL ). WSDL allows for a language-independent definition of the types, messages, and operations in a component's interface. WSDL separates these interface characteristics (the service's portTypes) from the bindings of the portTypes to a particular transport mechanism. Many web services are accessed remotely over the network using SOAP messages. In other cases, components may be executed locally and use higher performance "transport" such as direct method invocation. We intend the WSDL definitions in this document to be interpreted independently of whether the WSXL components described are to be accessed remotely or locally. WSXL Adaptation Descriptions can be expressed using the Adaptation Description Language described in this document. We separate the Adaptation Description Language from the Web Services Description Language to allow a component interface to be associated with a choice of Adaptation Descriptions. 2.2. Component Descriptions 2.2.1. Base
Component The base component in WSXL specifies the portTypes that are common for all WSXL components: basic inquiries, lifecycle management and generation of output markup. Other WSXL components, including data, presentation and control, implement these base portTypes as well as the particular portTypes required for their functionality. Base Component PortTypes The categories of interfaces of a WSXL Base Component are shown in Figure 6 and include: Inquiry: This portType provides basic inquiry operations that allow a client to request the WSDL service description document (particularly useful when the service was not discovered through UDDI) and inquire whether or not a particular portType is supported. The normative WSDL for this portType can be found in Appendix A. portType: WSXLServiceDescription getServiceDocument() - This operation provides the hasPortType(portTypeName) - This operation returns a Boolean
In reviewing recent WSIA documents, we note that this portType provides the operations to support requirements 7.4.3 and 7.5.1 from the Embedded Use Case and R301 from the Requirements document. Lifecycle: Both components and collections need to manage their Lifecycle and provide clients with means to indirectly refer to particular instances in subsequent calls (This need is related to the stateless character of WSDL services and should be supplanted with WSDL support for stateful services when that support becomes available). We therefore introduce the concept of a 'Handle' as a remote reference to an instance of the service and define basic operations to create, and destroy these instances. These Lifecycle operations are defined in the portType "WSXLLifecycle" whose normative WSDL can be found in Appendix A. portType: WSXLLifecycle createInstance(propertyList)- This operation destroyInstance(handle) - This operation Property management: A WSXL component must implement property management operations whereby clients can modify properties at times other than initialization. These operations are defined in the portType "WSXLProperties" whose normative WSDL can be found in Appendix A. portType: WSXLProperties setProperties(handle, propertyList) - This provides getProperties(handle, nameList) - General means for getPropertySchema() - This operation In reviewing recent WSIA documents, we note that this portType provides the operations to support requirements 7.5.2, 7.6.1, 7.6.2, 7.6.3, 7.6.4, 7.6.5 and 7.6.6 from the Embedded Use Case and R301, R302, R303, R401 and R403 from the Requirements document. Output: Operations related to the markup for the service. The normative WSDL for this portType can be found in Appendix A. portType: WSXLOutput getOutput(handle, propertyList) - This operation invokeAction(handle, actionName, propertyList) - This operation
In reviewing recent WSIA documents, we note that this portType provides the operations to support requirement 7.8.1 from the Embedded Use Case and R701 from the Requirements document. In general, a component may expose only a subset of its design externally -- by using an interface specification that reflects a restricted component structure and behavior intended for controlled extension or integration rather than the full underlying implementation. 2.3. Adaptation Description Language To this end, WSXL includes an extensible Adaptation Description Language where explicit locations of adaptation points, the permissible operations on adaptation points (e.g. insert, delete, modify, ...), and the constraints on the contents of adaptation (e.g. via an XML Schema) can be specified. The Adaptation Description Language can be used during a post-processing step where the output of a WSXL component can be adapted independently without invoking the component. The core concept of this description language is the notion of an Adaptation point. Adaptation points are a means of specifying how a particular user experience can be adapted to the channel through which it is delivered to the end user. Adaptation points define "observable characteristics" of a presentation stream, and as such, they are analogous to and complementary to message types. Adaptation points are used at design time, by both the application provider and the intermediary, to speed development and help ensure correctness. Further, they are used at runtime, by supporting middleware, to safely perform the adaptations requested by an intermediary. For example, a provider can specify Adaptation points that allow a client use the information to reliably: Change background color or font variable used by the application [Presentation adaptation] Lookup a value in the output markup (e.g. an embedded product ID) [Presentation adaptation] Overwrite/Add to a value in the output markup (e.g. a price) [Data adaptation] Insert a value in a particular page (e.g. an extra text field, a new column in a table) [Presentation and possibly Control adaptation] Override/extend the action associated with an action(e.g. button press) [Control adaptation] Adaptation Points are part of a WSXL component definition. Each Adaptation Point specifies: An application-specific Adaptation Point name The kind of operation (insert, replace, lookup). Specifies the adaptation's intended use. The names of pages, i.e., to the different component's outputs, that it applies to. Optional. This information is used at design time and in low cost runtime implementations. A locator to the item[s] of interest. For instance, xpath, xquery are used for XML documents. Note that a locator can point to multiple locations in document. An Adaptation Point category (XML, CSS, etc). Specifies the category of the item[s] of interest. The information specific to the application of an adaptation of that category. Tooling Hints As part of defining ports in the context of a service definition, a WSXL port can optionally specifiy an attribute named adaptationURI. An example of specifying the adaptationURI is as follows: <service
name="LeatherShopService"> The adaptationURI refers to the adaptation description file for the port. The root element of the adaptation description language is an Adaptation group which can consist of a combination of Adaptation Groups and Adaptation Points. AdaptationGroups are elements solely for application-specific organization of exposing adaptation points. The following categories of adaptations are initially introduced: XMLAdaptation CSSAdaptation These two have been introduced to handle the manipulation of two typical contents of messages i.e., CSS and XML. Other categories can be introduced into the language as necessary. To allow a provider to assist or control the markup inserted by an aggregator, a concept of adaptation generator is introduced. An AdaptationGenerator is an operation on the provider service that can be invoked by clients to request customized markup for inclusion in the provider service's output message stream. 2.3.1. XMLAdaptation <adaptation name="CustomerNumber"
use="lookup"> In the above example, the provider is specifying an adaptation for lookup for data items present in the output stream of a presentation component and indicating that the type of the value would be an integer. <adaptation name="ContactInfo"
use="replace"> In the above example, the provider is specifying an Adaptation Point to allow the replacement of the contact information in its output stream with the constraint that the replacing XML fragment should match one of the two specified types. The type description is available in the file at the URL specified in the schemaLocation element. As the last example, a data component provider may wish to allow a client to replace an item's price in dollars by an equivalent price in different currencies. However, the provider wishes to express a constraint that the price inserted should obey certain constraints. <adaptation name="PriceColValues"
use="replace"> 2.3.2. CSSAdaptation <adaptationGroup
name="changeLookAndFeel"> In this description fragment, the adaptationGroup has only one Adaptation Point, which provides information to aggregator about how the background color of a XHTML table can be adapted. The name attributes have only human significance. The "use" attribute on the adaptation specifies that a client can perform a replace operation on the item specified within the adaptation element. The outputList element consists of names that identify the subset of the different outputs to which the Adaptation Point applies. The locator element specifies where in the component's XML portion of the output the item of interest can be found while the CSSAdaptation specifies the CSS qualifying locator that identifies the specific attribute of interest. In this case the values in the property element must match one of the properties in the CSS specification. Note that CSSAdaptation are for dealing with inline CSS attributes only. All other "out-of-band" CSS specifications can be adapted by taking advantage of CSS specification by inserting a pointer to the CSS style sheet as "close" to item of interest as possible and leaving it to mechanics of the CSS applicator to apply them correctly. 2.3.3.
AdaptationGenerator For providers to provide assistance in creating markup for the aggregator for use in adaptation. To retain control over markup fragements that are inserted To sidestep the limitations of the constraint language. A provider service implements these AdaptationGenerator operations and includes their names as part of the AdaptationGenerator specifications. These operations are invoked by a client to perform presentation related transforms and use the resulting message in adaptation. Here is an example of a provider implementing an operation named "addColumnToXHTMLTable" and includes it within an AdaptationGenerator construct. <adaptation name="addColumnAtEndOfTableA"
use="replace"> The exact signature of the name specified in an AdaptationGenerator is obtained by looking at the WSXL specification of the service. It is expected to have an input message that consists of two parts: a) a portion of the message originally sent down by the provider or locators that point into the message, b) the presentation and/or content that the client wishes to be added to the provider's message portion. The output signature would be a that of a message that can contain any instance that can accomodate the client's content. 2.4. Creating Applications from WSXL
Components 2.4.1. Reusable Groupings of
Components The object implementing the WSXL Collection described in the section above may further implement the WSXL Component interfaces to allow the grouping to be reused together with other WSXL components. Figure 7 shows the interfaces that are exposed by such aggregate WSXL Components. As is true of all WSXL Components, this interface includes the WSXL base interfaces (Inquiry, Lifecycle and Output), along with any nested data, presentation, control, and application specific interfaces that are re-exposed by the grouping. Note that in this discussion even though we use the terms data and presentation in the singular, and show them as single icons in the figure, in general either data or presentation may consist of multiple instance fragments -- the controller supports reference to any number of fragments on either the data or presentation side. Components may be instantiated, and these instantiations assembled to create new aggregations. Such aggregations can be created from instances of different types, e.g., as in the earlier data/presentation example, or from instances of the same type, e.g. aggregating multiple data instances. For example, two data components being aggregated using a WSXL control component to produce an aggregated data component. The creator of such an aggregation can in turn implement the Component interface to enable this new aggregation to be used as an atomic data component in another composition such as the one above in Figure 7. 2.4.2. Multi-modal Coordination of
Components 2.4.3. Flow of Control Across
Components However, if a page-level Collection also implements the Component interface, it can be composed into a Collection. In fact, several of these page-level Collection/Components can be grouped together into a Collection. This Collection is much more interesting as an application since it has more than one "page". The interesting question to answer at this point is how does a Collection define and execute its behavior? How is the navigation between and among Components defined? The WSXL architecture defines the Control Component as having this responsibility. WSXL does not specifically provide a language for describing macro control, but rather relies on a pluggable architecture that allows a variety of implementations. Some examples of macro control implementation in a Collection are: Procedural code such as Java that initializes and executes components in the desired order. A rules engine. A WSFL flow engine. A state machine. Depending on the strategy chosen, a Collection could externally publish its behavior. For example, a Collection could publish its behavior in terms of a WSFL flow model. This would allow queries both during development and at run-time. Development-time queries on a macro flow may be useful as a form of documentation for a programmer developing a cooperating application. Run-time queries on a macro flow may be useful for determining allowable next steps. Furthermore, an architecture that supports externally defined control flow allows applications to be very agile with respect to changing requirements. While WSFL is intended to publish and orchestrate the interactions of web services with each other in order to accomplish a particular task, we are particularly interested in the definition of flow models. A flow model is a directed, a-cyclic graph, which describes a business process. The business process is described in terms of activities that are connected by data links and control links. These links connect activities together and thereby define their order of execution. Conditional expressions on control links are used to implement conditional branching among the activities in the graph. Another interesting point about flow models is that they can be recursively composed. Therefore, a flow model can invoke another flow model as a child activity. This enables a functional decomposition of an application that promotes re-use. In a WSFL flow model, an activity represents an operation on a web service. WSFL flow models can be applied to the Macro Control Component if we establish that an activity maps to an operation that starts and executes a Component. The flow model can therefore be used to describe the order of Components within the Collection as well as conditional branching among them. Since WSFL is meant to orchestrate web services, this applies nicely to WSXL because each Component has a well-defined WSDL lifecycle interface. Thus, an activity defined on a flow model can invoke the operation that kicks off the Component. During the Component's execution, the Control Component determines the completion status of the Component via its event handlers. The flow model evaluates completion status for the Component (activity) to determine whether to repeat the activity or proceed to the next activity in the flow. 3. Web Services For Remote Portals
(WSRP) Remote Portlet Web services can be published into public or corporate service directories (UDDI) where they can easily be found by intermediary applications that want to display their content. Web application deployment vendors can wrap and adapt their middleware for use in WSRP-compliant services. Vendors of intermediary applicatios can enable their products for consuming such services. Using WSRP, portals can easily integrate content and applications from many internal and external content providers. The portal administrator simply picks the desired services from a list and integrates them; no programmers are required to tie new content and applications into the portal. To accomplish these goals, the Remote Portlet Web services standard defines a web services interface description using WSDL and all the semantics and behavior that web services and consuming applications must comply with in order to be pluggable as well as the meta-information that has to be provided when publishing Remote Portlet Web services into UDDI directories. The standard allows Remote Portlet Web services to be implemented in very different ways, be it as a Java/J2EE based web service, a web service implemented on Microsoft's .NET platform or a portlet published as a Remote Portlet Web service by a portal. The standard enables use of generic adapter code to plug in any Remote Portlet Web Service into intermediary applications rather than requiring specific proxy code. Remote Portlet Web services are WSXL component services built on standard technologies including SOAP, UDDI, and WSDL. WSRP adds several context elements including user profile, information about the client device, locale and desired markup language passed to them in SOAP requests. A set of operations and contracts are defined that enable WSRP plug-n-play. 3.1. Remote Portlet Web Services and
Portals 3.2. Publishing, Finding and Binding Remote Portlet Web
Services 3.3. WSRP and WSXL By standardizing the complete interface and behavior for compliant services and client applications in addition to what is standardized in WSXL, the Remote Portlet Web Services specification enables plug-n-play interoperability between any compliant client application and Remote Portlet Web services, so that client applications can invoke Remote Portlet Web Services always using generic invocation code. WSXL provides a generic set of basic interfaces for lifecycle and presentation. WSRP implements and extends selected WSXL interfaces and provides a specialized interface to its services. WSRP is designed so that implementing a compliant service is as easy as possible, services are extensible and interfaces can be efficiently accessed. For interoperability, WSRP services not only provide specialized and efficient access through the WSRP interface for WSRP clients like portals but also provide generic access through the WSXL interfaces for WSXL clients. We envision the following relation of WSRP and WSXL: WSRP services must implement the basic WSXL interfaces WSRP services must implement the WSXL markup interfaces WSRP services should implement the WSXL property interfaces 4. Web Services Experience Language By Example:
Implementation Details 4.1. Syndicated Purchasing of Traveler
Checks As depicted in Figure 8, the provider can describe a WSXL application that can then be used to serve direct client access or as the business logic within a remote application re-distributed by a business partner. In the case of the later, the distributor adds an additional WSXL Presentation Component with two functions: (1) to adapt the presentation of the provider's application to the requirements of the distributor, and (2) to add any additional presentation elements required for new functionality introduced by the distributor. In this scenario, the distributor simply establishes an alternative brand view of the application for its clientele by varying the skin of the provider's presentation. The presentation component at the distributor level, therefore, generates its own output markup perhaps by applying different XSLT or CSS style sheets. Besides achieving application syndication with WSXL for presentation purposes, the provider's application can also have direct control over events raised by interactions at the browser. In implementation terms, the distributor's presentation component delegates all events received from the client to the provider for interpretation within the provider's control and data context. 4.2. Distributed Visualization Services (Local
Portal) If implemented as a local portal, as described in this section, the presentation, data, and control components introduced by the distributor can be managed by a simple WSXL Collection. In order to support remote access through a second tier distributor -- i.e. as a remote portal -- then this grouping would in turn implement the WSXL Component interface to allow for remote binding and interaction. 4.3. Value Added Reselling of Traveler
Checks In order to achieve this goal the bank creates customized presentation layer by integrating the remote application of its business partner with a locally available application that addresses the handling of debit transactions from bank member accounts. The local application consists of a WSXL Presentation component to capture the specific user information required for the debit transaction. The local WSXL Control component then contains an event handler to pass this information to a bank-hosted debit application implemented in whatever technology is appropriate for the bank. Since the debit transaction does not involve further end-user interaction it is itself not a WSXL application. Note, however, that the WSXL Control component that initiates this debit is required also to notify the provider's Control component that a transaction has been initiated so that the provider's application can proceed to the appropriate next step of acknowledgement or termination. 4.4. WSXL and Macromedia Flash Figure 11 demonstrates a WSXL application producing Macromedia Flash content. Figure 12 demonstrates a WSXL application interacting with a Flash Presentation Component. In the example shown in Figure 11, the WSXL Presentation component is moved to the client in order to support direct generation of presentation using the Flash runtime engine. The Flash runtime is implemented inside a WSXL Flash Presentation Component as an extension of the base WSXL Presentation Component. As such, the WSXL Flash Presentation interfaces include the base WSXL Component interfaces for DOM access and events (shown in red in the Figure), and the standard WSXL Presentation interfaces (shown in blue). The WSXL Flash Presentation component defines additional interfaces (shown in yellow) to support Flash specific functions such as display and physical interaction with the user. WSXL components may execute on any tier of the network, and use W3C DOM Events to signal changes between them through arcs established by WSXL Control Components. In the figure, the WSXL Flash Presentation Component interacts with the remainder of a WSXL application through control links established by a WSXL Control Component. Data can be provided to the Flash presentation, and results returned from it, by receiving and raising events on these links. Changes in the interaction state of the flash presentation can also be signaled using events in order to synchronize the behavior of the flash presentation with non-flash parts of the user interface that may also be present. 5. Summary 6. Appendices 6.1.2.
WSXLServiceDescription 6.1.3. WSXLLifecycle 6.1.4. WSXLProperties 6.1.5. WSXLOutput 6.1.6. WSXLComponent 6.2. Appendix B. Advanced WSXL
Services portType: WSXLEventSource This portType allows clients to attach listeners interested in notification when an event the component has defined in its WSDL is dispatched. Means are also provided (in a separate portType) for handling events generated by other components such that an instance of a Control Component may cause this operation to be triggered at appropriate times. (Note: If events and event processing become defined for WSDL services in general, these portTypes should be revised to adopt the WSDL definitions). queryAvailableEventTypes(handle)- This operation addEventListeners(handle, listenerList) - This operation
removeEventListeners(handle, listenerList) - Clients should
portType:WSXLEventSink handleEvent(eventSourceHandle, eventType, eventInstanceDoc) -
This In addition to the WSXL base component and event oriented portTypes described above, the WSXL data component implements portTypes used to describe and maintain instances of DOM- accessible data in WSXL applications. The WSXL data component is based on the data functionality in XFORMS, and includes both XFORMS model and instance functions. WSXL data components may be connected to data sources external to WSXL applications, but this is an implementation detail that is beyond the scope of WSXL. Data Component Interfaces The additional categories of interfaces of a WSXL data component are shown in Figure 13 and include: Access: (Required) A WSXL data component describes the structure it wishes to expose using a flattened and subsetted version of the DOM Level 2 interface. Access: (Optional) A WSXL data component may expose the full flattened version of the DOM Level 2 interface to provide richer semantics for accessing its data structures. UpdateControl: (Optional) These operations are used to mark the start and end of a group of updates. Use of this portType is optional, at the discretion of the collection. Default behavior is to raise change notification events synchronously with each update. Validation: (Optional) These operations are used to trigger evaluation of type constraints between the data instance and its model. They are a part of any data component which supports the XFORMS model interface. Recompute: (Optional) These operations are used to trigger evaluation of side effects from updates elsewhere in the data. Result is to call any handlers that are part of the internal implementation of the data component, i.e. those that will not be evaluated as a result of evaluating external control links (see control component below). These operations are also part of a data component supporting the XFORMS model interface. DataAvailability: (Optional) These operations are used to signal the availability of the component's instance data. While the way in which the component connects to external data is not itself standardized, states associated with that data connection could be, such as unconnected, data requested, data partial and data available. Notes WSXL defines a processing model, which may be implemented by a WSXL collection, for applying updates to components it manages and for managing the steps required to flush updates to other components bound with WSXL control components. The specific event handlers that implement updates among a collection's components are defined using the control component. How might we implement states associated with data such as error, input, default, valid? How is this connected with the XML processing model, not just XFORMS processing model -- how does this connect with WSFL? It is an open issue whether XFORMS metadata, including relevance and required attributes, should be carried on a WSXL control component grouped together with the associated data component in a WSXL collection, or on the control component that links data directly to presentation. We prefer a separate control component linked to data since if we put those model constraints on the arc linking presentation to the model, we will have to duplicate them for each presentation component we bind to the data. Starter set of components -- simple wrapper for web service, allows declarative creation of a WSXL data component; simple collection for aggregating data components. Tooling could expose as drag/drop metaphor in visual editor. 6.2.2. Presentation Component Presentation Component portTypes Beyond the base component portTypes, the additional portTypes of a WSXL presentation component are shown in Figure 14 and include: Access (Required): A WSXL presentation component describes the structure it wishes to expose using the WSXLDOMLite portType as defined above for data components. Interaction (Required): used to indicate state of end-user interaction with elements in the presentation component, such as focus, selection, activation, execution, hide/expose. Draws on and extends the abstract UI events in DOM Level 2 event model . Physical events such as mouse probably of less import to server-side components. Keyboard events required. 6.2.3. Control
Component As shown in Figure 15, the WSXL control component is an extension of the WSXL base component as are the data and presentation components. In addition to the base WSXL component and event oriented portTypes, the WSXL control component implements portTypes used to manage the arcs binding data components to presentation components, to parse and interpret the XLINK -based control language specification described below, and to implement a processing model that controls the propagation of event notifications in both directions between data and presentation. The basic control model is illustrated in Figure 16. The control component, either in response to the invocation of its arc management portType, or by parsing and interpreting a control language specification, establishes arcs between components, generally one being a data component and the other a presentation component. Each arc consists of an object that is a listener to a given element on the data component and to another element on the presentation component. The control component establishes arcs and maintains itself at runtime to manage the order and timing of event notifications in each direction. Control component implementations may support directly connecting the endpoints of an arc, but will then need to deal with inserting themselves when operations to control the order and timing of event propagation are invoked. Event handlers can be associated with arcs to provide control logic triggered in response to event notifications. This between-component, or "micro-level" control logic may (1) modify the values or structure of the data and/or presentation components, (2) make calls to external services, and (3) interact with across-component or "macro-level" control to trigger the possible instantiation of additional WSXL components for subsequent steps in the application. It is important to note that micro and macro control logic are both triggered by events raised on arcs established and managed by a single type of WSXL control component. The distinction between them is simply in the nature of the changes effected by event handlers on those arcs. Event handlers that make changes within already instantiated and bound data and presentation components involve only micro-control logic. Event handlers that instantiate and bind new WSXL data and presentation components, or destroy existing ones and return to earlier steps in the application, involve macro-control logic. We expect that macro-logic may commonly be implemented through use of flow-language (e.g. WSFL) specifications invoked by event handlers on WSXL control components. Control Component portTypes Beyond the base component portTypes, the additional portType of a WSXL control component are shown in Figure 15 and include: Arc definition and management: (Required) These operations are used to create new arcs by providing source and destination component instances, XPATH locators within those instances, and event handlers to be associated with the arc. This portType supports operations to enumerate, create and destroy both locators and arcs. This portType can be called directly, or via the control specification language described below. The relevant standards for arcs include XFORMS, XLINK, and XML events. Control specification parsing: (Required) The WSXLControl specification includes a specification language enabling compliant control components to parse an XLINK-based control specification file and create locators and arcs using the interface above. This interface supports a declarative way of defining the behavior of the control component without driving the underlying programmatic interface directly. A schema for this specification language in included in Appendix D. Update processing model: (Optional) These operations are used to maintain list of "dirty" links, order list of updates and update groups, apply updates according to policies set by binding language (sync, async), fire event handlers on arcs. When this interface is not supported, events are propagated synchronously. Notes What is the need for multiple processing models? Portlets vs XFORMS vs batching, vs multi-modal? Will application authors in general define new processing models or should this be fixed? Perhaps in order to implement lazy vs greedy refresh? XFORMS does specify when sync should happen, and also defines the longest time when can be delayed. Checkpoints. Do the update groups require control component functionality, or are they just implemented by the data or presentation component? The update groups really correspond more to the UpdateControl concept above. This then requires an API within the Control component to support batches of updates. Control specification can bind to a number of different action languages: Java, Javascript, XML vocabulary like WSUI 6.2.4. Extensible Micro Control
Language Presume the following is contained within www.examples.com/presentation.html: <form id="Employee" . .
.>
<Employee> <BinderLinks
xmlns:ev="http://www.w3.org/2001/xml-events" <!--
First define the endpoints .... locators in XLink parlance
--> <!--
'parent' protocol indicates what follows is a locator's label
--> <loc
xlink:type="locator" <loc
xlink:type="locator" <!--
Now define the arcs between the endpoints
--> <bind
xlink:type="arc" <bind
xlink:type="arc"
<!-- validate the entered serial number prior to writing A couple of additional locators are declared relative to these two root level locators. The Micro Control Component will query the components referenced by the parent locators to resolve the supplied query string (in this case an XPath). The processing of the arc declarations will establish listener relationships between the referenced components and the controller using the DOM Level 2 Event API. The default event type is PropertyChange with a default action making the value of the endpoints of the arc equal. As can be seen from the last arc definition, both the event and handler can be declared using XML Event syntax. An extension is required to indicate which endpoint is the source of the handled event (the example specifies the input field with id='employeeNum' in presentation.html). These handlers may format the data during the traversal of the arc by returning a new value, abort the traversal by returning null, as well as any desired side effects (e.g. trigger a transition in the Macro Flow between components). 6.2.5. WSXL
Collections A WSXL collection provides an execution and management environment for WSXL components. It calls the lifecycle operations on WSXL components it instantiates, and implements a set of interfaces and a processing model for use by WSXL components and objects external to the collection. An object implementing the WSXL collection interface need not be a WSXL component. PortTypes A WSXL collection defines two categories of portTypes: required and optional. The hasPortType operation from the WSXLServiceDescription portType may be used to query which optional portTypes the collection implements. The collection portTypes are: Query: (Required) A Collection must provide standard means for querying the components and nested collections it is managing. The simple query interface (modeled after DOM NamedNodeMap interface) required of all collections is shown below. Hosting: (Required) Collections must provide a means to specify the components that are to be instantiated. The collection instantiates the component (may just be a local proxy to a remote service) and invokes operations on the component that are part of the initialization/lifecycle contract. Rather than defining an additional set of operations, setting a property named ?DefinitionsDocument? will result in that document being parsed and the components / nested collections specified by it being instantiated. An example of a DefinitionsDocument and the schema for them can be found in Appendix C. Management:(Optional) Once a component is instantiated, a collection may provide an interface that allows the component to request resources. An example of such a resource is display "real estate". A collection in turn decides when to remove a component and deallocate its resources. Environment and Context service: (Optional) This interface deals with how a component can find out details about the environment. Here the environment encompasses a) the details of specific configuration and the deployment platform in which the component has been instantiated, b) the details and objects of the specific session/context in which the component is being executed. The latter item includes APIs that deal with personalization (device information, user profile) etc. Event service: (Optional) A collection may support the WSXLEventSource and WSXLEventSink interfaces. Supporting these interfaces allows a component to register interest and handlers for events without having to know the existence of all components that may generate that event. This also provides decoupling between an event generator and event listener with the collection acting as a broker that controls the dispatch and propagation of an event. Component discovery and invocation: (Optional) A collection may offer an API where a component implementation or instance (local or remote) can be found at runtime based on some attributes of the component interface. Then the hosting API can be used either to instantiate the discovered component locally, or the component may establish a separate direct binding to the discovered component. Notes Making the requirements on a collection interface minimal results in making the collection writer's job easy. However, does it make the WSXL component writer's job hard? What tradeoff should we make? On a related note, should we subdivide the categories more to have more required and optional categories? Relevant Standards The newly started working group on XML plugins. Other standards/practices for conceptual input, some of them not in the markup domain, are HTML behaviours, netscape plug-in API, EJB Containers, Java AWT. 6.3. Appendix C. Collection Definitions
Document <WSXLComponent name="ChartUI"
role="Presentation" <WSXLComponent name="ChartData"
role="Data" <WSXLComponent name="ChartController"
role="Control" <!-- if more than one control
file is needed, just repeat the ControlFile
property: <ev:listener event="CollectionInited" handler="ChartData-InitHandler" type="javascript"/> </WSXLCollection> 6.4. Appendix D. Control Specification Language 7. References
如果您希望与本文章的作者或其所在机构，进一步交流，请联系：姜小姐 jill.jiang@amt.com.cn | 021-51096826-112 | 在线联系 |
 CIO职场，强者生存？在2008年，我们将继续看到CIO向商业运营方向发展。与此同时，我们也会看到商业管理人员将与技术管理人员一起竞争CIO岗位。 IT领导者的就职机会虽有不少，但其难度将会大幅提高。2……  防震减灾，IT当关今天，任何的防震救灾体系，都离不开IT技术。地震观测台是数字化的，震害防御需要对以往的地震信息进行数据分析，应急救援要需要现代多样化的通讯技术。如果说，在许多行业，信息技术还只是一…… |
|
|