软件工程外文英文文献翻译面向逻辑框架的WEB编程

单位代码 01 学 号070112058 分 类 号 TP393 密 级_ _ _文献翻译面向逻辑框架的WEB编程 院（系）名称信息工程学院专 业 名 称软件工程学 生 姓 名指 导 教 师 黄河科技学院毕业设计(文献翻译) 第 7 页 英文译文面向逻辑框架的WEB编程朱利奥，安德里亚，恩里科摘 要万维网作为一个开发平台尽管流行，但是设计一个恰当描述它的结构原则和设计标准被确立仅仅在过去十年里，通过引入代表性的状态转换构造风格，其定义了以资源为核心的抽象信息。被用的语言和工具作为 Web 程序规划，通常很难理解缺乏适当它的结构和设计的拘束，从抽象不匹配，使其难以充分利用网络的潜力。叙述式语言适当的为编程系统瞄准一个的合适网络架构和原理。在逻辑技术中，tuProlog 已经明确地被设计是以英特网为基础的基础设施的促成元件之一:其工程特性在web,在运行时间内允许适当的修改逻辑编程资源。因此，本文中我们提出一个开发基于这个模型的设计Web资源和概述一个框架web应用程序的 Prolog的逻辑模型。关键字：万维网，语境，tuProlog，Prolog1 介绍尽管流行的网络平台的开发和实现多以互联网为基础的系统，但设计了一个恰当的描述网站的设计原则和建筑标准仅仅在过去十年里已经达到，通过引入代表性的状态转换(其他)结构风格为超媒体系统1。以其他资源为重点，定义了抽象的信息沟通和互动,规定在资源发生时，通过一致的接口转换代表性的资源现状。然而,从早期程序上的CGI脚本到现代的面向对象的框架，web应用程序编程一直集中在不同的抽象概念上，如页面6、控制器15和最近的服务器11，从而面对不协调，使得很难开发可能的网站结构特性。事实上，一个网页是计算涉及一个或更多资源的结果，并且处理结果仅仅在表现问题的客户端；另一方面，一个控制器恰好是(仅仅)一个程序框架的抽象，共享几乎没有任何其潜在的网络平台。相反，忽视网络标准如URI和HTTP，因此他们从不获得利益而言，其余架构依据可缓存性、连通性、可寻址行、一致性和互操作性14。作为一个事实, 声明程序设计在网络逻辑语言的主流中从未被接受，尽管研究人员表示他们能有效地处理基于网络环境1的沟通和协调和逻辑技术已经成功用于智能设计元件为核心的网络基础设施2。然而，其余的集中在以资源再现为主要驱动的相互作用，并给出了相应的网络计算模型，在架构以资源为目标的应用程序中声明语言能发挥了重要的作用。利用元素的优势从逻辑编程语言比如Prolog既有代表性的基础网络计算模型：一个资源的声明可以被操作，在子句开始并给出了程序的解释，在资源涉及到运算时直接被解释器执行。在本文中，我们讨论一个资源编程模型、Web逻辑编程(WebLP)13，把与元素与之相适应的逻辑范例和逻辑技术相结合 (例如tuProlog引擎2)，来定义一个Web应用程序框架释放快速原型当支持网络架构特性比如可扩展性和可变性。2 WEB逻辑编程WEB逻辑编程(WebLP)13是一种基于Prolog的逻辑模型，其应用于系统约束的万维网架构的交互作用。 起初网络逻辑编程描述的事其主要的数据类型抽象，然后定义它的计算模型。2.1 资源定义了一个资源，为任何其他概念的目标的超链接文本。任何信息，那可命名为是一种资源，包括虚拟(如文件)及不是实质上(例如一个人)的物体。从如此抽象的定义、主要性质的资源可以很容易地确定：一个名字(URI的形式)；数据代表着资源状态和行为，以用来改变的状态或管理与企业的其他资源的交互作用。在界定的资源可以轻易的将元素映射到元素的逻辑编程语言，比如Prolog：对于每个资源R，其名称N(R)可以被指定为单一资源的URI引用原子含有标识符，当数据和行为可以进一步确认为事实和规则，分别在一个逻辑理论T(R)包含了知识库相关资源。特别地,如果它是描述性的名字，采用资源在可预知的方式14中有明确的结构变化，它们有一个共同的特征是一个有趣的特性，对他们自己的：任何路径，可以解释为包括一套资源的名称。证明这条线，我们说一个资源的名字，如：http : /涵盖的其他资源的名字也就是说，那些可能相关的项目包括提高子路径域的根源URI:http : /http : /http : /We denote this by writing:N(R) N(R1) . . . N(Rn)每个N(Ri)是指相应的资源Ri。这个命名结构强调资源并不是孤立的，而是在一个信息化环境中由资源相关资源的名字里面的名字。为了说明网络计算的复杂性，可能涉及的信息比它是封闭在一个隔离资源更多，上下文C(R)介绍了消失的计算与相关各资源。这样一个背景下，然后是定义所组成的理论与之相关联的名字是资源与资源的名字里面的理论，包括与之关联的资源本身。因此，比如，上下文C(R)向关联的表示以上资源R命名为N(R)产生：C(R) = T (R) T (R1) . . . T (Rn)任何理论T(Ri)，含有知识库相关资源的Ri，可以为空例如，当没有实体实际上有关的名字N(Ri)。2.2 计算模型根据WEB计算模型围绕交易的HTTP协议。每个事务都从一个请求开始，含有WEB计算的两个主要成份：方法信息，表明寄件人如何期望接收器处理应用，范围信息，表明部分数据集接收器将申请方法14。该方法在Web中，信息都包含在这HTTP请求的方法(例句GET, POST)和范围的信息资源的URI是要定向请求。网络计算的结果是一种响应，告知请求成功或失败，随机包含表示新状态的目标资源。采用一种逻辑编程计算模型，每个网络 HTTP协议的要求可以被解释为一个推论信息映射到目标的范围和方法理论，信息发布到了一个适当的逻辑目标。然后，计算在服务器端发生HTTP协议，在语义中联系目标资源的请求。目标信息的解决方案是造成最终翻译转化为一个合适的陈述，返回HTTP响应。它允许用户调用它，而目标计算的一种资源R触发G的演绎成G对语境C(R)。这篇构图的理论形成C(右)然后经过一个非常类似的方式作为单位在语境的逻辑编程(CtxLP)中9。目标G依次询问每个理论: 如果没有找到任何理论解答，这个目标失败，或一旦解决了利用知识库中的一种理论T(国际扶轮)则成功。此外，在理论中当目标G被子目标替换成相匹配的规则，计算所得的理论从C(Ri)而不是从最初的上下文被重新启动。这一现象的原因可能的选择是，如果计算已达到C(Ri)，必要的信息以继续进行，最有可能出现在别的任何地方因为它是典型的假定语境逻辑编程8；然而，不同的操作(例如，延迟绑定策略)需要的时候也可以很有用。例如,让我们考虑一个书架共享应用,在用户jdoe的书架是由URI确定 books/1最终是调用在B当一个获取请求签发这个资源。如果断定挑选取biology books/1依赖于选择books/3确定是拿书在B或是S，理论上是C(B)越过向后的资源，作为描述，如图1，在那里一个合适的定义来取books/3并最终找到。根据上述(期望)策略，定义为其他属性调用然后从上下文的根源，而不是C(B)，在该计算最初开始。图1书架上的jdoe/shelf/biology得到响应HTTP请求而最终调用选biology book/1，依次挑选书籍books/3。语境是直到恰当定义，因为它是发现在这里，在这个/资源。值得注意的是，无论如何，不像语境逻辑编程，它可能将或流行单位在运行时从上下文堆栈，固定结构的URIs为资源标识符使组成的理论形成了一个上下文是静止的。此外，结构的标识符、资源的网络架构的高低决定了独特的方向理论的相关资源组成了一个上下文可以穿越那就是，从最外层(与之关联的资源在计算已被调用)到最深处，经过理论属于每个组成资源,直到主资源是最后参与。2.3 动态资源特性资源特性动态下可以看作是两个独立的方面。首先，两个或两个以上的URIs可以表示在任何时间相同资源的联系：即名字为N1(R)、，Nm(R)可确定为同一资源R，因此同样的知识库中包含T(R)相关理论的资源。每一个不同的名字的Ni(R)也用来识别不同环境下的Ci(R)，同一资源R可能经历在里面(见图2)，因此，判断应用于T(R)但未定义行为有可能以不同的方式给出定义，通过上下文资源是访问。图2逻辑理论问题的一种资源代表销售额为2004年第四季度的可被两个不同的名字识别，因此住进两个不同的上下文环境。第二个动态方面的资源来自于行为规则的表达能力，一个逻辑编程语言的抽象：一方面，众所周知逻辑机制规定操作(the assertz/1 and retract/1判断)可以被利用，改变知识库的相关资源；另一方面，HTTP协议本身通过PUT请求的方法允许改变一个资源，其内容应考虑作为一种经过改良的目标资源来代替(或合并)最初版本居住在服务器上的资源。例如，让我们想象一个阅读期望列表在之前的书架上的应用。通常，当新增加一本书，该资源代表着希望的列表可以检查当地图书馆的图书的有效性，并可能借它用户的身份：如果没有找到书，这个资源可以检查其在网上书店可用性、应为用户将来采购报告其价格。然而，在销售时间，当一个网上书店提供折扣，期望清单资源应该对插入的新书首先检查储存。实现这种功能，网络应用程序然后能被指导去改变行为的期望清单资源的请求，签发HTTP把修改计算表示这些资源。这将要求将进行新规则的内容，所以期望清单会修改他们的知识库资源进行相应的调整。应用终于可以恢复旧的行为结束的时候，折扣期限内发送另一个程序中含有以前把要求每一个愿望清单规则集的资源。3 tuProlog：逻辑控制技术对网页tuProlog3是一个最小的基于Java的系统，明确设计整合可配置的和可扩展的Prolog成分，在标准的网络应用程序中，并被用来作为核心技术提供基本协调能力成为复杂的网络基础设施2。除了配置性和可扩充性，tuProlog是专为特写的其他工程性质,特别适合于分布式系统架构那就是，解除部署、轻盈和互操作性的标准操作规程(按照RMI，CORBA，TCP/IP)。这些特性是与构建属性描述相匹配，使tuProlog成为一个好的候选的核心推理机来处理资源计算和它们之间的相互作用。为了支持WebLP框架，一个tuProlog引擎将需要是有着概念可扩展(及相关运算符)类似于逻辑脉络，由于各种实现技术的存在，他们从最小的嵌入解释元虚拟机来有效提高。在记忆中有这样一个目标，tuProlog重新设计在过去几年来有效地支持延展性12，特别重要的是在允许一台轻量级Prolog重要技术来扩展具有相似缓解Prolog要素的执行模型可扩展的纯语言方面。全面整合tuProlog Prolog和Java之间的特点是另一种关键方面，由于可以使所有的Java技术立即可得到WebLP开发框架。例如，现有的Apache Tomcat网络服务器/容器可以作为一个多线程有效平台开发整合tuProlog，以至于开发组件的生命周期的管理和HTTP统一的接口实现。JavaServer page是另一个可扩展技术，这种技术能被利用来生产资源陈述只限在客户端网络应用程序。Java/servlets，相反，构成一个有趣的反例，他们由于不相匹配的抽象和其余的构造风格：事实上，Java/servlets用作于申请控制器被排除或重复用于不同的目的(例如仅仅作为HTTP调度程序)。4 相关的问题和进一步的工作使用Prolog，而比较普遍的是描述性语言，在过去几年中网络已经被开发应用于各个方面7，从大范围的语义网(包括OWL/RDF处理,格式翻译等等)，到GUI框架设计5、10。然而，使用Prolog框架内的网络技术覆盖的看起来相当少一个最近期的现有贡献16,提出了一个架构是相通的,其他的Prolog部件在网络应用程序通过HTTP、支持语法分析,描述和产生大型的HTML,XMLand RDF文件,包括语义网RDF加工。因此,我们的计划,进一步发展WebLP框架, 通过扩展的编程模型的基础上，建立起某种经验进行测试的应用程序，并完成了其实现tuProlog编程框架。摘自：朱利奥，安德里亚，恩里科. 面向逻辑框架的WEB编程.人工智能5 (2011) 151155 DOI 10.3233/IA-2011-0019 IOS出版社， 2011.5黄河科技学院毕业设计(文献翻译) 第 16 页 附：英文原文Towards a logic framework for Web ProgrammingGiulio Piancastellia, Andrea Omicinia and Enrico Dentib,aAlma Mater Studiorum-Universita di Bologna, Cesena, ItalybAlma Mater Studiorum-Universita di Bologna, Bologna, ItalyAbstract. Despite the popularity of the World Wide Web as a development platform, a proper description of its architectural principles and design criteria has been established only in the last decade, by the introduction of the REpresentational State Transfer (REST) architectural style, which defines the resource as the key abstraction of information. Languages and tools used for Web programming generally suffer from a lack of proper understanding of its architecture and design constraints, and from an abstraction mismatch that makes it hard to fully exploit the Web potential.Declarative languages are well-suited for a programming system aimed at being respectful of the Web architecture and principles. Among logic technologies, tuProlog has been explicitly designed to be one of the enabling components of Internet-based infrastructures: its engineering properties make it suitable for use on the Web, where logic programming allows modification of resource behaviour at runtime. Accordingly, in this paper we present a Prolog-based logic model for programmingWeb resources, and outline a framework for developing Web applications grounded on that model.Keywords: World Wide Web, REST, Contextual Logic Programming, tuProlog, Prolog1. IntroductionDespite the popularity of the Web platform for the development and fruition of many kinds of Internetbased systems, a proper description of the Web architectural principles and design criteria has been achieved only in the last decade, by the introduction of the REpresentational State Transfer (REST) architectural style for hypermedia systems 4. REST defines the resource as the key abstraction of information,and prescribes communication and interaction among resources to occur through a uniform interface by transferring a representation of a resource current state.Yet, from the early years of procedural CGI scripts to the modern days of object-oriented frameworks, Web application programming has always focussed on different abstractions, such as page 6, controller 15,and more recently service 11, thus suffering from a mismatch that has made it difficult to exploit the full potential of the Web architectural properties. In fact, a page is just the result of a computation involving one or more resources, and deals only with representation issues on the client side; on the other hand, a controller happens to be (just) a programming framework abstraction, sharing almost nothing with the underlying Web platform. Services, in their turn, disregard Web standards such as URI and HTTP, so they do not get the benefits of the REST architecture in terms of cacheability, connectedness, addressability, uniformity, and interoperability 14.As a matter of fact, declarative programming has never been accepted into the Web mainstream, even though logic languages have shown they could effectively handle both communication and co-ordination in a network-based context 1, and logic technologies have been successfully used to engineer intelligent components at the core of Internet-based infrastructures 2. However, the REST focus on resource representations as the main driver of interaction, and the corresponding Web computational model, suggest that declarative languages could play a significant role in the construction of resource-oriented applications. The advantage of using elements from logic programming languages such as Prolog lies in the representational foundations of theWeb computational model: a declarative representation of resources may be manipulated and, given the procedural interpretation of Prolog clauses, directly executed by an interpreter when a resource is involved in a computation.In this paper, we discuss a resource programming model, Web Logic Programming (WebLP) 13, which puts together elements of the logic paradigm with suitable logic technologies (i.e., the tuProlog engine 2), to define a Web application framework easing rapid prototyping while supportingWeb architectural properties such as scalability and modifiability.2. Web Logic ProgrammingWeb Logic Programming (WebLP) 13 is a Prologbased logic model to program resources and their interaction in application systems following the constraints of the World Wide Web architecture. Describing WebLP amounts at first characterising its main data type abstraction, then defining its computational model.2.1. ResourcesREST defines a resource as any conceptual target of a hypertext reference. Any information that can be named can be a resource, including virtual (e.g. a document) and non-virtual (e.g. a person) objects. Starting from such an abstract definition, the main properties of resources can be easily determined: a name (in the form of an URI); data, representing the resource state; and behaviour, to be used to change the state or manage the interaction with other resources. The defining elements of resources can be easily mapped onto elements of logic programming languages such as Prolog: for each resource R, its name N(R) can be specified as the single quoted atom containing the resource URI identifier, while data and behaviour can be further recognised as facts and rules, respectively, in a logic theory T (R) containing the knowledge base associated to the resource.In particular, if the resource names adopted are descriptive and have a well-defined structure varying in predictable ways 14, they feature an interesting property on their own: any path can be interpreted as including a set of resource names. Following this line, we say that a resource name such as:http : /encompasses the names of other resources namely, those possibly associated to the included sub-paths up to the domain at the root of the URI:http : /http : /http : /We denote this by writing:N(R) N(R1) . . . N(Rn)where each N(Ri) denotes the name of the corresponding resource Ri.This naming structure highlights that resources do not live in isolation, but in an information context composed by the resources associated to the names encompassed by the resource name.In order to account for the possible complexity of Web computations that may involve more information than it is enclosed in a single isolated resource, the context C(R) is introduced as the locus of computation associated with each resource. Such a context is then defined by the composition of the theories associated with the resources linked to names which are encompassed by that resource name, including the theory associated with the resource itself.So, for instance, the context C(R) associated to the above resource R named N(R) is generated as:C(R) = T (R) T (R1) . . . T (Rn)Where any theory T (Ri), containing the knowledge base associated to the resource Ri, can be empty for instance when there is no entity actually associated to the name N(Ri).2.2. Computational modelAccording to REST, the Web computational model revolves around transactions in the HTTP protocol. Each transaction starts with a request, containing thetwo key elements of Web computations: the method information, which indicates how the sender expects the receiver to process the request, and the scope information, which indicates on which part of the data set the receiver should apply the method 14. On theWeb, the method information is contained in the HTTP request method (e.g. GET, POST), and the scope information is the URI of the resource to which the request is directed. The result of a Web computation is a response, telling whether the request has been successful or not, and optionally containing the representation of the newstate of the target resource.Adopting a logic programming viewof theWeb computational model, each HTTP transaction request can be interpreted as a deduction by mapping the scope information onto the target theory, and the method information onto a proper logic goal. Then, the computation takes place on the server side of the HTTP transaction, in the context associated to the resource target of the request. The information resulting from goal solution is finally translated again into a suitable representation and sent back in the HTTP response.A computation invoked by a goal G on a resource R triggers the deduction of G on the context C(R). The composition of theories forming C(R) is then traversed in a very similar way as units in Contextual Logic Programming (CtxLP) 9. The goal G is asked in turn to each theory: the goal fails if no solution is found in any theory, or succeeds as soon as it is solved using the knowledge base in a theory T (Ri).Furthermore, when the goal G is substituted by the subgoals of the matching rule in the theory, the computation proceeds from C(Ri) rather than being restarted from the original context. The reason for this choice is that, if the computation has reached C(Ri), the necessary information to proceed is most likely found there than anywhere else as it was typically assumed in Contextual Logic Programming 8; however, different operators (for instance, for late binding policies) could also be used whenever needed.As an example, let us consider a bookshelf sharing application, where user jdoes shelf is identified by the URI let us call this shelf resource S. Let us also suppose that the resource B for biology books lives at /jdoe/shelf/biology, and that predicate pick biology books/1 is ultimately invoked on B when a GET request is issued for that resource.If predicate pick biology books/1 depends on a pick books/3 predicate that is neither defined inB nor in S, the theory chain inC(B) is traversed backwards up to the resource, as depicted in Fig. 1, where a suitable definition for pick books/3 is finally found. According to the above-stated (eager) policy, definitions for other predicates invoked by it are then searched starting from the context of the root resource, rather than C(B) where the computation originally started.Fig. 1. The /jdoe/shelf/biology resource responds to a HTTP GET request by eventually invoking the pick biology book/1 predicate, which in turn calls pick books/3. The context is traversed until a proper definition for it is found here, in the / resource.It should be noted, however, that unlike Contextual Logic Programming, where it was possible to push or pop units from the context stack at runtime, the fixed structure of URIs as resource identifiers makes the composition of theories forming a context static. In addition, the structure of identifiers and resources in the Web architecture also dictates a unique direction in which the theories associated to resources composing a context can be traversed that is, from the outermost (associated with the resource on which the computation has been invoked) to the innermost, passing through the theories belonging to each of the composing resources, until the host resource is finally involved.2.3. Dynamic resource behaviourThe behaviour of a resource can be regarded as dynamic under two independent aspects. First, two or more URIs can be associated to the same resource at any time: that is, the names N1(R), . . . , Nm(R) may identify the same resource R, thus the same knowledge base contained in the theory T (R) associated to the resource. Each different name Ni(R) also identifies a different context Ci(R) that the same resource R may live within (see Fig. 2); therefore, predicates that are used in T (R) but not defined there may behave in different ways based on the definition given by the context where the resource is called.The second dynamic aspect of a resource comes from the ability to express behavioural rules as firstclass abstractions in a logic programming language: on the one hand, well-known logic mechanisms for state manipulation (the assertz/1 and retract/1 predicates) can be exploited to change the knowledge base associated to a resource; on the other, the HTTP protocol itself allows changing a resource by means of a PUT request, whose content should be considered as a modified version of the target resource that has to replace (or be merged with) the original version residing on the server. Fig. 2. The logic theory of a resource representing sales for the fourth quarter of 2004 can be identified by two different names and therefore live in two different contexts.As an example, let us imagine a reading wish list in the previous bookshelf application. Usually, when a book is added, the resource representing the wish list could check local libraries for book availability, and possibly borrow it on users behalf; if no book can be found, the resource could check its availability in online bookstores, reporting its price to the user for future purchase. However, during sales periods, when an online bookstore offers discounts, the wish list resource should react to the insertion of new books to check that store first.To implement this behaviour, the Web application could then be instructed to change the behaviour of wish list resources by issuing HTTP PUT requests that modify the computational representation of those resources. The PUT requests would carry the new rules in the content, so that wish list resources would modify their knowledge base accordingly. The application could finally restore the old behaviour at the end of the discount period programmatically, by sending another PUT request containing the previous rule set for each wish list resource.3. tuProlog: Logic technology for the WebtuProlog 3 is a minimal Java-based system explicitly designed to integrate configurable and scalable Prolog components into standard Internet applications, and to be used as the core enabling technology for the provision of basic coordination capabilities into complex Internet-based infra