JP2006510955A - Context-independent framework system and method for managing and executing XML processing tasks - Google Patents

Abstract

Provides a context independent framework system for management and matters of XML processing tasks. The XML processing task is executed by a module called an XSA engine in accordance with a predetermined set of instructions prepared as an electronic document written in a special purpose XML programming language. The instruction set contains references to three classes of processing modules and controls their execution. The three classes of processing modules independently perform XML processing subtasks and jointly accomplish one XML processing task. The framework is disconnected from any particular execution context, meaning that standardized XML processing can be applied in almost any desired application. Special purpose programming languages improve the productivity of developing XML processing tasks compared to using general-purpose programming languages, and write custom code to link different types of XML processing subtasks to perform XML processing tasks Has reduced the need to do.

Description

  A task execution management system that includes context-independent processing of structured data using a special purpose programming language.

  Most computer applications are designed to perform a certain task (s) and provide a comfortable life for that human user in the process. Computer networks and the Internet have introduced new opportunities to make life easier with computer applications. Today, almost all computers in a company or organization are connected to some kind of computer network, and more commonly connected to the Internet.

  In recent years, Extensible Mark-up Language (XML) has emerged as a common way to describe structured data of all forms. Extensive industry support for XML and the ubiquity of XML development is increasing the number of suppliers of computer applications that provide some form of XML support in their applications. One type of XML that a new application provides is called a web service. A web service is a software component that exposes a predefined XML interface to its data and services that are generally accessible over the Internet.

  XML is frequently used in the field of electronic publishing, particularly when publishing is done on request and involves the movement of data through a computer network. For example, all browser applications understand some form of XML or XML-related data format (eg, HTML, XHTML, WML) and provide these to their human users. Other representation formats for other types of electronic representations may or may not be XML or XML-based, but generally XML is very suitable for publishing applications.

  Electronic business is another area where XML and the Internet play a major role. Electronic business often involves performing electronic business transactions automatically between organizations according to predefined rules and invocation criteria. EDI is a common non-XML-based electronic business framework, but all the continuous frameworks that are now emerging (eg, BizTalk, ebXML, etc.) rely heavily on XML and the Internet.

  Despite the overall adoption of computer networking, many applications cannot do this even if it is effective to communicate freely with other applications over the network. Most applications have some function of importing data from an external application on the network and exporting the data to the external application. Unfortunately, most current applications generally require enterprise-specific data formats and protocols, making communication between applications, possibly beneficial, difficult. This means that automatic information exchange (integration) between applications is highly desirable in many cases, but data must be derived and converted between protocols by middleware (or interpreter software), which is often custom-made. Only then will applications be able to freely communicate and exchange data / information.

  In this regard, integration problems often arise when an organization wants to access an integrated unified interface to more than one back-end application. Because such applications often do not communicate freely, a single application cannot provide an interface with views for data from many systems. The only solution to this problem is to introduce portal software middleware, but this can be communicated to all the required systems, and all data is fused and unified as appropriate, then There is a need to provide a consistent interface with integrated views for data / services from all applications. However, portal software sometimes has the disadvantage of relying on data replication from many systems.

  Another integration issue arises in electronic publishing. Since many applications have limited representation capabilities, human interaction with the interface can often be provided with only one type of media. This means that if new expression needs arise, middleware software, which is often custom-made, needs to be introduced in order to extend the application interface.

  Also related to this is the fact that many electronic representation formats (eg Adobe PDF documents, MSWord documents) have little or no separation between content data and representation data. There is another expression problem. This means that it is difficult or impossible to adapt an existing document to a new format when a need for a new representation arises.

  Some of these problems can be remedied or even eliminated if an organization replaces their old application with a new one. However, many organizations have sought to mitigate the problem by introducing Enterprise Application Integration. This can in some cases extend the scope of an existing application by installing middleware, improving or extending the application's existing interface, or allowing the application to communicate with other applications. Accompanied by.

  XML is very suitable for any application that relies on structured data. The unique characteristics of XML and the exceptional wide industry response have proved to be very useful for integration, electronic business and publishing applications. Many analysts are convinced that XML allows applications to actually communicate with each other, thus making it easier to make their users' lives easier. In practice, this means lower integration costs when XML is involved in the solution. It is clear that at least XML and XML-related technologies are widely used today for integration and electronic business and publishing software for a reason.

  For most experts in this field, utilizing XML and XML-related technologies means when developing certain types of applications, such as those that need to be used for heterogeneous system integration, electronic work and publishing. I am sure there is. However, their use in these applications is often little standardized or ad hoc. As for the current situation, some organizations have information processing capabilities and use XML to build better applications, but some organizations may be able to describe it by saying that they do not. Most of these will only be used on an ad hoc basis unless you tell them what the existing XML-related specifications will do. The world of XML processing is filled with small modules for narrowly defined tasks, but lacks a clear framework for managing them together. This means that most current XML-based solutions rely, in part, on ad hoc programming “glue” to link different XML-based modules together.

  Thus, it is desirable to influence the framework methods and systems for managing and executing XML processing tasks. In addition, such frameworks are disconnected from any specific execution context, and are flexible enough to handle all cases where the XML processing management framework seems valuable. It is important to be.

  In addition, such a management framework reduces or eliminates the need to use a general purpose programming language to splice together many different types of XML processing tasks, each governed by an existing XML processing standard or specification. Therefore, it is preferable to rely on special purpose programming languages that define XML processing tasks. Such a special purpose programming language for XML processing tasks allows developers to improve productivity far more than is possible with general purpose programming languages while defining XML processing tasks.

  Some of the problems associated with XML processing being useful in integration, publishing, electronic work, or other areas are overcome or mitigated by the preferred embodiment of the present invention. A framework method and system for managing and executing XML processing tasks is provided. This framework can be disconnected from any specific execution context, meaning that the management framework can be applied anywhere within an application that requires XML processing.

  The present invention relates to server-side XML applications, ie, any server-side computer application in which XML processing plays an important role or can play an important role. XML applications are common in fields such as enterprise application integration, electronic publishing, and electronic business processing. More particularly, the present invention relates to a method and system for a standardized structured framework for managing, defining, and executing XML processing tasks based on a special purpose programming language that defines processing tasks. .

  Furthermore, according to a preferred embodiment of the present invention, the XML management framework relies on a special purpose programming language designed for the purpose of linking different XML processing subtasks together and is well known in the technical field of XML processing. Control each subtask by standard, method or use. Special purpose programming languages are specifically designed for the management of XML processing tasks, allowing developers of XML processing tasks to be more productive than possible with general-purpose programming languages. Alleviates the need to write custom code that links different types of XML processing subtasks to accomplish the task. Examples of useful applications are business message transformation and delivery, heterogeneous system integration, and web publishing.

  One aspect of the present invention defines an XML processing task according to a predefined set of instructions prepared as an electronic document written in a special purpose programming language specifically designed for managing and linking XML processing subtasks. And a method and system for performing. Here, each subtask is adjusted according to a well-known XML-related standard, specification or method. Each XML processing task defined by a specific set of instructions in an electronic document written in a special purpose programming language is often referred to herein as an XML service action or simply XSA. A software module capable of executing XSA-s is called an XSA engine. Special purpose programming language formats and syntax that are designed to define how XML service action electronic documents are created and to manage XML processing tasks can be defined with high precision and special The target programming language syntax is preferably specified in markup based on XML.

  The method includes invoking the system with an external request and executing a specific set of processing instructions, ie, a specific XSA electronic document written in a special purpose programming language. The call includes an indication of which XSA to perform, and can also include other information regarding the origin and purpose of the call. Upon receipt of the call, the XSA engine locates the appropriate XSA electronic document, attempts to execute the instructions defined therein, and returns a response according to the instructions within the particular XSA executed as appropriate.

  In accordance with a preferred embodiment of the present invention, the XML management framework and special purpose programming language are based on three different classes of XML processing modules, which together are specified together with another part of the present invention. The XML processing task defined in XSA is performed. Each XSA written according to a special purpose programming language generally references at least one of each of these three classes of XML processing modules and controls its function. The XML service action defines, modifies, and controls how these three types of modules interact and work together to perform XML processing tasks. The three types of modules are referred to herein as generators, converters, and sinks. Most XML processing subtasks are either correctly defined or are well known in the XML processing art and can be categorized as subtask generation, subtask transformation / operation, or subtask sink.

  In any given XML processing task, defined by any XSA, the generator module is responsible for generating XML source data, and the converter module converts or manipulates the XML source content. In this way, it is responsible for forming different XML data (processed XML data), and finally the sink module is responsible for interpreting, responding to, or delivering the processed XML data. The generator generates XML source content and generally exposes the data generated in the external system. An example generator communicates with an external system, such as a JDBC compliant database, and publishes it to content or services provided by the external system in an XML format that is prepared for further XML processing. Each generator defines its own XML syntax and is published in a natural way to the content or service provided by the back end system (multiple back end systems) with which it communicates To do.

  One or more converters comprehensively process the XML content to further process, interpret, or manipulate the XML source data to perform the requested XML processing tasks defined in the specific XSA. Transformation, interpretation, validity determination, response, or manipulation in some way generally yields different (or at least examined and validated) XML data. This is referred to herein as processed XML data. The converter is a module having XML data as both input and output, and many converters can be used in series. An example of a converter is a software module that converts XML according to a given stylesheet written in Extensible Stylesheet Language Translation (XSLT). Depending on its purpose, each type of converter may or may not impose constraints on its XML input data received from the generator or another converter. Each converter also defines the format of the processed XML output data.

  In the execution of the XML processing task defined in any given XSA, the final part is done using the sink module. The sink module defines what to do with the processed XML data received from the converter. Different types of sinks perform different tasks depending on the purpose of the XSA. One common task is to publish processed XML data in some way, often not in XML format, and send it back to the client that requested the execution of XSA. Some sinks interpret the received XML data and determine whether and how to react, for example, by performing some action. One example of a sink output outputs its XML input data, such as HTML or WML, and another example publishes it as a PDF electronic document. Some other types of sinks distribute the obtained XML as XML business documents over the Internet, and yet another sink uses information in the received XML to determine whether to execute a task. Some will do. Tasks include sending an email for notification purposes, writing data to a database, or sending XML to another system for integration purposes.

  As described above, the present invention includes an execution system for an XML service action electronic document, preferably written in a special purpose programming language according to the XML service action specification. The XML service action specification precisely defines the effective syntax of XSA in the spirit of the present invention. The system includes an XSA engine that is disconnected from any application specific context and provides only a general purpose interface. According to a preferred embodiment of the present invention, the system adapts to a specific application context based on a software module, referred to herein as an adapter. The adapter is responsible for accepting specific XSA-s execution requests or calls from various types of external clients, such as network devices, wireless devices, or other computer systems. The adapter encapsulates all application or context specific communications by handling all communications with external clients, and adapts to a specific type of communication protocol as a whole and requires the execution of a specific XSA to A software module that performs bidirectional processing with the XSA engine through a general-purpose interface. Thus, the adapter component adapts the generic XSA engine to a specific application context. When a request arrives through the adapter component for each XSA execution request, the adapter component defines a context for the XSA to execute. This provides a link from the real world of computing applications to the XSA engine that may be appropriate for a particular XML processing task. Through the general-purpose interface provided by the XSA engine, the adapter can provide the XSA engine with information about incoming requests. This incoming request is probably in XML format or parameter name-value pair format. When the execution of XSA ends, it is common to return an appropriate response to the requesting external client through the adapter component that invoked the XSA engine based on the result of the processing defined in that particular XSA. . A particular generator, converter, or sink may impose constraints on which particular type of adapter is compatible with them.

  Any XSA can perform a desired XML processing task using a particular type of generator, converter and sink in a variety of ways. XML processing defined in XSA may be performed in more than one thread of execution, for example by merging or splitting XML electronic documents. The XSA engine relies on many different types of software modules to implement the flexible and sophisticated processing and flow possibilities of XML data using the three classes of XML processing modules described above. These software modules include error handling, validity determination, access to metadata related to specific XSA execution, session control, user management, authentication, authorization, and other similar auxiliary functions, such as: An auxiliary or support function can be provided.

  XML software actions can be used to perform very different computational tasks in very different applications. More or fewer system components may be used and the present invention is not limited to the system components described above. The present invention does not necessarily require the presence of any software component. This describes an XML processing task execution method and system defined only for the management or linking of explicit XML processing subtasks and defined by XML service action electronic documents written in a special purpose programming language. This performs its desired function using a specific implementation of the abstract processing module described herein. Although the present invention has always been described herein in terms of XML processing tasks, the method and system are equally applicable to any processing of structured data that is not necessarily in XML format. In order to be useful in the real world, specific software modules and component implementations must be provided, depending on the specification for the special purpose programming language, that precisely defines the format and processing modules of the XML service action electronic document to be controlled. I must.

  According to a preferred embodiment of the present invention, each XML service action electronic document is written in a special purpose programming language that should be defined in a specific syntax and may or may not be XML-based. . The XSA engine is responsible for interpreting and executing XSA electronic documents. The XSA electronic document can be used by the XSA engine by dynamic generation, or it can be obtained from any storage in the requesting client or computer system. A system capable of executing XML service action electronic documents written in a valid special purpose programming language in accordance with the specification written in the gist of the present invention can be implemented in a conventional computer system.

  The XSA framework provides a flexible, elaborate means that is disconnected, standardized, structured, and processed from any specific execution context to process and manipulate publishing, business message delivery, enterprise application integration, and structured data In other areas of particular value, many problems can be solved more correctly and easily.

  The XSA framework is complementary to existing technology. This is a framework for managing XML processing tasks and is not a substitute for any particular type of existing XML processing technology. For example, this does not define how to transform an XML document and the specific embodiment can be used in any existing way for that purpose. By requesting and using a high-level special-purpose programming language specifically designed for managing XML processing tasks, you can create custom code in a general-purpose programming language and even reduce or eliminate the need to stick XML processing subtasks together To do. Here, each subtask is adjusted according to a well-known XML processing standard, specification or method. The following are the similar ones. An XSLT engine, XML validator, HTML-XML converter, XML serializer, or any other module that performs a particular type of XML processing task is considered a program. The XSA engine then resembles an operating system that coordinates the interaction between these programs. The XSA engine can interpret and execute XSA electronic documents written in a special purpose programming language and can be viewed as a general implementation of the XSA framework described herein, and thus XSA A framework can be considered similar to an operating system family or standard.

  In one particular preferred embodiment of the present invention, the method and system are used to allow a wireless device to request information in an electronic document in a format that the device can understand. . Through a suitable adapter capable of communicating with the device (eg, an HTTP adapter), a specific XSA can be invoked and executed within the XSA engine. The XML processing task defined in this XSA retrieves data from the back-end system, converts it to XML format using a specific type of generator, and requests it using a converter It can be converted to a format suitable for the original device and finally the sink can deliver it to the device through the adapter.

  For example, in accordance with a preferred embodiment of the present invention, request information about current weather from a wireless device by navigating to a specific URL using hypertext transfer protocol (HTTP) compliant browser software. be able to. The XSA engine can access a specific XSA electronic document that defines how the desired response is derived from the information obtained from the weather data source and deliver it to the requesting device through an HTTP adapter. This request is received by an HTTP adapter that can communicate with the requesting client via HTTP. The adapter then invokes the XSA engine and begins executing the requested specific XSA. This XSA contains a reference to a particular type of generator that can be connected to a weather database. An instruction in XSA instructs the generator to retrieve the weather data, which is then converted to XML source data. XSA can also contain references to and instructions for one or more specific types of converters (eg, converters that convert XML using XSLT) and convert XML source data. Thus, an XML electronic document in wireless markup language (WML) format suitable for display by a browser on the requesting device can be formed. Finally, XSA also contains references to and instructions for certain types of sinks that can deliver WML electronic documents to requesting devices through an HTTP adapter module. The particular XSA electronic document in question is written in a special purpose programming language and can be accurately defined in the XSA programming language specification. However, the present invention is not limited to HTTP communications, wireless devices, or databases. Other data, protocols, network devices, or external systems can also be used.

  The foregoing and other features and advantages of preferred embodiments of the present invention will be more readily understood by those of ordinary skill in the art upon reviewing the detailed description of the embodiments of the invention in conjunction with the accompanying drawings.

  For a better understanding of the aspects of the invention in which the above cited advantages and other advantages can be obtained, a more detailed description of the invention is provided with reference to the accompanying drawings. Furthermore, descriptions of specific embodiments of the present invention are also illustrated with reference to the accompanying drawings. With the understanding that these drawings depict only typical embodiments of the invention and are therefore not to be considered as limiting its scope, the invention will be described and used with the accompanying drawings to illustrate the invention. The aspects that are best understood at the present time will be described in further detail for purposes of illustration only.

  The embodiments described herein are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Conversely, the embodiments selected for description are described so that those skilled in the art can utilize their teachings. Most notably, although XML processing is frequently referred to herein, the present invention is not limited to XML processing or XML service side applications, but is equally applicable to any structured data. .

  The following discussion is intended to provide a brief and comprehensive description of a suitable computing environment in which the invention may be implemented. Although the present invention will generally be described in terms of computer-executed instructions, such as program modules, executed by a personal computer, it is not required to do so. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data formats. Further, as will be appreciated by those skilled in the art, the present invention includes handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, etc. Other computer system configurations can be implemented. The present invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

  As used herein, the term “software module” or “module” shall mean any set of executable instructions that are separately recognized to perform a particular logical function within a computer program.

  FIG. 1 is a block diagram illustrating the basic components of an XML processing system 10. The XML processing system 10 generally includes an XSA engine 16 with a general purpose interface and one or more adapter modules 12 that allow an external client to perform bidirectional processing with the XSA engine 16. The XSA engine 16 can execute instructions encoded in the XSA electronic document 18 using a special purpose programming language designed for the management of XML processing tasks. Since the XSA engine 16 only provides a generic interface, calls to the XSA engine 16 are made through the adapter component 12, thereby causing one or more types of external clients 40 and on the other hand. It can communicate with the XSA engine 16. Each call or request from the external client 30 must contain information or data that can be used to determine which XSA electronic document 18 the adapter module 12 will execute. Upon receipt of the request or call, adapter module 12 may provide the XSA engine with information regarding the origin and purpose of the request. This information is accessible to the XSA engine, here represented by the context module 14. The XSA engine 16 is defined in a request XSA electronic document 18 written in a special purpose clear high-level programming language specifically designed for managing XML processing tasks using the context module 14. Initialize and execute the XML processing task. Having such a special purpose higher level programming language means that the creation of a specific XML processing task can be done more easily and quickly than is possible with a general purpose programming language. Although applicable only to XML processing tasks, the creation of such tasks can be done much faster and easier using special purpose programming languages. You can also create a software program that probably uses a graphical user interface and completely eliminates the need to write custom code directly, allowing developers to create concrete XSA documents through the higher-level interface. it can. The developer's bi-directional processing with such a high-level interface makes it possible to generate concrete XSA, possibly using graphic components, without having to write any textual code. There is also a case.

  The present invention divides XML processing tasks into three classes of XML processing steps or subtasks, XML generation, XML transformation, and XML delivery / response. This is reflected in the fact that each XSA electronic document 18 generally includes a reference to a specific implementation of three classes of XML processing modules, and each class corresponds to one of these subtasks. ing. The XML generator module 20 is connected to an external back end system 40 and exposes its content, services and / or business logic as XML data that can be used for further processing by the XML converter module 22. Is responsible. This step often involves both connecting to the external system and defining the mapping of the external system's native data structures to the XML format. The XML converter module 22 converts the XML data received from the XML generator 20 into a different XML format. The XSA electronic document 18 can sequentially define more than one XML converter for sequential processing of XML data (discussed in more detail below). The XML sink module 24 reacts to or distributes XML data received from the XML converter module 22. Each of these three abstract XML processing module types is provided by the adapter module 12 where it can access the meta information represented by the dynamic XSA context module 14. Meta information in the XSA context module 14 is provided by the adapter module 12 before the execution of a particular XSA begins and persists throughout the execution of the XSA. This is accessible to all modules involved in the execution. The meta information represented by the context module 14 defines the context executed by the XSA. Each of the three abstract XML processing modules can also access the passive resource repository 26. In the passive resource repository 26, various resources in electronic format are stored in a storage medium. An XSA electronic document can define and control one or more XML generator modules, zero or more XML converter modules, and one or more XML sink modules.

  FIG. 2 refers to specific generators, converters and sinks, and by managing these interactions, specified in a special purpose high-level programming language and designed for the management of XML processing tasks, It shows how an XSA electronic document defines an individual XML processing task.

  FIG. 3 is a block diagram illustrating execution of an XML processing task when an XSA electronic document is being executed. This figure also shows the flow of XML data that undergoes zero or more conversions during the period from the generator to the sink.

  FIG. 4 is a flow chart illustrating a series of events that initiate and complete the execution of XSA in the XML processing system according to the present invention. A call or request from an external client is made (1). The request contains information that can be used to determine which XSA electronic document to execute. Furthermore, the information can also contain information that depends on other contexts. All request information, whether implicit or direct, may be referred to as request property (2). If a particular adapter module is able to communicate with the requesting client, receives the request and has access to the appropriate context-dependent information, it supplies the XSA engine with an XSA context module (4) By doing so, the context of XSA execution (3) is defined. The adapter module initiates execution of a specific XSA within the XSA engine module. The XSA engine uses the information in the XSA context module to prepare for execution of the requested XSA electronic document (5) written in a special purpose programming language. The specific type of generator defined in the requested XSA generates XML source content according to the instructions in a given XSA (6). In doing so, it generally communicates with some external back-end system and converts the acquired data to XML. The result is XML source data (7) before processing. Next, zero or more XML converters (8) convert the XML source data according to the requested instruction in XSA, resulting in different types of XML data (9). Finally, the XML processing module terminates the XML processing task by delivering or reacting (11) to the XML content in some way. This step may or may not involve interpretation of the processed XML data. In general, some kind of response is returned to the requesting client through the adapter module as a result of the task that the XML sink (12) has completed.

  FIG. 5 is a block diagram illustrating the role of the generator and the typical structure defined by the XML service action model. This figure generally shows that the generator is faced with a dual task of first connecting to the external system and then publishing data from the external system in XML format.

  FIG. 6 is a block diagram showing the role of the converter defined by the XML service action model. This figure shows that any number of converters may be applied sequentially and each one has XML data as both input and output.

  FIG. 7 is a block diagram showing the role of the sink defined by the XML service action model. In general, a sink either converts XML input data into some external data format and distributes or publishes it to the requesting client, or interprets or reacts in some way according to the processed XML input. The response can be either depending on the purpose of the sink and does not necessarily involve a response to the requesting client.

  One preferred embodiment of the present invention is a presentation system, in a back-end system to many different types of network clients, for example many different types of mobile devices, that have incompatible requests for expression. Facilitates publication of resident data. The presentation system includes an adapter module that can communicate with a client through, for example, the HTTP protocol. The presentation system also has a specific type of generator module that can communicate with the back end system (multiple back end systems) and publish back end system data in XML format. I have. The presentation system also provides a specific type of converter module that can convert generic source XML data from the back end system into many different formats suitable for display on each of the network client devices. Also built in. The system also includes a sink that can return individually produced content to the requesting client device through the adapter that sent the request. The system also contains specific XSA electronic documents written in a special purpose programming language, manages the processing of XML data, and depending on which client has requested the content, the appropriate generator Ensure that converters and sinks are used. The presentation system is inherently extensible for the XSA framework, facilitating complete separation of raw content data from presentation information. To accommodate new back-end systems, new clients, or new communication protocols, simply add new generators, converters or adapters.

  Another embodiment of the present invention is a messaging system, which typically uses a standardized business messaging protocol such as ebXML or BizTalk over the Internet from one external system to the other in a secure manner. To deliver. This system requires an adapter module that can communicate using the protocol. The system also includes a specific type of generator module that can extract data in XML format from the communication system. In addition, it can also incorporate various converters that can turn system data into business messages for delivery. The system also includes a specific sink module that can deliver the message to its destination through the appropriate adapter module. The system can also incorporate specific types of converters that can translate between business messages of different standards. Finally, the system is written in a special purpose programming language and manages specific XSA electronic documents that manage and control XML processing and XSA that can do it when requested to execute these documents. Built-in engine.

  Yet another embodiment of the present invention is an integrated system that can integrate data between disparate source and destination applications. This type of integrated system includes an XSA engine, a specific XSA electronic document written in a special purpose programming language, a specific adapter module that can communicate between the source and destination applications, A specific generator capable of converting the data structure to XML format, a specific converter capable of converting XML input from the source application into an XML format suitable for delivery to the destination application, and finally, A sink component is provided that can deliver the processed (converted) XML data to the destination application.

  In the following, further preferred embodiments of the present invention will be described in detail. Hereinafter, this will be referred to as embodiment A. Embodiment A is a specification of a special purpose programming language that precisely defines one possible format for an XML service / action electronic document, describes its semantics, and is further defined by Embodiment A. The implementation of the XSA engine written according to Embodiment A can be described as an example of an XML service action specification in a special purpose programming language designed for the management of XML processing tasks, and can be used by those skilled in the art to Specific implementations of the invention can be created in a computer system. Embodiment A can also be used as a precisely described framework for all the other embodiments described above.

  According to embodiment A, an XSA electronic document is written in a special purpose programming language based on an XML format that conforms to a document format definition (DTD). The XML electronic document effectively constitutes an XSA document, and may be referred to as an XSA definition here.

