[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bpel4people] Groups - HT-Architecture including rendering (HT Architecture v0-9-2.docx) uploaded
Dear Frank, As Alex and Phil have been commenting, this document spells out many architecture details clearly and it is excellent. I overlooked it before, but now I notice that the WS-HT document included <rendering> for purpose. Your document includes the better and most helpful explanation for the <rendering>, which is much clearer than the normative part (WS-HT CD-02, 4.4). (I always thought that the <rendering> was about the rendering of the Task metadata <presentation>. Confused. Now I understand that it seems you are not talking about implementing Tasks as remote Web services??? You are giving the Task UI definitions as <rendering> in HT definition and the Task Processor (or the Task Client) to manage/render the Task. WS-C is used between the Task Parent and the Task. I had a different notion that the Task had to be implemented by another Web Service, and the WS-HT was just a definition pointing to the EPR in the <interface>, since how to call the WS-HT itself from the BEPL4People process has been defined already. I understood that that was how the Task Parent called the Task pT to instantiate the Task. Also, I thought that the WS-C was for between the Task instance and the Task Implementation (which is another Web Service). In this scheme, one does not need to specify <rendering> like HTMLForm in detail. Only need to specify as <taskUI> i.e. it could be URL or EPR, where it is and how to call it, and the type. The Task Client will work it out the rest, if it can handle the types. Also, it is not still clear to me that how the "6 Programming Interfaces" is related with this. I thought that it was rather for the managing relationship between the Task Parent and the Task, and that the WS-C was used for other purpose. But I suppose that the Programming Interface manages the life cycle of the Task Parent in your picture??? Finally, could you please put the Task List Client in the picture as it has been described as below, so that we all could understand it better? That the Task be presented to a potential owners by the Task Client for claiming, in your description and the writing, is not correct. It has to be presented by the Task List Client, who later calls the Task Client for Task UI rendering. Best regards, Yoichi WS-HT CD02, R4 3.3 Task Rendering Humans require a presentation interface to interact with a machine. This specification covers the 721 service interfaces that enable this to be accomplished, and enables this in different constellations 722 of software from different parties. The key elements are the task list client, the task engine and 723 the applications invoked when a task is executed. 724 It is assumed that a single task instance can be rendered by different task list clients so the task 725 engine does not depend on a single dedicated task list client. Similarly it is assumed that one task 726 list client can present tasks from several task engines in one homogenous list and can handle the 727 tasks in a consistent manner. The same is assumed for notifications. 728 A distinction is made between the rendering of the meta-information associated with the task or 729 notification (task-description UI and task list UI) (see section 4.3 for more details on presentation 730 elements) and the rendering of the task or notification itself (task-UI) used for task execution (see 731 section 4.4 for more details on task rendering). For example, the task-description UI includes the 732 rendering of a summary list of pending or completed tasks and detailed meta-information such as 733 a deadlines, priority and description about how to perform the task. It is the task list client that 734 deals with this. 735 The task-UI can be rendered by the task list client or delegated to a rendering application invoked 736 by the task list client. The task definition and notification definition can define different rendering 737 information for the task-UI using different rendering methodologies. 738 Versatility of deployment determines which software within a particular constellation performs the 739 presentation rendering. 740 The task-UI can be specified by a rendering method within the task definition or notification 741 definition. The rendering method is identified by a unique name attribute and specifies the type of 742 rendering technology being used. A task or a notification may can have more than one such 743 rendering method, e.g. one method for each environment the task or notification is accessed from 744 (e.g. workstation, mobile device). 745 The task-list UI encompasses all information crucial for understanding the importance of and 746 details about a given task or notification (e.g. task priority, subject and description) - typically in a 747 table-like layout. Upon selecting a task, i.e. an entry in case of a table-like layout, the user is 748 given the opportunity to launch the corresponding task-UI. The task-UI has access to the task 749 instance data, and may can comprise and manipulate documents other than the task instance. It 750 can be specified by a rendering method within the task description. 751 -------------------------------------------------------------------------- Yoichi Takayama, PhD Senior Research Fellow RAMP Project MELCOE (Macquarie E-Learning Centre of Excellence) MACQUARIE UNIVERSITY Phone: +61 (0)2 9850 9073 Fax: +61 (0)2 9850 6527 -------------------------------------------------------------------------- MACQUARIE UNIVERSITY: CRICOS Provider No 00002J This message is intended for the addressee named and may contain confidential information. If you are not the intended recipient, please delete it and notify the sender. Views expressed in this message are those of the individual sender, and are not necessarily the views of Macquarie E-Learning Centre Of Excellence (MELCOE) or Macquarie University. On 25/05/2009, at 4:31 PM, Frank.Leymann@informatik.uni-stuttgart.de wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]