CC BY
43
a list of Views. Looking at the IModelExecutionContext can provide a clear example. XAF is based on an MVC pattern which means that there is a Controller class responsible for connecting the Model with the View. The controller exposes the system events. What has been done is create a base controller and subscribe to all system events. Then when an event is raised the XAF model is queried for all rules that have that event in their IModelExecutionContexts list and for the rules found we execute the controllers registered for these. We have named the module that provides that architecture Logic Module.
3.6. More Abstraction
A XAF application can be controlled - ruled in at least 4 different ways. Developing with metadata (Fig. 2, left), declarative development though model, code development with the Rule systems provided (XAF has a Validation, ConditionalEditor, ConditionalAppeareance and eXpand the abstract Logic Module) and also the system behavior can be changed by applying security permissions. From parti of Fig. 8 one can see that interfaces are not Model depended (they are not named IModelxxx). This provides enough abstraction to implement the same interfaces in attributes (metadata) so that the model can be created but also we can implement permissions with them. Furthermore since there are base controllers which work with rule interfaces and we want to support rule creation with code instead of having to deal with model, permissions or rules it is possible to create a class adapter that implements the same interfaces and transform our model, attribute and permissions to that. That architecture is used extensively from eXpand to design various modules like shown on Fig. 9. (Note the common attributes and structure defined by the logic module).
Conclusions
Due to page limitations it has been impossible to cover further issues that may arise. The goal of this article has been to present a personal point of view and experience on how a real world application should behave. Describing our work with such functional tools allows for a better collaboration between us, and most importantly it can hopefully create a bridge with the business community.
References
1. DevExpress eXpressApp Framework (XAF), http://www.devexpress.com/xaf/
2. eXpand Framework is first open source project based on DevExpress eXpressApp Framework (XAF), http://www.expandframework.com
PROTOTYPE OF NONENAVIGATION OBJECT QUERY LANGUAGE SYNTAX REPRESENTED AS XML-DOCUMENTS
Pavel P. Oleynik, Ph.D., System Architect, JSC Aston, Russia, Rostov-on-Don, xsl@list.ru
Extensible Markup Language (XML) is used to represent semistructured data, i.e. such as information, the structure of which is either unknown or will experience profound changes in the future [1]. Due to its flexibility, visibility and the existence of a large number of supporting technologies, the language is applied in the various tiers of the information system (on a DBMS server, a client application, an application server). The problem of representing the syntax of a query language (QL) to the data (e.g., SQL, OQL, etc.) is one of the challenges that appears while saving the information the structure of which is unknown a priori. The declaration of such a QL in the form of XML-documents allows to unify the process of data manipulation, which in this case does not depend on a specific data source (a file system, RDBMS, OODBMS, etc.), and allows to replicate this solution for various hardware-software platforms. Thus, there appears an opportunity to perform XML-queries in a heterogeneous environment by creating a mechanism of mapping syntax structures of this language on a specific QL, supported by the data source (SQL, OQL).
15
XML was used for declaration of the XOQL application (XML Object Query Language). XOQL is an object query language syntactic structures of which are equivalent to the OQL features of the ODMG standard. In order to determine the permissible semantics for syntax structures of the designed object QL, the XML-schema is described and its graphical representation is shown in Fig.1.
The tag <XOQL> is the root element of any XOQL-query. It has an attribute “version”, intended to describe the query language version. The value of this attribute is analysed by the parser program that performs the transformation of an XOQL-query into the QL, supported by the target DBMS. In this way the possibility of supporting backward compatibility was provided. It allows an application to work with different versions of the language. The child element <Select> indicates that the query retrieves some information from the data store. Other types of queries (new data insertion, deletion and modification of existing information) are not considered in this article. Therefore the appropriate syntax structures (represented by XML-tags) are not shown in Fig. 1.
The optional tag <SelectOptions> may attend inside the element <Select>. This tag is intended to indicate various options affecting the dataset. For example, using the nested node <TopRowCount> the result set can be restricted by the first N entries, where N - is a positive integer.
To describe the elements of the result dataset projection the tag <SelectItems> is used. Each element is defined in the XML-node <SelectItem> and may contain an alias (specified as an “Alias” attribute value) under which it will be returned to the client application. Thus, usage of the “Alias” attribute is equivalent to usage of the “as” directive in a SELECT query in SQL.
16
The ability to specify in the selected list not only the attributes of atomic literal type, but the attributes the type of which is represented by a class is the key feature of OQL. This feature (not available in SQL, which only involves removal of atomic values in the “select” directive) simplifies the process of extracting the required data. To implement this functionality the dot notation is used. It allows representing path expressions.
The tag <InstanceAlias> (nested in <SelectItems>) is applied to retrieve objects (instances) as the elements of the projections. This tag contains a collection alias declared with the node <FromItem>.
The tag <Attribute> allows to retrieve an attribute value. If the attribute is represented by an atomic literal data type (string, integer, float, etc.) and is uniquely defined by its belonging to any type of item in the collection, then it is just sufficient to specify its name (as the value of the XML-element). If it is impossible to define the type of collection item by the attribute name unambiguously (it happens when there are multiple attributes with identical names in one scope), you should specify the name of the collection by the tag <InstanceAlias>. The name of class attribute in this case is defined as the value of XML-element <AttributeName>.
To retrieve an attribute value of the aggregated class it is necessary to describe a path expression, which is implemented using an alternation of the nested tags <Attribute> and <ReferenceJoin>.
If the extracted value should be cast to any concrete class (while retrieving the instances of a derived class through a link, which type is a base (possible abstract) class), then its child class name is specified as the value of the node <SelfClass>.
The <From> tag allows to specify various collections (with nested nodes <FromItem>) the Cartesian product of which is the source for the dataset. The collection can serve as an extent, containing objects of a certain class, as well as a class specified by a path expression from the previously declared collection.
The first method uses the tag <Class>, containing the name of the class which objects must be retrieved, and the second one uses either the XML-node <InstanceAlias>, containing the alias name given earlier for a particular collection or the item <Attribute>, retrieving the attribute of the class type. The attribute “Alias” is used to specify collection alias for future references to it by specifying a value in the tag <InstanceAlias>.
To describe the predicate (logical expression), which imposes filtration conditions on extracted data, the tag <Where> is used. Fig. 1. shows that logical operations (“and”, “or”, “not”, “xor”), as well as comparison operations (“>”, “=”, “<”, etc.) are described within this tag. When software applications are developed with the use of an object-oriented programming language and when we try to solve the problem of similar objects description (in our case, operations), class inheritance is mostly used. This problem can be solved through the usage of polymorphism implemented in XML-schema by the attribute “base" of the tag <extension> (the child tag of the node <complexContent>), which contains an XML-type name (described with the use of the tag <complexType>), acting as parent in relation to the declared one [3]. Despite the apparent similarity, the inheritance of XML-types and the class inheritance have the key difference. When inheriting tags in an XML-document (i.e. XOQL-query), the tag name of the base class is specified, and the name of the child XML-type is specified in the attribute “xsi:type”. From the standpoint of our task, to construct a predicate in the element <Where>, we need to place several identical XML-nodes nested into each other, representing each logical and comparison operation. This approach makes it difficult to write logical expressions and reduces their demonstrativeness because of the need to support many different operations, and therefore it can not be used in our task.
As an alternative, we can declare the group AnyLogicalOrCompareOperation (using a standard tag <group> of the XML-schema) in which the component <choice> provides links to a group AnyLogicalOperation, representing the set of all logical operations and a group AnyCompareOperation, describing the set of all comparison operations. Moreover, for all logical operations the base type LogicalOperation was declared (not shown in Fig. 1), which has two subtypes: 1) UnaryLogicalOperation is announced as the parent tag for all of the unary logical
17
operations and allows to describe as the value tags corresponding to the group AnyLogicalOrCompareOperation; 2) MultipleLogicalOperation is intended to describe the multiple logical operations and allows to describe as the value two or more tags corresponding to the group AnyLogicalOrCompareOperation. Many logical operations, such as “or”, “and”, “xor” are binary. When writing complex queries, there is a need to union more than two operands with one operation. To get rid of repeating the same operation several times XML-type MultipleLogicalOperation has been described. The types of concrete operations (tags <And>, <Or>, <Xor>) were inherited from this XML-type. Thus, in general, binary operations are n-ary ones. The values of these operations are evaluated from left to right. It corresponds to the serial extraction of tags by such programming interfaces (API) as DOM or SAX [4].
Similar approach is used for tags developing, that allows to describe the comparison operation: for the unary operations the type UnaryCompareOperation was defined, and for the binary ones the type MultipleCompareOperation was used. Both types are inherited from the base one CompareOperation. The binary operations are n-ary as well as logical ones. The operation IsNull is the only unary operation declared in the schema. It checks empty value for the attribute the type of which is a class. Fig.1 shows that for the other comparisons we can use a set of tags as child elements corresponding to the group ExpressionContent, which represents a sequence of arithmetic operations (the group AnyArithmeticOperation), attribute values (the tag <Attribute>) and constant values recorded in the tag <ConstValue>. Since the value of the last XML-node is a string, then using the “Type” attribute we can specify the desired type, corresponding to the types of DBMS into the query language of which the XOQL-query will be transformed.
In any comparison operation the tag <Attribute> can be used. It suggests the potential for describing a path expression. This approach demonstrates the commonality of the implemented treatment of the dot notation (for a path expression).
This article describes in detail the basic syntax constructions of the object query language XOQL, based on XML-applications. The key areas of the presented research progress consider the problem of the expansion of the proposed syntax with additional constructs (“order by”, “group by”, “having”, etc.) and the description of the directives which allow to add new data, to edit and delete the existing ones. It is also necessary to develop and implement an algorithm for transformation of XOQL-queries into a certain dialect of queries (e.g., SQL), supported by a specific DBMS.
References
1. Graves M. Designing XML Databases, Prentice Hall PTR, 2001, 688p.
2. Cattell R.G., Barry D.K. The Object Data Standard:ODMG 3.0, Morgan Kaufmann Publishers, 2000,
288p.
3. Russell Butek, Web services tip: Use polymorphism as an alternative to xsd:choice, http://www.ibm.com/developerworks/webservices/library/ws-tip-xsdchoice.html
4. Holzner S. Real World XML, Second Edition, Peachpit Press, 2003, 1200p.
УДК 004.457
ПРИМЕНЕНИЕ ОБЪЕКТНОГО ПОДХОДА ПРИ СОЗДАНИИ РАСПРЕДЕЛЕННОЙ СИСТЕМЫ ВЫЯВЛЕНИЯ И ПРЕДОТВРАЩЕНИЯ АТАКИ ТИПА ARP-SPOOFING
Крылов Александр Юрьевич, студент, Ивановский государственный химикотехнологический университет, Россия, Иваново, Krylov Al@mail.ru Шитов Николай Андреевич, студент, Ивановский государственный химикотехнологический университет, Россия, Иваново, niko 1989@inbox.ru Галиаскаров Эдуард Геннадьевич, к.х.н., доцент, доцент, Ивановский государственный химико-технологический университет, Россия, Иваново, galiaskarov@isuct.ru
18