Below, the definition of the term used for description of Embodiment A is shown.
XSA execution engine: A software implementation capable of executing the XSA definition defined for embodiment A.

  XSA definition: Each XSA to be executed is specified as an XML document. The location and form of the document are not limited to the specifications of Embodiment A, and can be read from a storage medium, generated by a machine at the time of execution, or obtained by any other method. An XML document that describes one instance of XSA defined for embodiment A is called an XSA definition.

  XML operations: Each XSA definition consists of a number of XML operations. An XML operation is a unit of execution in XSA, and these are executed sequentially as defined in the XSA definition.

  XSA component: A component used in an XML operation is called an XSA component. Examples of XSA components include execution pipeline blocks, such as generators, converters, and sinks.

  While XSA components are always referenced within the XSA definition, the actual components used are defined outside the XSA definition, giving the implementer complete freedom in the programming language, implementation, and configuration of the components used.

  Generator: A generator is a component that generates XML data in some specific way. The method that the generator uses to create the XML depends on the implementation of the generator component that is used.

  Converter: A converter is a component that converts XML data in a certain way. The method used to convert to XML depends on the implementation of the converter component used.

  Sink: A sink is a component that distributes processed XML data. Distribution can include anything from holding XML data in memory in internal format to serializing it to some external format and storing it in a database.

  Pipeline: A pipeline combines a generator, a series of converters, and a sink to form a series of executions. XML data flows from the generator through the converter to the sink.

Conditional operations: Conditional operations can be used to determine which pipeline to execute and to control the flow of execution.
XSA context: Each XSA execution takes place in a context, giving access to a set of named variables through several named scopes.

  Scope: The XSA context stores all named variables in the scope. Scopes are requests, sessions, clients, users, and applications. Each scope has the meaning as defined later for embodiment A herein.

Variable: The term variable is used for name-value pairs stored in the XSA context. A variable has a name and a value and belongs to a certain scope.
The following describes the XSA-defined basic syntax elements used in defining XML operations according to Embodiment A.

  Each XSA definition written according to this specification in embodiment A must include a DOCTYPE declaration and set the public identifier to "-// Dimon // DTD XSA 1.1 // EN". This DTD is as follows.

[Table 1]
<!-
XML Service Action Specification for Embodiment A
Namespace = http: //www.dimon.is/namespaces/xsa
This DTD module has this PUBLIC identifier,
PUBLIC "-// Dimon // DTD XSA 1.1 // EN"
And this canonical system identifier.
SYSTEM "http://www.dimon.is/dtds/xsa/1.1/xsa/dtd"
The system identifier may change. The DOCTYPE declaration can be shown as follows:
<! DOCTYPE xsa PUBLIC "-.. Dimon // DTD XSA 1.1 // EN""xsa.dtd">
Review: DRAFT
->

<!-See component ID defined and configured somewhere in the server->
<! ENTITY% refid "refid CDATA #required">

<!-Specifications of named variables in a given range->
<! ENTITY% variablespec "
scope (request || session | client | user | application) #required
name CDATA #required ">

<!-General sub parts of action->
<! ENTITY% XML Operation "(pipeline | setvariable | removevariable | lif | operation)">

<!-Any value specifier. out-param-value is a special case and can only be used as a subordinate of out-param. Others can be used anywhere valuespec is in the content model->
<! ENTITY% valuespec "(null | literal | getvariable | mapping | out-param-value)">

<!-Batch expression of conditions->
<! ENTITY% anycondition “(and | or | not | isdefined | isoftype | equlas | condition)”>

<!-Batch representation of input / output parameter assignments a
<! ENTITY% inoutparam "(out-param | in-param)">

<!-Root element of any action specification->
<! ELEMENT xsa (support *, errordef *, (% XMLOperation;) +)>
<! ATTLIST xsa
version CDATA #required
xmin CDATA 'http://www.dimon.is/namespaces/xsa'
>

<!-Indicates the correspondence for a given adapter. If no corresponding element appears, it can be assumed that any adapter can call this XSA.
->
<! ELEMENT supports EMPTY>
<! ATTLIST supports
adaptername CDATA #required
>

<!-Define an error and the XSA to call in case of this error.
This content can be an English descriptive error message.
The name attribute is the name of the error and the call must give a reference to the XSA to call in case of this error.
->
<! ELEMENT errodef #PCDATA>
<! ATTLIST errordef
name CDATA #required
invokes CDATA #required
>

<!-Represents an operation that executes an XML pipeline.
Generators, transformers, and sinks are specified by nested elements->
<! ELEMENT pipeline ((generator | raiseerror), (transformer || raiseerror) *, (sink | raiseerror))>

<!-Represents the action of setting a variable in the scope.
The content specifies the value to set->
<! ELEMENT setvariable (% valuespec;)>
<! ATTLIST setvariable
% variablespec;
failonerror (true | false) "true"
>

<!-Represents the action of removing variables in the scope->
<! ELEMENT removevariable EMPTY>
<! ATTLIST removevariable
% variablespec;
failonerror (true | false) "true"
>

<!-Represents an action that performs each action in one after selecting between two action lists by evaluating a condition->
<! ELEMENT if (% anycondition;, then, else?)>

<!-Container for XML operation to be executed when the condition becomes true after evaluating the condition->
<! ELEMENT then ((% XML Operation;) *)>

<!-Container for XML operation to be executed when the condition becomes true after evaluating the condition->
<! ELEMENT else ((% XML Operation;) *)>

<!-Represents the instantiation of the generator that starts the SAX chain.
Browse to a generator factory configured anywhere and specify the parameters to call it->
<! ELEMENT generator ((% inoutparam;) *)>
<! ATTLIST generator
% refid;
>

<!-Represents the instantiation of the converter as part of the SAX chain.
Browse to a converter factory configured anywhere and specify the parameters to call it->
<! ELEMENT transformer ((% inoutparam;) *)>
<! ATTLIST transformer
% refid;
>

<!-Indicates the instantiation of the sink that terminates the SAX chain.
Browse to a sink factory configured anywhere and specify parameters to invoke it->
<! ELEMENT sink ((% inoutparam;) *)>
<! ATTLIST sink
% refid;
>

<!-If XPath evaluates to true, an error is issued.
The error attribute must contain the name of the error to issue, and the inspection attribute must contain the XPath to be evaluated->
<! ELEMENT raiseerror EMPTY>
<! ATTLIST raiseerror
error CDATA #required
test CDATA #required
>

<!-Representing the value of a given variable->
<! ELEMENT getvariable EMPTY>
<! ATTLIST getvariable
% variablespec;
>

<!-May take input parameters assigned by nested in-param elements that reference conditions defined elsewhere->
<! ELEMENT condition (in-param *)>
<! ATTLIST condition
% refid;
>

<!-AND condition, only true if all nested conditions are true->
<! ELEMENT and ((% anycondition;) +)>

<!-Inclusive OR condition, true only if one of the nested conditions is true->
<! ELEMENT or ((% anycondition;) +)>

<!-Negation condition, negation of nested condition->
<! ELEMENT not ((% anycondition;))>

<!-Is-defined condition, whether all nested values (any object) are non-null.
True if degenerate with no nested values->
<! ELEMENT isdefined ((% valuespec;) *)>

<!-Is-of-type condition, whether or not the first nested value (any object) is of the class named by the second nested value (string). If any is null, give false->
<! ELEMENT isoftype ((% valuespec;), (% valuespec;))>

<-Equal condition, tells whether the first nested value is equal to each other as determined by the equal method. True if all are null. If some are null and some are not, false.
Returns true if there is only one nested value
->
<! ELEMENNT equals ((% valuespec;) +)>

<!-Represents assigning a value to a named input parameter->
<! ELEMENT in-param (% valuespec;)>
<! ATTLIST in-param
name CDATA #required
>

<!-Represents a mapping that takes one or more input parameters and produces a result value. Input parameters are given by nested in-param->
<! ELEMENT mapping (in-param *)>
<! ATTLIST mapping
% refid;
>

<!-Represents assigning output parameter to variable->
<! ELEMENT out-param (setvariable)>
<! ATTLIST out-param
name CDATA #required
>

<!-Represents the value of the output parameter when used as a descendant of the out-param element. All other cases are illegal->
<! ELLEMENT out-param-value EMPTY>

<!-Represents the value of null (->)
<! ELEMENT null EMPTY>

<!-Represents the value specified by the character->
<! ELEMENT literal (#PCDATA)>

<!-Represents a custom XML action constructed by a given parser class. The parser class must be in the XSA parser class loader and have a default constructor.
This element may contain any XML. Either the XML is in a separate namespace (to avoid interference with this DTD) or this DTD is not run at the time of analysis.
->
<! ELEMENT operation EMPTY>
<! ATTLIST operation
parserClass CDATA #required
>

An example of a DOCTYPE declaration is as follows:

[Table 2]
<! DOCTYPE xsa
PUBLIC "-// Dimon // DTD XSA 1.1 // EN"
"http://www.dimon.is/dtds/xsa/1.1/xsa/dtd">

The root element of the XSA definition is <xsa>. If XSA was written according to this specification of embodiment A, it must contain a version attribute with a value of 1.1. An example of an empty root element can be as follows:

[Table 3]
<xsa version = "1.1" xmlns = "http://www.dimon.is/namespaces/xsa">
</ xsa>

Inside the root, the XSA definition contains any number of elements, as discussed below. Most of these elements correspond to XML operation. The types of XML operations will be discussed in more detail below, but the following list briefly describes each type of XML element allowed inside the root element according to embodiment A of the present invention.

  Pipeline: A pipeline is defined by a <pipeline> element. Pipelines combine generators, converters and sinks and use basic elements to process XML data.

  Variable: manipulated by the <setvariable> and <removevariable> elements and accessed by the <getvariable> element. A variable is a means for passing control information to an external XSA execution, receiving from the XSA execution, and internally passing between XSA components.

The variable is part of the XSA content. This is discussed in detail below.
Condition: A condition is defined by an <if> element. These can be used to control which XML operation is executed and which XML operation is not executed.

Custom operation: A custom operation is defined by an <operation> element. These can be used when performing any custom XML operation.
The syntax of each XML operation is discussed below. An example of the XSA definition according to the specification of Embodiment A can be as follows.

[Table 4]
<? xml version = '1.0'?>
<! DOCTYPE xsa
PUBLIC "-.. Dimon..DTD XSA 1.1 // EN"
"http://www.dimon.is/dtds/xsa/1.1/xsa.dtd">
<xsa version = "1.1" xmlns = "http://www.dimon.is/namespaces/xsa">
<setvariable scope = "request" name = "http.response.Content-Type">
<literal> text / plain </ literal>
</ setvariable>
<pipeline>
<generator refid = "index"/>
<transformer refid = "resourcetrax">
<in-param name = "xsl">
<literal> index.xsl </ literal>
</ in-param>
</ transformer>
<sink refid = "clipsersink">
<in-param name = "outputStream">
<getvariable scope = "request" name = "http.responsestream"/>
</ in-param>
</ sink>
</ pipeline>
</ xsa>

According to the specification of the special purpose programming language described in embodiment A, XSA definitions are executed in a linear order. This means that after each XML operation is fully evaluated, the next XML operation in the list is evaluated. Implementations must follow this ordering. This is because the setting of variables may depend on the order of execution.

The description of the execution context of Embodiment A is shown below.
XSA is executed to activate processing defined in the XSA definition. Each time XSA is executed, the XSA context is accessed. The XSA context exposes a set of variables defined in the scope. This specification does not define specific variable names, but all variables must belong to one of the following named scopes:

  This specification of embodiment A does not define read / write access to a particular variable regardless of the scope of the variable. Some embodiments attempt to meet this requirement by restricting access to certain variables as needed. For example, a variable in the user scope is allowed read access. Wouldn't allow write access. If the set limit is violated, an error must be generated and the error handling described below must be invoked accordingly. The details of the implementation are what errors occurred.

  To set a variable in the XSA context, as long as writing to that variable is allowed by the implementation, it must overwrite the previous value for that variable (if any value exists). The following scope is defined in this embodiment of embodiment A: The mapping of these scopes to the runtime environment depends on the implementation according to the specification of this embodiment A. The mapping to be performed must follow the description given below.

  Request: The request scope needs to persist after the current XSA execution, but need not persist any further. This contains data initialized by the XSA caller and the variables defined in this scope can be changed by executing the XSA. All implementations must support the request scope.

  Session: The session scope needs to persist between requests as long as the same session is used. The definition of “session” is left to the implementation example, but a trivial example is an HTTP session in the case of a web server using the XSA model. Corresponding to session scope is optional.

  Client: The client scope is used for data that applies to clients that have called XSA directly or indirectly. Client definition is left to the implementation, but one example is a browser that invokes a web page using the XSA model. Corresponding to client scope is optional.

  User: The user scope is used for data related to the user identity (usually a person) that invoked XSA directly or indirectly. Corresponding to user scope is optional, as the user's idea may not be applicable to many implementations of this specification of embodiment A. Even if some implementations support user identification, user scope is optional.

  Application: The application scope is used for data related to the application that the XSA is running. Application definition is left to the implementation of the XSA specification. Corresponding to application scope is optional.

  The specification of embodiment A of the present invention states that the scopes of a plurality of variables together form what is called an XSA context. It is useful to initialize the XSA context before running XSA, but it can be used again during XSA execution if desired. In that case, the implementation must clearly define when and when the XSA context is used again, avoiding potential security holes.

Below, the concept about the pipeline of Embodiment A of the present invention will be described in detail.
A pipeline defines a series of XML generators, converters, and sinks. Pipeline elements are XSA-defined XML operations.

  A pipeline is defined by a <pipeline> element. This contains an ordered list of elements, starting with a mandatory generator, followed by any number of converters, and then a mandatory sink.

  The data flow begins at the generator, creates the XML document (s) to be processed, passes through the converter, modifies the structure and content of the XML data, and finally ends at the sink, specifying Delivers or reacts to the form of data.

  Data flowing through the various parts of the pipeline is in XML format. This implementation does not need to hold this data in any particular format, and can use common APIs such as SAX and DOM. In addition to data flowing between components, input and output parameters can also be used for each component. The order of evaluation of these parameters is not restricted by this specification. This means that output parameters from the front component in the pipeline may not be available for input to the back component in the pipeline. The only constraint is that the pipeline must complete its parameter evaluation and execution before performing the next XML operation in XSA. The following describes the XSA component type used in the pipeline. Start with a description of the attributes common to all component types.

  XSA components are used in pipelines to perform some form of work during pipeline execution. The XSA component is defined externally and is quoted from the XSA definition. The method used to define the XSA component, the nomination method used to cite the XSA component, and the interface implemented by the XSA component are implementation details that are not addressed in this specification of Embodiment A. .

  The name of the component instance to be used is given in the refid attribute of the XSA component. This reference must always refer to the same object instance defined by the programming language in use, and if the object is modified in any way, all XSA definitions that refer to it will also It must be updated accordingly.

In addition to being quoted externally, XSA components share one or more common abilities, ie input and output parameters.
Each XSA component can be defined with any number of named input and output parameters. Within the XSA definition, input parameters are given with an <in-param> element and output parameters are given with an <out-param> element.
The format of the <in-param> element is as follows.

[Table 5]
<in-param name = "xsl">
<!-Value specification->
</ in-param>

The format of the <out-param> element is as follows.

[Table 6]
<out-param name = "xsl">
<setvariable ...>
...
</ setvariable>
</ out-param>

The name of each input and output parameter is defined by the component implementation.

The generator components specified for embodiment A of the present invention are described below.
The generator is an XSA component that is used to create XML data for processing in the pipeline. How the generator creates XML varies from implementation to implementation, including reading XML from a file, importing it through a network, accessing a database, and converting the data to XML. included. The generator output must always be correctly formed in the internal representation of the XML implementation. The XSA execution engine enforces this requirement on each generator, but it does not have to.

  The generator is always defined at the beginning of the pipeline and is required in all pipelines. The <generator> element is used to define a generator in the pipeline. As with all XSA components, the generator supports named input and output parameters. The format of the <generator> element is as follows:

[Table 7]
<generator refid = "mygen">
<in-param name = "myinparam">
...
</ in-param>
...
<out-param name = "myoutparam">
...
</ out-param>
...
</ generator>

In the following, the transducer component specified in embodiment A of the present invention will be described.

  A converter is an XSA component that is used to convert data from one XML format to another. How the converter processes the XML varies from implementation to implementation, which uses XSLT, applies custom coded modifications to text nodes, sorts , Judging effectiveness, and the like. The output of the converter is always required to be correctly formed in the internal representation of the XML implementation, and its input also comes from either the generator or another converter, both of which are correctly formed Since it is required to generate XML, it is correctly formed. The XSA execution engine enforces this requirement on each converter, but it does not have to. A converter is not required in the pipeline definition. When a converter appears, it always appears after the generator and before the sink. The <transformer> element is used to define a transformer in the pipeline. As with all XSA components, the transducer supports named inputs and outputs. The format of the <transformer> element is as follows:

[Table 8]
<transformer refid = "mytran">
<in-param name = "myinparam">
...
</ in-param>
...
<out-param name = "myoutparam">
...
</ out-param>
...
</ transformer>

Hereinafter, the sink component specified in the embodiment A of the present invention will be described.

  A sink is an XSA component used to handle an internal representation of XML data obtained from processing executed in a pipeline. What the sink does with XML varies from implementation to implementation, including writing the XML to a file, sending it as HTML to a web browser, or generating a PDF from it. This is correctly formed because the generator or converter always generates the input to the sink. No limit is set for the output from the sink.

  A sink is always defined at the end of the pipeline and is required in all pipelines. The <sink> element is used to define a sink in the pipeline. As with all XSA components, sinks correspond to named input and output parameters. The format of the <sink> element is as follows:

[Table 9]
<sink refid = "mysink">
<in-param name = "myinparam">
...
</ in-param>
...
<out-param name = "myoutparam">
...
</ out-param>
...
</ sink>

The variable and value specifications according to the XSA specification of Embodiment A of the present invention will be described below.

Variable operations in XSA always apply to variables in the XSA context.
Variables can be set and removed on the root level of XSA definitions and within conditions. Use the <setvariable> element to set a variable, and the <removevariable> element to remove a variable. The failonerror attribute defines whether to stop the operation when an error occurs, and is true by default.
The format of the <setvariable> element according to the specification of Embodiment A of the present invention is shown below.

[Table 10]
<setvariable scope = "request" name = "var" failonerror = "true">
<!-Specify value->
</ setvariable>

The format of the <removevariable> element according to the specification of Embodiment A of the present invention is shown below.

[Table 11]
<removevariable scope = "request" name = "var" failonerror = "true"/>

A scope attribute is required and must be set to one of request, session, client, user, or application.

A name attribute is required and specifies the name of the variable within the specified scope.
Different value specifications can be defined using <null>, <literal>, <getvariable>, <mapping>, and <out-param-value> elements. These will be described in turn below. In a specific XSA context, a value is obtained by specifying the value and used as an input to the <setvariable> operation.

  The <null> value specification always obtains a null reference in the Java programming language or an equivalent value in binding with another language. This element has no content or attributes. Setting a variable to null has the same effect as setting no variable at all. The <literal> value specification defines the character data used for the value. This seeks the text contained in the <literal> element, regardless of the XSA context. A component can convert this to a number, date, or other simple format, but such typing is outside the scope of the XSA specification and implementation. An example of a <literal> element is as follows:

[Table 12]
<literal> This is a character value </ literal>

The <getvariable> variable specification finds the value of a variable with a given name in a given scope. The scope and name are given as attributes. No content is allowed for <getvariable>. An example of a <getvariable> element is as follows:

[Table 13]
<getvariable scope = "request" name = "var"/>

A scope and name attribute is required, and the scope attribute must be set to any one of request, session, client, user, or application.

  The <mapping> value specification is used when referring to a custom value specification that is not defined by the XSA specification of Embodiment A. This can have the same input parameters as the XSA component, as defined above, but cannot have output parameters. An example of the <mapping> element is as follows.

[Table 14]
<mapping refd = "mymapping">
<in-param name = "myparam">
<literal> literalValue </ literal>
</ in-param>
</ mapping>

The <out-param-value> value specification can only be used as a descendant of the <out-param> element, and the <out-param> element is used in the XSA component in the pipeline and is defined earlier. When inside an <out-param> element, <out-param-value> contains the value of the output parameter and can be used as an input for other operations, for example, to store the value of the output parameter . An example of an <out-param-value> element in the context of an <out-param> element is as follows:

[Table 15]
<out-param name = "out">
<setvariable scope = "request" name = "var">
<out-param-value />
</ setvariable>
</ out-param>

The conditional operation defined by the specification of Embodiment A of the present invention will be described below.

Conditional operations can be used to control which XML operations are executed. These are intended to choose between different pipelines to be executed.
All conditions are given in the root <if> element. A conditional action is a Boolean logic element, and if true, the XML action contained in the <then> element is executed. If the Boolean element evaluates to false, an optional <else> element can contain the XML action to perform in that case. Note that <if> itself is an XML action element, so conditional actions can be nested.
<if> The format of the XML operation is as follows.

[Table 16]
<if>
<!-One of Boolean logic elements, and, or, not, isdefined, isoftype, equals, condition->
<then>
...
</ then>
<else>
...
</ else>
</ if>

Hereinafter, various Boolean logic elements defined to be used in the <if> element according to the specification of Embodiment A of the present invention will be described.

The <and> element defines an AND Boolean logic operator. The content of the <and> element is one or more Boolean logic elements.
The <or> element defines an OR Boolean logic operator. The content of the <or> element is one or more Boolean logic elements.

The <not> element defines a NOT Boolean logic operator. The content of the <not> element is another Boolean logic element.
The <isdefined> element contains zero or more value specifications, as defined above, and is true if all values are non-null, as defined by implementation language binding. It becomes. The <isdefined> element is true if no value specification is included.

  The <isoftype> element must contain two value specifications, as defined above, and is true if the first value is the type specified by the second value. Here, the meaning of “type” is defined by implementation language combination. If both values are null, this element is false.

The <equals> element contains one or more value specifications as defined above, and is true only when all values are "equal" as defined by the implementation language combination.
The <equals> element is true if all values are null. False if some are null but not all. If only one value specification is specified, <equals> is true (even if the value is null).

  The <condition> element is used to define custom conditions. This has the same definition as the XSA component, as defined above, except that it does not correspond to an output parameter. How Boolean results are evaluated depends on the implementation of the custom condition. The error handling specification according to Embodiment A of the present invention will be described below.

  Error handling is doubled when XSA by element A is used. First, there is an error definition that can be used to define an error and what to do in case of that error. Second, errors can occur at any time during pipeline execution.

The meaning of the named error is not specified in this specification of embodiment A. That is, in this specification, a prescribed error is not given.
Each implementation according to this specification of Embodiment A must have a generic fall-back error mechanism, which is consistent with the errors defined for the XSA definition. If not, deal with error handling. This specification does not define how this error handling works and what to do in case of an error.

  Errors are defined by name, and each XSA designation can specify what to do if a named error occurs. Errors are defined in the XSA-defined route before any XML operation. Names used in error definitions must follow a tree structure, with a dot (.) Character separating the names at each tree level. At each level, all alphanumeric ASCII characters are allowed. An example of a correct error name is something.error.specific. This structure is used to select which error definition should be used when an error is invoked.

  The <errordef> element is used to define an error. The name attribute contains the name of the error, and the call attribute must give a reference to the XSA definition and be called when an error occurs. The content of the <errodef> element can contain a human-readable description of the error and is used only for debugging purposes, such as printing to a log. The format of the <errordef> element is as follows:

[Table 17]
<errordef name = "some.error.name" invokes = "erroHandling.xsa"/>

You can check XPath conditions at any time during pipeline execution. If the XPath condition is true (as defined by the XPath specification), search the error definition for the closest match.

The matching mechanism tokenizes the error name with dots. For example, tokenize the error something.errorspecifc to something, error and specific. Use the error definition that has the highest degree of matching and contains tokens in the same order. In this same example, if an error definition exists for errors something.bogus, something.error and something.error.morespecific, the XSA definition quoted from something.error error definition is called. Because something.error.morespecific is not a match.
The format of the <raiseerror> element is as follows:

[Table 18]
<raiseerror test = "/ some / xpath / to / test" error = "some.error.name"/>

A given XPath must be able to access all scoped variables throughout the XPath parameter using the format $ scope: variable-name.

  In one implementation, the error name of itself can be freely defined, and the XSA definition can handle execution errors in the XSA engine. An example would be the case where several resources are lost and an error can occur, and the XSA definition can define what to do in that case. This implementation must publish the error code and not save the error. That is, all errors can be ignored in the XSA definition.

In some implementations, the error handling XSA definition must be executed using the same XSA content that was used for the XSA definition that caused the error.
The custom operation according to the specification of Embodiment A of the present invention will be described below.

  The <operation> element can be used when referring to a custom XML operation. The only configuration defined is the ParseClass attribute, which must be used to parse the contents of a custom XML operation by naming the parser used. The method for mapping this name to a parser implementation, and the programming level interface that the parser must implement, is specific to each XSA implementation.

  The contents of the <operation> element must be available to the parser being used, and the parser can use it to define the operation. The content of the element may be entered in a namespace that is separate from the XSA namespace to avoid current and future conflicts.

The following describes XSA execution according to the specification of Embodiment A of the present invention.
The XSA execution engine must always execute the XSA definition within one XSA context. The whole of creating XSA content and executing XSA is called an adapter. An example of an adapter is an HTTP adapter that takes an HTTP request, selects an XSA definition, creates its context based on the information in the HTTP request, and then executes the XSA definition.

  No rules or registration is required for the adapter name. This is considered specific to each XSA implementation. However, since an implementation can define an adapter name, the XSA definition can embed information that allows the adapter to significantly perform XSA. This can be done using a <supports> element with one attribute adaptername. Before any XML operation, any number of <supports> elements can be placed at the beginning of an XSA definition. If no <supports> element appears, the XSA implementation must assume that any adapter can invoke XSA.

  An example of the <supports> list is presented below. This example shows that the XSA definition may only be executed on adapters HTTP and FTP. The adapter named FILE must be prohibited from executing this XSA by the XSA implementation.

[Table 19]
<xsa>
<supports adaptername = "HTTP"/>
<supports adaptername = "FTP"/>
...
</ xsa>

With the detailed description of embodiment A above, one skilled in the art can form a connection to a programming language, such as the Java programming language. An example of a valid XML service action document based on the detailed XSA specification defined by embodiment A of the present invention is shown below. This does not show all the features of the XSA specification defined by Embodiment A.

[Table 20]
<? xml version = '1.0'?>
<! DOCTYPE xsa
PUBLIC "-// Dimon // DTD XSA 1.1 // EN"
"http://www.dimon.is/dtds/xsa/1.1/xsa.dtd">
<xsa version = "1.1" xmlns = "http://www.dimon.is/namespaces/xsa">
<supports adaptername = "HTTP"/>
<if>
<isdefined>
<getvariable scope = "request" name = "http.get.param"/>
</ isdefined>
<then>
<pipeline>
<generator refid = "index"/>
<transformer refid = "resourcetrax">
<in-param name = "xsl">
<literal> index.xsl </ literal>
</ in-param>
</ transformer>
<sink refid = "clipsersink">
<in-param name = "outStream">
<getvariable scope = "request" name = "http.responsetream"/>
</ in-param>
</ sink>
</ pipeline>
</ then>
<else>
<pipeline>
<generator refid = "alt"/>
<transformer refid = "alttrax">
<in-param name = "xsl">
<literal> alt.xsl </ literal>
</ in-param>
</ transformer>
<sink refid = "clipsersink">
<in-param name = "outputStream">
<getvariable scope = "request" name = "http.responsestream"/>
</ in-param>
</ sink>
</ pipeline>
</ else>
</ if>
<xsa>

This concludes the detailed XSA specification description of the special purpose programming language defined by embodiment A of the present invention.

  Although the present invention has been described as having exemplary embodiments, this patent application is intended to cover any variations, specifications, or modifications using its general principles. Moreover, this patent application is intended to cover any deviations from the present disclosure as fall within the known or customary practice within the art to which it belongs. The spirit and scope of the present invention shall be limited only by the terms of the appended claims.

FIG. 1 is a block diagram of an example of a general purpose system that provides an operating environment suitable for the present invention. FIG. 2 is a block diagram illustrating the main types of modules controlled by XML service actions written in a special purpose programming language specifically designed for the management of XML processing tasks. FIG. 3 is a block diagram illustrating the execution of an XML processing task defined by an XML service action, written in a special purpose programming language. FIG. 4 is a flowchart showing the flow of execution of the XML service action. FIG. 5 is a block diagram illustrating the role and typical structure of the generator defined by the XML service action model. FIG. 6 is a block diagram illustrating the role of the converter defined by the XML service action model. FIG. 7 is a block diagram showing the role of the sink defined by the XML service action model.

Claims (25)

A management system for execution of tasks including context independent processing of structured data,
-Means for receiving requests from external clients;
-A context-independent engine;
-At least one adapter module that communicates between the external client and the context independent engine to adapt the context independent engine to a specific application context;
Connected to at least one back-end system residing on the computer network and exposing the at least one back-end system data as structured data ready for further processing At least one generator module configured as follows:
-Connected to the at least one converter, receiving the processed structured data, interpreting and reacting according to the processed structured data, and the requesting external client through the adapter module; At least one sink module configured to perform one or both of returning structured data processed;
With
The communication between the external client and the context-independent engine is a predefined set of electronic documents written in a special purpose programming language designed to manage the processing of any structured data. A management system comprising means for selecting at least one generator module and at least one sink module to perform processing of the structured data according to instructions.   2. The management system of claim 1, connected to the at least one generator module, configured to receive the structured data from the at least one generator and convert it into processed structured data. Management system with one or several transducer modules.   The management system according to claim 1, wherein the context independent engine reads and interprets the electronic document written in the special purpose programming language, thereby controlling execution within the management system.   4. The management system according to claim 1, wherein the structured data is processed in an extensible markup language (XML) format.   5. The management system according to claim 1, wherein the adapter module receives a request received by a hypertext transfer protocol (HTTP) and can respond to the request.   6. The management system according to claim 1, wherein the adapter module receives a request received by a short message service (SMS) and can respond to the request.   7. The management system according to claim 1, wherein the adapter module receives a request received by a multimedia message service (MMS) and can respond to the request.   The management system according to claim 1, wherein the adapter module receives a request received by a simple object access protocol (SOAP) and can respond to the request.   9. The management system according to claim 1, wherein the converter module is capable of transforming XML data using Extensible Stylesheet Language Transformations (XSLT). 10. A management system according to any of claims 1 to 9, wherein the at least one generator module comprises the following back end system-any OBBC or JDBC compliant database
A file system on a computer running the management system,
Any data source that can communicate using the Hypertext Transfer Protocol (HTTP),
-Any data source that can communicate using Simple Object Access Protocol (SOAP);
-Microsoft Exchange ™ personal information management (PIM) system,
-Lotus Domino ™ personal information management (PIM) system,
Any directory service with Lightweight Directory Access Protocol (LDAP);
Any email system with Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP / POP3) or Internet Message Access Protocol (IMAP),
A management system configured to communicate with at least one of the plurality and convert their native data format to XML format. The management system according to any one of claims 1 to 10, wherein the system is a presentation system,
At least one adapter module that receives requests for content residing in the back end system from at least one network client;
A converter module for converting XML source content into markup suitable for said at least one client in at least one step,
-Converting the XML source content into markup independent of the client;
Adapting the client independent markup to a version suitable for the particular type of client that requested the content;
Said converter module comprising:
A sink module for delivering the markup to the client;
Management system equipped with. 12. The management system according to claim 1, wherein the format of the request from the at least one client is the following format: portable document format (PDF),
-Client specific hypertext markup language (HTML),
-Client specific wireless markup language (WML),
-Short Message Service (SMS),
-Multimedia message service (MMS), and-Compact HTML (cHTML),
-XHTML,
A management system that is one of The management system according to any of claims 1 to 12, wherein the system is a messaging system;
-At least one adapter module configured to communicate with an external system through a standardized electronic business protocol;
-At least one generator module configured to extract business data from the source and destination systems and publish it as XML;
-At least one converter module configured to convert the associated XML business source data into a business message;
-At least one sink module configured to deliver the business message;
Management system equipped with.   14. The management system according to claim 1, wherein the standardized business protocol is an electronic business XML (ebXML). 15. The management system according to claim 1, wherein the system is an integrated system.
Means for initiating execution of an XML processing task without a call from an external client;
-Means for synchronizing data between different source and destination systems,
At least one generator module extracts data from the source system and converts it to XML source data;
At least one converter module converts the XML source data into an XML format suitable for delivery to the destination system;
At least one sink module has means for delivering the processed XML to the destination system;
The data synchronization means;
Means for business process management and execution, wherein each task of the business process is defined and executed as a single XML processing task;
-A means for publishing a set of hypertext files on the World Wide Web along with information on the status of running business processes;
Management system equipped with.   16. The management system according to claim 1, wherein the request from the external client contains information or data, which is used by the adapter module to determine which electronic document to execute. Management system. A method for managing and executing structured data processing tasks in a network comprising a plurality of network devices, comprising:
A step of receiving an execution request of a predetermined context-dependent structured data processing task defined by an instruction set from an external client, wherein each of the structured data processing tasks is used for managing processing of all structured data; Encoding into a set of instructions using a special purpose higher level programming language designed for
-Interpreting the instruction set to determine validity; setting a context-dependent execution environment based on the instruction set and information found in the request from the external client;
-Executing said context-dependent structured data processing task, said execution comprising:
Connecting to a back end system on the network and converting native back end system data to structured source data, and optionally,
Converting the source structured data into processed structured data;
Performing one or both of reacting to the processed structured data and returning the processed structured data to the requesting client in some way;
Including steps, and
A method.   The method of claim 17, wherein the processing of the structured data is performed in an extensible markup language (XML) format.   19. A method according to claim 17 or 18, wherein the request is received by a hypertext transfer protocol (HTTP).   20. A method according to any of claims 17 to 19, wherein the request is received by a short message service (SMS).   21. A method as claimed in any of claims 17 to 20, wherein the request is received by a multimedia message service (MMS).   22. A method as claimed in any of claims 17 to 21, wherein the request is received by a simple object access protocol (SOAP).   23. A method as claimed in any one of claims 17 to 22, wherein the XML data is transformed using extensible stylesheet language transformation (XSLT). 24. A method according to any of claims 17 to 23, wherein converting the source structured data into processed structured data comprises the following back-end system--OBBC or JDBC compliant database:
A file system on a computer running the management system,
Any data source that can communicate through the Hypertext Transfer Protocol (HTTP),
Any data source that can communicate through Simple Object Access Protocol (SOAP),
-Microsoft Exchange ™ personal information management (PIM) system,
-Lotus Domino ™ personal information management (PIM) system,
Any directory service with Lightweight Directory Access Protocol (LDAP);
Any email system with Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP / POP3) or Internet Message Access Protocol (IMAP),
Including a conversion from a format corresponding to at least one of the above to an XML format.   A computer readable medium having stored thereon instructions for causing a central processing unit to execute the method according to any one of claims 17 to 24.

Images