WO2003021375A2 - Technology independent information management - Google Patents

Technology independent information management Download PDF

Info

Publication number
WO2003021375A2
WO2003021375A2 PCT/SE2002/001594 SE0201594W WO03021375A2 WO 2003021375 A2 WO2003021375 A2 WO 2003021375A2 SE 0201594 W SE0201594 W SE 0201594W WO 03021375 A2 WO03021375 A2 WO 03021375A2
Authority
WO
WIPO (PCT)
Prior art keywords
service
environment
recited
instance
user
Prior art date
Application number
PCT/SE2002/001594
Other languages
French (fr)
Other versions
WO2003021375A3 (en
Inventor
Sven Johan Belin
Mats Göran BLOMBERG
Pernilla Rut Charlotte Flyg
Nils Martin ÅGREN
Original Assignee
Sven Johan Belin
Blomberg Mats Goeran
Pernilla Rut Charlotte Flyg
Aagren Nils Martin
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sven Johan Belin, Blomberg Mats Goeran, Pernilla Rut Charlotte Flyg, Aagren Nils Martin filed Critical Sven Johan Belin
Priority to US10/525,769 priority Critical patent/US20060047709A1/en
Priority to AU2002329148A priority patent/AU2002329148A1/en
Priority to EP02765744A priority patent/EP1546877A2/en
Publication of WO2003021375A2 publication Critical patent/WO2003021375A2/en
Publication of WO2003021375A3 publication Critical patent/WO2003021375A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/465Distributed object oriented systems

Definitions

  • the present invention relates generally to management and access of information. More specifically, the present invention relates to technology or platform independent management and access of information, computer implemented services and computerized functionality.
  • the overall object of the present invention is to solve the problem of achieving a technological platform where objects for example in the shape of information, executable software code or apparatuses with possibly heterogeneous properties can interact 5 and collaborate in manner that is perceived to be homogeneous.
  • the above mentioned object and the different problem aspects are in accordance with the invention addressed by means of an improved object oriented concept thinking realized in a distributed object oriented architecture (in short herein also called object architecture).
  • the inventive distributed object oriented architecture comprises an object definition language, which is a subset of the extensible Markup Language.
  • the Object Definition Language enables object developers to define objects, independent of hardware -technology, -configuration, network -topology, -semantics, -protocols, logic implementation language and physical differentiation. It provides the developer with an abstraction, enabling the developer to focus on the object's interface and functionality. This enables the developer to isolate the native/technology-dependent aspects of the object.
  • the objects of the invention is achieved by means of the below method for processing data objects in a distributed data processing system, and realizations in the form of a system or a computer program product.
  • the distributed data processing system has a plurality of software and/or hardware nodes that are mutually communicatively connectable or couplable.
  • An embodiments of the method comprises the steps of: defining a first environment, called object runtime environment, for processing objects at a first level of abstraction that is independent of the software/hardware platform of said nodes; defining a second environment, called native environment, for processing objects at a second level of abstraction that is dependent on the software/hardware platform of said nodes; defining in said first environment a first object model with a first category of object aspects, i.e. generic or platform independent aspects; defining in said second environment a second object model with a second category of object aspects, i.e.
  • predefined object connectivity means in the shape of software code portions and protocols communicatively coupled to o said first, platform independent environment, are devised to interface with and execute data communications between an internal entity situated within and an external entity situated without said defined first and second environments.
  • an instance of said first, platform independent environment is configured together with an instance of said second, platform dependent 5 environment and object connectivity means to constitute a service provider functionality.
  • an instance of said first, platform independent environment is configured together with an instance of said second, platform dependent environment to constitute an object consumer functionality.
  • a object provider functionality is preferably configured together with o and a service consumer functionality constituting a consumer/provider subset of the distributed system, also called a federation (explained below) within which the processing of objects or object instances is performed.
  • Seamless transition between software objects and software components is achieved by providing a common development model for objects and for software 5 components.
  • information is preferably stored in a common format, heresometimes called the extensible Document Format (below also referred to as XDF format) which is the single document format of the system.
  • XDF format is used to describe any type of functionality or content.
  • There is no type attribute connected to an XDF document and therefore there is no difference between a data file, such as a document or an image, and an application of executable program code, in the way the information is structured and stored. From the user's point of view, there is no difference between for 5 example a document and a data communications service.
  • a result and an important feature of the present invention is that a user that operates and interfaces with a data processing system or a data base designed in accordance with the inventive concept may conveniently gain access to the same information with any connectable data communication device independent of its technical platform. That is, the 0 information is accessible whether the user operates from for example a conventional computer, a WAP device, a mobile phone or any other communication device that is connectable to the system via the for example the Internet without the need for any cumbersome conversion or synchronization routines.
  • the system in accordance with the invention automatically performs any 5 required adaptation or profiling of the format of data for the user to gain access to an object e.g. in the shape of information or a service, such as the processing of data in a user-centric service.
  • objects according to the invention are made platform independent.
  • a user may thus start working with an object such as a document by means of a service, such as a word processor, by using one type of communication device or processing device, e.g. a o desktop computer. Then the user can continue working with the same document using a different type of communication or processing device such as a PDA or WAP phone.
  • the invention makes it possible to make available upon request different services, for example a word processing service provided at remote site or apparatus, e.g. a central site or another node in a distributed system.
  • a user may thus gain access to the 5 requested word processing service without having a word processing program installed on the communication device that is used by the user to communicate with the system.
  • a user may gain access to very powerful services, functionalities and resources provided at a remote site or apparatus, e.g. a central site or another node in a distributed system, although the communication device itself is relatively primitive because it is not necessary for the communication device to have any powerful programs installed.
  • the inventive concept comprises functionality to treat objects and components alike. That is, the inventive object architecture does not make any semantic or programmatic difference between an object and a component. When an object becomes more complex, the complexity is delegated for example by means of compositions or aggregations. Objects that delegate functionality then seamlessly transfer to behave like or perhaps even be an entity that in prior art often is referred to as a component. In the invention an object can therefore be developed and treated either as a software component or an object, but the inventive object architecture makes no difference between the two and therefore a program developer is freed to develop a program solution that is neither larger nor smaller than necessary.
  • Object An entity that encapsulates information, processes and behaviors as specified by the accepted principles of Object Orientation.
  • the word is in this text used to define an object built and based on the technology according to the invention, which in some respects differs from prior art definitions. Also the word object is used to identify a non-instantiated object.
  • a second object interacting with the first object is an external actor.
  • the Object Definition Language is used within the technology according to the present invention to define objects and in this text refers to a specifically developed language. Federation A system according to the invention in which a
  • Runtime Environment for the first time, some additional steps are required; decoding object definition, merging object definitions, decoding runtime descriptor, cache object definition etc. These additional steps are referred to as deploying an object, object deployment or a deployed object throughout this description. In contrast with prior definition of deployment, here deployment refers to a process that is performed o autonomously and not by a system administrator or a developer.
  • Fig. 1 is a schematic collaboration diagram of the operating system of the present invention
  • 5 Fig 2 is a schematic block diagram of illustrating components in embodiments of the invention.
  • Fig 3-5 show exemplifying scenarios of signal communication between different components in embodiments of the invention.
  • the invention is dependent on the application realized as a method, an apparatus or system, or as a computer program product.
  • An apparatus or system would typically comprise data processing means having a central processing unit (CPU), data storage means, an input/output interface and data communication means.
  • the apparatus or 5 system would then be set up to execute steps of the inventive method by means of specifically designed computer program code.
  • the invention when realized as a computer program product, would typically comprise computer program code portions that are devised to direct a data processing system to perform steps and functionality of the inventive method or apparatus.
  • the invention is explained with reference to schematic drawings that depict functional units that in different embodiments may be realized as method steps, hardware units or computer program code portions. For the sake of simplicity the distinction between different realizations is not always mentioned in the below description of embodiments.
  • the invention is preferably implemented in terms of an object oriented concept.
  • Objects are created, that is defined and established, exist and operate in an object runtime environment constituted by a possibly distributed system of data processing devices provided with software for realizing a platform independent data processing method in accordance with the invention. Possibly, a plurality of different object runtime environments exists side by side, and may also communicate.
  • Objects can also exist in the native environment and it is proper to define different aspects of an object, namely the generic, platform independent aspect and the native, platform dependent aspect. If an object contains one or more native aspects, the object is also defined native as such.
  • Objects that are defined native have two object models, namely one in the Object Runtime Environment and one in the Native Environment.
  • the model existing in the Native Environment is populated with all native aspects of the object.
  • Both object models can interact with each other.
  • native methods can invoke non-native methods within the same object and vice versa (with the extension that objects can invoke native methods in other objects also).
  • any attributes defined native are always kept coherent in the two object models. For example, if the attribute value is changed in one object model, the change is propagated to the other object model.
  • the majority of all objects that are created should be totally platform independent. Only a small number of objects will contain any native representations. Such objects (e.g. Image object, Text object, AudioPlayback object etc.) implement functionality that is futile to support as platform independent, without a devastating amount of development and administrative implementation work. Instead these native objects, i.e. objects containing native aspects, will be the most atomic building blocks for other objects to use.
  • An effect of the platform independent generic aspect of objects in accordance with the invention is that each object only has to be defined once, and can thereafter be delivered to all different types of devices for which there an object consumer runtime environment (further explained below).
  • GUID globally unique identification number
  • GUID globally unique identification number
  • a globally unique identification number GUID must be guaranteed uniqueness on all involved software devices within the implementation. The effect of this is that the objects of the invention are or can be truly and entirely distributed in the sense that they can exist on an arbitrary number of clients and communicate with an arbitrary number of servers.
  • An attribute can hold or store basic entities called primitives, more specifically a primitive, a runtime primitive, a custom primitive, or it can hold a reference to another object.
  • An attribute can be declared native, which means that it operates in an environment, called native environment, that is dependent on a specific technical platform at a level below the platform independent level. This is further explained below.
  • an attribute is unable to be exposed directly to other objects, instead attributes must be accessed through accessor and mutator methods defined in the invention.
  • Data of different kinds is accessed or stored through a set of primitives that is used to contain data.
  • Data can also be stored in other objects or object instances that a first object has a reference to, in which case the reference is stored as an attribute.
  • a mail object can have a reference to a recipient object.
  • the storage of more complex data can be realized as a mixture of primitives and objects, and example a mail object can have a collection of attachment objects.
  • Different embodiments comprise one or more among the following primitives. It is also possible to define other primitives within the inventive concept.
  • Number A primitive that can contain any type of numerical value, for example integer, decimal (floating point) or big decimal. The type is determined by the value inputted by the developer of the implementation.
  • String A string primitive contains a universal character set transformation format UTF. There are for example an UTF-8 or an UTF-16 string value.
  • Boolean A boolean primitive contains a boolean value, for example expressed as a single bit dependent on the implementation.
  • Collection A collection primitive is able to contain primitives (including collection primitives), runtime primitives, custom primitives and object references.
  • the data contained in the collection primitive should be contained in a structure independent way.
  • the collection can then be treated as any type of collection, such as map, vector, array, list, linked list or the like.
  • Transaction A transaction resource contains a reference to a globally unique transaction that has been performed or executed.
  • Runtime primitives are primitives that are local for the Object Runtime Environment in which they were created and populated. Runtime primitives are transient by nature, and they are not allowed to be serialized and/or distributed to another Object Runtime Environment.
  • an object When an object is serialized it is stored in a format that can be transmitted over a network or it is stored on a persistent medium, such as a hard disk. In an alternative wording the complex format of an object is stored for example as a binary stream or as an XML-document.
  • serialization when an object is transferred as binary data, an object is distributed by sending an object reference to certain recipients.
  • Embodiments of the invention comprises:
  • Container A native container is a runtime primitive that represents a graphical user interface container (e.g. a window) that is used to project presentation objects.
  • Custom primitives e.g. a graphical user interface container (e.g. a window) that is used to project presentation objects.
  • Custom primitives are custom defined primitives, defined by an object vendor or an object developer.
  • An example usage of custom primitives is a primitive pertaining to a Java Technology Object.
  • a custom primitive is by default not transient, but may be declared transient by the object vendor.
  • An attribute can contain a reference to an instance of another object. Such a reference is used to invoke methods that operate on the current object instance.
  • An object is accessed or activated by means of an object operation method, which is a portion of executable software code designed to perform a specific task of the object.
  • the object operation methods is the only part of the object that is directly exposed to other objects and is available in order on one hand to execute functionality or operations and on the other hand to access or manipulate data that is encapsulated in the object.
  • Each object operation method has a definition that defines its name and its return value. For each object operation method an unlimited number of unique method implementations can be declared. The uniqueness of an object operation method implementation, or an object operation method signature, is based on the number of arguments, argument names, and argument types it requires.
  • an object operation method can be implemented in any programming language that is supported by the current embodiment.
  • An object operation method can be invoked synchronously or asynchronously. When invoked synchronously, the execution will block until the method invocation is complete, optionally resulting in a return value. If invoked asynchronously, the execution will not block. Instead, the external actor specifies an object instance that will be interfaced by the Object Runtime Environment when the method invocation is complete, attaching any return value as an argument. Also, an external actor such as a user, device or another object can specify a specific object instance to be used to monitor or observe the invocation of the object operation method. As mentioned above, an object that is defined as native have two object models, i.e. one in the runtime environment and one in the native environment. Both object models can interact with each other.
  • native methods can invoke non-native object operation methods within the same object and vice versa.
  • objects can invoke native object operating methods in other objects too.
  • any attributes defined as native are always kept coherent in the two object models. For example, if the attribute value is changed in one object model, the change is propagated to the other object model.
  • Object Definition An object is defined by its Object Definition. It defines the object's attributes, methods, presentation, inheritance, concurrency, transaction isolation etc.
  • Object Blueprint An object blueprint defines an interface of an object, or blueprint, that is exposed to external actors. The blueprint is created automatically from the Object Definition.
  • Object Deployment Descriptor An object deployment descriptor declares the usage and the level of usage of Object Runtime and Native Environment built-in services such as 5 transactions, concurrency, garbage collection, secure communication, etc. Two Deployment Descriptors can exist for any object; one that is a part of the object and one that can be supplied by other functionalities of the system.
  • An object instance When an object is instantiated or an object reference is de-serialized, i.e. when an object represented with binary data or XML is transformed to its proper format, 0 an object instance is created.
  • An object instance can exist in two different modes, viz. active or inactive.
  • An active instance is an object instance currently deployed in an Object Runtime Environment and its inactive counterpart is an object instance currently serialized.
  • An active instance is always local for an Object Runtime Environment and is unable to be directly accessed or interfaced by an external actor.
  • An object instance is always interfaced using an 5 object reference.
  • Object Reference External actors never interact with an object instance directly. Instead there is always an object reference that references the object instance. So for example: If an object instance A (that is located in Object Runtime Environment A) wishes to interact with an object instance B (that is located in Object Runtime Environment B), the object instance o A must first acquire a reference to instance B. The acquired object reference is then located in Object Runtime Environment A, whilst the actual object instance is located in Object Runtime Environment B.
  • Objects in the Form of ODL Documents 5 are preferably defined in the Object Definition Language, which is a subset of the extensible Markup Language.
  • the Object Definition Language enables object developers to define objects, independent of hardware -technology, -configuration, network - topology, -semantics, -protocols, logic implementation language, physical differentiation . It provides the developer with an abstraction, enabling the developer to focus on the object's interface and functionality. This enables the developer to isolate the native/technology- dependent aspects of the object.
  • the object definition language provides a syntax for inheritance, abstraction and encapsulation.
  • XDF format is the single document format of the system 10.
  • the XDF format can be used to describe any type of functionality or content. Since there is no type attribute connected to an XDF document,there is no difference between, for example, an image and an advanced e- commerce deployment service in the way that the information is structured and stored. From the user's point of view, there is no difference between a layout document and a mail Service.
  • Several XDF documents may be merged together and form a new XDF document that contains the merged documents, i.e. the new XDF document inherits content and properties from the merged documents.
  • inheritance from a single abstract or concrete definition of an object and from an unlimited number of object interfaces.
  • polymorphism of the objects is devised through interfaces and an object inheriting content or properties from several interfaces can be morphed or transformed to any of these interfaces.
  • the XDF documents contain both the data, the presentation of the data and logic. Instead of opening the XDF document in different applications, the XDF documents may carry the information on how to present the XDF documents themselves so that the XDF documents may be adapted to any suitable format before the documents are sent to the requesting user.
  • An XDF document is, preferably, constituted of objects which represent the smallest piece of functionality in the system.
  • an object may be a button, an image editor or a shopping cart.
  • An object has a clearly defined functionality.
  • an image object has, as its only purpose, to show the user an image.
  • a controller object connects interface objects with server side logic.
  • An object could be a derived object, i.e. constructed of a number of other objects, or an atomic object.
  • An atomic object is a basic building block and is essential in the adaptation process.
  • An object contains a number of properties. Some of these properties are general for all objects such as name, x-position, y- position, z-depth, width and height. Other properties are specific for the object type. In general, all services made available by the system 10 are a combination of objects.
  • an object can represent physical entities as well as software entities.
  • the physical entity can be a robot, a lamp or a dishwasher, and a software entity can be a user focused service such as a word processor or a control service in a physical device.
  • a robot object instance would represent an actual robot, for example used in a production facility. The object instance would then represent an interface to the robot and other objects can be arranged to interface with the robot object to control the associated actual physical robot device.
  • Common for physical entities that are represented by objects is that the Object Runtime Environment and the object instances representing the robots would be deployed on a central location in the production facility. Meanwhile, the actual robot would only host the native aspects of the object representing it, thus in a Native Environment.
  • the technology architecture of the invention is based on three major components, viz. the Object Runtime Environment, the Native Environment and Object Connectivity. These components are preferably implemented in software code and are in different embodiments available or located distributed in different possible configurations in different hardware nodes or are located together in a common hardware node. These components also represent three different perspectives from which any object can be viewed.
  • the platform independent part of an object is deployed and managed by the Object Runtime Environment.
  • the platform dependent or native part or parts of an object is deployed and managed by the Native Environment.
  • the connectivity of an object to external systems, such as Enterprise Information Systems or databases, is handled by the Object Connectivity component.
  • Connectors are not a part of an object but are global for the Technology Provider they are deployed on.
  • the Connectors are predefined software code portions and protocols that are devised to interface and execute data communications between an internal and an external entity.
  • An internal entity is situated within and an external entity is situated without the defined runtime and l o native environments.
  • the three components Object Runtime Environment, Native Environment and Object Connectivity form two actors in the technology architecture of the invention, viz. a provider and a consumer. These actors build and constitute technology
  • Fig 2 shows a schematic block diagram of the technology architecture, thus comprising a predefined object runtime environment 202, a predefined native environment 220 and a predefined object connectivity component 230 in its turn comprising a connector 232. These components are mutually communicatively coupled or couplable in order to
  • the primary function of the Object Runtime Environment 202 is to manage objects and to facilitate any request from the objects that are within its management. It also provides a number of predefined standard services to users and objects as well as implements a comprised security model.
  • an object 203 that is dwelling in the Object Runtime Environment 202 is symbolically depicted as a circle.
  • the object runtime environment 202 comprises in different embodiments optional configurations of the following components.
  • An object model 204 is comprised in the object runtime environment to enable instantiation and managing of object instances. All object instances instantiated within a certain Object Runtime Environment is aggregated in the object model of this Object Runtime Environment.
  • a security module 206 is comprised to define a specific security enclosure for each object dependent on a predefined object specific security level or security clearance with regard to accessability and communication.
  • all objects deployed in an Object Runtime Environment are placed in such a security enclosure that can be more or less restrictive to an object, depending on its security level or clearance. For example, the security clearance is higher if an object is certified.
  • a number of execution modules 208 are comprised in the Object Runtime Environment 202 in order to support different programming languages (e.g. Java) that require support for code execution platforms (e.g. JVM).
  • the Object Runtime Environment 202 utilizes pluggable execution modules to execute object logic, i.e. modules that are simple to add or remove by means of a common predefined connection interface.
  • Each execution module 208 defines which code execution platform it handles.
  • the Object Runtime Environment 202 then delegates the execution of object logic to the different execution modules at runtime.
  • a JavaScript execution module is comprised in all deployments of the Object Runtime Environment 202.
  • the object runtime environment 202 preferably comprises a garbage collector module 210 that is devised to support distributed garbage collection.
  • the distributed garbage collection is devised to remove an object instance that is no longer used by any other local or distributed (remote) object instance.
  • the use of or interaction of objects and/or deployments of objects with the garbage collector 210 at runtime is optional.
  • a Transaction Processing Monitor (TP Monitor) 212 is comprised for managing distributed transactions and interacts with all transaction participants. These participants can be objects as well as connectors. Distributed transactions are transactions that involve or runs on a plurality of nodes in a distributed data processing system, thus a plurality of transactional operations that all have to be successfully performed or all cancelled and rolled back. Preferably, only one monitor is engaged in a transaction, and that monitor is the one deployed in the Object Runtime Environment where the transaction was initiated. Preferably, the support of a TP monitor should be present in every Object Runtime Environment deployed.
  • a TP monitor is used indirectly by objects in the sense that the TP monitor is activated to operate in transactions involving an object without being actuated or called by the object itself.
  • a Concurrency Monitor 214 is comprised in the Object Runtime Environment 202 to monitor access to object operation methods, i.e. invocations of object operation methods, and enforces the concurrency integrity that is specified by the object in its object definition.
  • object operation methods i.e. invocations of object operation methods
  • concurrency integrity that is specified by the object in its object definition.
  • a concurrency monitor should be comprised in every Object Runtime Environment 202 deployed.
  • Fig 2 thus further shows a Native Environment 220 communicatively coupled to the Object Runtime Environment 202.
  • the Native Environment is used to deploy any native aspects of an object in a distributed data processing system, that is the native aspects of an object are those that are platform dependent.
  • a Native Environment is typically deployed in a device or any other type of leaf node in a federation according to the invention.
  • the Native Environment 220 comprises an object model 221, that should always be synchronized with the object model 204 of the Object Runtime Environment 202.
  • a native element 222 represents an object in the Native Environment 220.
  • the native element contains all the native aspects of the object it represents. It can contain attributes, object operation methods and/or presentation. In a native element, the presentation is not a composition of attributes; instead it is a native logic (i.e. software code) interacting directly with the Graphical User Interface (GUI) Application Programming Interfaces (APIs) of the device.
  • GUI Graphical User Interface
  • APIs Application Programming Interfaces
  • a native element must preferably be coherent with the object is represents. If the value of an attribute that is defined native in an object's object definition is changed in the native element, the value must be also be updated in the object that the native element represents and vice verse.
  • a native object operation method that is comprised in a native element, can be invoked by the object it represents.
  • a native object operation method can also be invoked by external actors, if it has been declared in the public scope.
  • a native object operation method can, correspondingly, invoke object operation methods in the object it represents, but invocations of object operation methods in an object from a native element are restricted only to the object, which the native element represents.
  • a Native Container 224 represents a graphical container, e.g. a window, in a Native Environment 220.
  • Native containers are optional in different embodiments because not all Native Environments will be deployed in environments where a Graphical User Interface is applicable or available.
  • the Native Environment 220 and the Object Runtime Environment 202 are in different embodiments deployed on different or on the same hardware node. In both cases the Native Environment and the Object Runtime Environment are devised such that they are capable to communicate, in order to the meet the requirement concerning coherency in data. Consumer Functionality
  • a consumer functionality is established by configuring (again referring to Fig 2) an object runtime environment 202 associated with a native environment 220. Possibly, the native environment 220 is also associated with one or more input/output interfaces (not shown), for example a drawing API or audio playback device, dependent on the specific application.
  • the consumer functionality enables objects to be autonomously deployed and instantiated at runtime and to collaborate with other, local as well as remotely situated, object instances.
  • the consumer functionality is often deployed in the leaf (outmost) nodes of a federation, and are often positioned in network devices (e.g. internet appliances) where direct bi-directional user input and output is required.
  • a consumer functionality can also comprise an object connectivity function.
  • the connectivity function is primarily used for interoperability with external data sources and systems, which however is seldom done in the outer or outmost nodes of a system.
  • the consumer functionality comprises the availability of a JavaScript Execution Module.
  • a provider functionality is established by configuring (again referring to Fig
  • the provider functionality provides all the functionality that a consumer functionality provides together additional functionality of said added components.
  • Presently preferred embodiments of the provider functionality comprise the availability of JavaScript and Java execution modules, whereas availability of additional execution modules is optional.
  • the routing component enables routing of input data, output data and calls (stimuli) within a federation. This is described in more detail below.
  • the authentication component provides authentication facilities for instances of consumer functionality that request to become a part of a federation. In presently preferred embodiments the activation of this component is optional. The responsibility for this component is primarily to authenticate a consumer establishing contact or participation in a federation, whereas the task to authenticate an actual user to the system is handled at another level.
  • the provisioning component enables provisioning of objects to consumers. It manages object inheritance as well as device profiling, thus relieving the consumer functionality from those, rather processing and I/O intensive tasks.
  • the provisioning component can be devised to provisioning objects over HTTP.
  • a federation in accordance with the invention comprises a provider functionality (also called provider) and one or more instances of consumer functionality (also called consumers).
  • the provider functionality serves as a central hub in a federation and consumers are nodes.
  • all the consumers are devised to have a direct communication channel with the provider functionality.
  • Consumers can also have a certain level of awareness of or information about each other and can optionally even have direct communication channels between them. Between consumers where direct communication channels exist communication is performed using the communication channels. If direct communication channels does not exist, the provider is used to route communication between consumers.
  • objects can seamlessly collaborate and interact.
  • the stimuli in the shape of calls can normally be communicated in two different ways. If a direct communication channel exists between the two consumers, the action stimuli and, if applicable, re-action stimuli are sent using that direct communication channel. If no such direct channel exist, the action stimuli and the re- action stimuli is routed by the provider. When routing, the provider utilizes its direct communication channel with each of the two involved consumers to send and receive the stimuli.
  • Fig 3 shows a scenario of a user requesting an object for utilizing an image editing service.
  • a user 302 signals by means of a signal (1 :request Image Editing Service Object) to a consumer functionality 304 (corresponding to a client in a client/server- architecture) that it wishes to use an image editing service accessed through a dedicated object.
  • the consumer functionality 304 comprises a native environment 306 and an object runtime environment 308.
  • the object runtime environment 308 has a device or technology profile that is dependent on the currently active user, for example specifying a user access device such as a mobile WAP browser or an stationary computer web browser.
  • the object runtime environment 308 of the consumer 304 (i.e. the client) then sends a request for the image editing service (2: request Image Editing Service with device profile) to the provider functionality 310.
  • the provider 310 (corresponding to a server in a client/server-architecture) then profiles or adapts the requested object for the device or technology profile specified by the consumer object runtime environment 304 (3: profile object for specified device). Thereafter, the provider 310 returns or provisions (4: return/provision object) the requested and by now profiled object to the object runtime environment 308.
  • the object is instantiated (5: instantiate object), i.e. an object instance is created.
  • the object contains any native aspects, these are propagated to the native environment 306 of the 5 consumer 304 (6: propagate native aspects) and a return signal (7: return) is sent back to the object runtime environment 308 as a confirmation. Thereafter, the thus profiled image editing service is made available to the user 302.
  • FIG 4 shows a scenario of a user invoking a local object operation method.
  • a user 402 operates on an image by means of a user interface, for example acordal user o interface (GUI) that in this example is assumed to comprise a native aspect in the shape of a field representing a control button for activating a service for sharpening the image.
  • GUI a conversational user o interface
  • the user 402 clicks on the sharpen image button and thereby sends a signal (1 : click on location x,y in GUI).
  • the user interface is normally a part of the native environment and therefore the user click event is handled by the consumer native environment 404.
  • the consumer 5 native environment 404 resolves on which native aspect in the GUI the user has clicked (2:resolved click to be on sharpen image button).
  • the native environment 404 then sends an on-click event signal (3: send onclick event) to a sharpen image button native aspect 406.
  • the sharpen image button native aspect 406 then 0 invokes an object operation method in the object it is associated to by means of a signal (4: invoke on-action operation method in object logic) to the consumer object runtime environment 408.
  • the object operation method is dispatched by the object runtime environment 408 (5:resolve implementation for on-action operation method in button object), which resolves the adequate method implementation for the on-action object 5 operation method (6:resolve implementation language).
  • the object runtime environment 408 activates (7:execute object logic for on-action object method) an execution module 410 to execute (8:execute) in a sharpen image button object 411 the object logic for the object operation method implementation dependent on the operation method implementation language (e.g. Java or Javascript) and returns (9:return).
  • the execution model returns (10:return) also the object runtime environment returns (11 :return) and the sharpen image button native aspect 406 becomes active again.
  • the button native aspect has accomplished 5 everything that it was designed to do and a current execution session in the button native aspect 406 terminates in a return (12:return) to the native environment 404.
  • the aspect itself remains in an existing waiting state in order to respond to possible sequential events from the native environment 404.
  • Fig 5 shows a scenario of a consumer invoking a remote object operation
  • a consumer object runtime environment 502 (1 :) resolves the implementation for an on-action object operation method in the button object and (2:) resolves the implementation language.
  • (3:) object logic for on-action object operation method is executed by means of an execution module 15 504 that (4: execute) invokes execution of a sharpen image button logic 506.
  • the button object logic 506 When the button object logic 506 is executed it interfaces a sharpen filter object reference 508, which is a reference to a remotely available / distributed sharpen filter object 512 that performs the actual sharpening of the manipulated image.
  • the sharpen filter object 512 is deployed and is dwelling on a second, remotely situated object runtime environment 510 that in this
  • the button object logic 506 invokes the apply filter operation method (5: invoke applyFilter method) on the sharpen filter object reference 508, the latter communicates via the consumer object runtime environment 502 (6: invoke remote operation method apply filter) with the object 512 that it references to.
  • the consumer object runtime 25 environment 502 sends an (7: invoke method request) invoke object operation method request to the remote provider object runtime environment 510.
  • a local object operation invokation procedure as described in the scenario of Fig 4 takes place within the remote provider object runtime environment 510. That is, the remote provider object runtime environment 510 (8: invoke local object method) invokes a local object operation method, whereupon (9: execute object logic) execution of object logic in the sharpen filter object 512 takes place.
  • the local object operation method returns (10: return) to the remote provider object runtime environment 510
  • the latter sends (11: invoke method response) an invoke object operation method response to the consumer object runtime environment 502.
  • the consumer object runtime environment 502 (12: return) returns to the object reference 508, which returns (13: return) to the button object logic 506, and the returns goes on from the object logic 506 (14: return) to the execution module 504 and back (15: return) to the consumer object runtime environment 502.
  • some of the calls and signal communications would involve a number of arguments or parameters, but for the sake of simplicity in explanation this is not shown in the figures.
  • FIG. 1 One embodiment of the invention is shown in Fig. 1, and comprises an operating system 10 designed in accordance with the present invention.
  • This operating system 10 is a network based, such as an Internet based, platform that enables a user 11 to gain access to a wide range of services.
  • the user 11 may log into a web site and use the powerful resources of a content distribution and an object connecvtivity component in the shape of a synchronization server 12 and other functionalities connected to the system 10.
  • the user 11 may purchase, subscribe or lease services as they are required.
  • the user 11 may conveniently gain access to the same information whether the user operates from a conventional computer, a WAP device, a mobile phone or any other communication device that is connectable to the system 10 via the Internet without the need for any cumbersome conversion or synchronization routines.
  • the system 10 has a provider object runtime environment in the shape of a behave server 14, a provider provision extension in the shape of a service delivery server 16 and a file delivery server 18 that may communicate with the user 11.
  • the behave server 14 may directly be used by external actors to interact with services and to perform certain behave scripts such as data manipulation or execution of logic.
  • the service delivery server 16 acts upon external requests for services, loads the service, adapts it and then delivers it to the external user 11 who requested it.
  • the file delivery server 18 acts upon external requests for a certain file, loads the file, adapts it and then delivers it to the requesting user 11.
  • the user 11 may request access to a service, such as a word processing service or any other functionality or service made available by the system, by sending a request service signal 36, i.e. a request object signal, to the service delivery system 16.
  • the behave server 14 may be used when the user 11 needs to manipulate the information, such as documents, delivered by the service delivery system 16 and file delivery system 18, as described in detail below.
  • the user may send the request service signal 36 to the system 16 that receives the signal 36 and sends a session lookup signal 38 to a session server 40 to determine if there is a pre-existing session associated with the user's request. If there is a session stored in the session server 40, the server 40 sends back a deliver session signal 42 to the system 16 that in turn sends a deliver service signal 44, including the requested service, back to the user 11. If there is no session in the session server 40 then a new session may be set up.
  • the user 11 may start working with a document by using one type of communication device, such as a desktop computer, and then continue working with the same document using a different type of communication device such as a PDA or WAP phone.
  • the system 10 automatically takes care of any required adaptation of the format for the user to gain access to a service.
  • the user 11 may also request access to a previously stored file, such as a JPEG picture, sound clip or video file, by sending a request signal 22 to the system 18.
  • a new file may be created by a service using a behave script using logic executed by the SPU.
  • the file delivery system 18 Upon receipt of the signal 22, the file delivery system 18 sends a load and adapt file signal 24 to a file adaptation unit 26.
  • the unit 26 receives the signal 24 and sends a load signal 28 to the server 12.
  • the server 12 receives the signal 28 and finds the requested file and sends back a deliver file signal 30 including the requested file information to the unit 26.
  • a single document format (XDF or ODL) is used to describe any type of functionality or content.
  • the user 11 may just open any document or start with an empty document.
  • New documents may be named at the time of creation and saved continuously and automatically.
  • the unit 26 receives the signal 30 and converts the file information to a format, such as JPEG, WBMP etc., that is suitable for the communication device used by the user 11. For example, if the user 11 is using a PDA when communicating with the system 18 then the unit 26 sends back a deliver adapted file signal 32 in a format that is suitable for the PDA. If the user is using a conventional computer, the signal 32 is in a format that is suitable for the computer and so on. In this way, the format is always adapted to the communication device the user 11 is using when communicating with the delivery system 18. The delivery system 18 receives the signal 32 and forwards the information in a deliver file signal 34 back to the user 11.
  • a format such as JPEG, WBMP etc.
  • the user 11 may also request a service by sending a request service signal 36 to the service delivery system 16.
  • a Service must be requested before files are requested.
  • a user 11 may always request a service before the file delivery system 18 and the behave server 14 are used.
  • the service may provide access to a word processing service or any other type of service such as picture or video related services.
  • the user 11 may gain access to the requested word processing service without having a word processing program installed on the communication device that is used by the user 11 to communicate with the system 16.
  • the behave server 14 may be used when the retrieved services or documents require manipulation.
  • the user 11 may broadcast an object operation method invokation in the shape of a behave event signal 46 to the behave server 14 to inform the server 14 about the required event that the picture should be made sharper.
  • the server 14 sends a session lookup signal 48 to the session server 40 to find out if there is a previously stored session in the session server 40 and to identify the user 11.
  • the system 18 also sends a session lookup signal 49 to the session server 40 when a file is requested, as described above. The system 18 then receives a deliver session 51 in response to the signal 49.
  • the server 40 sends back a deliver session signal 50 to the server 14 that receives the signal 50 and the server 14 sends a signal for executing an object operation method implementation in the shape of a execute behave script signal 52 to a behave runtime device 54, the latter being an objcet runtime environment core.
  • the signal 52 may include object operation implementation logic, i.e. software code, in the shape of the script commands that are required to accomplish the requested event.
  • the signal 52 may be in the XDF format or any other suitable format.
  • the device 54 receives the signal 52 for the event of the behave script, i.e. the object operation method invokation, such as making a picture sharper, and obtains the required logic in the shape of a script.
  • the device 54 then reads or interprets the script that constitutes the object operation method implementation and may, depending upon the type of event, execute logic or manipulate binding data. The latter is in principle mutation of attributes in an object by the object itself indirectly through the object runtime environment.
  • the device 54 receives the signal 52 and loads the script, i.e. implementation logic for the object operations method related to the sharpness of the picture from a service runtime device 56 by sending a load behave script signal 58 thereto.
  • the signal 58 is always sent to the device 56 to obtain the required script.
  • the device 56 receives the signal 58 and sends a prepare service signal 68 to a XDF runtime device 70, which is an object model that is a part of the object runtime environment.
  • the device 56 may also receive an invoke service signal 82 from the service delivery system 16.
  • the device 70 receives the signal 68 and sends a load service resources signal 72 to the server 12.
  • the server 12 responds by sending back a deliver resources signal 74, including the requested resources, to the XDF runtime device 70.
  • the device 70 may load one XDF document from the device 12 and then propagate data in the document to the current session binding pool.
  • the device 56 may be designed to handle the request and response administration for the device 70. More particularly, the device 70 may then send a deliver service signal 76 to the service runtime device 56. The device receives the signal 76 and sends a deliver behave script signal 60 back to the device 54.
  • the device 56 may send back an adapt service signal 84 to the service adaptation device 43, which is a part of the provision extension to the provider, that may forward the information in a deliver adapted service signal 86 to the service delivery system 16.
  • the device 43 may send a load bindings signal 41 to the service adaptation unit 43 that sends back a deliver bindings signal 45 including the required bindings.
  • the device 54 determines the next steps which may include sending an execute logic signal 62 to a service processing unit 64, i.e. an execution module, or a manipulate bindings signal 66 to the session server 40.
  • a service processing unit 64 i.e. an execution module
  • a manipulate bindings signal 66 to the session server 40.
  • the first time a service is loaded one or more behave scripts may be executed even before the service has reached the requesting user 11. For example, if a credit card transaction service is to be delivered, it may be necessary to prepare the request by executing logic when the request is sent to the credit card company but before the service is delivered to the client.
  • the device 54 sends the execute logic signal 62 to the device 64.
  • the unit 64 receives the signal 62 and sends a load logic and content signal 78 to the server 12. It should be noted that the device 64 may communicate with some external systems without using the device 12.
  • the server may send a transaction signal 88 to an external content adaptation unit 90 that communicates with an external actor 92, such as a database.
  • the server 12 responds to the unit 64 by delivering a transaction state by using the deliver signal 80.
  • the unit 64 When the unit 64 receives the signal 80, it sends a deliver resources signal 94 to the device 54 that, in turn, sends a deliver resource signal 96 to the behave server 14. The server 14 then sends a deliver response signal 98 back to the user 11. In this way, the unit 64 carries out at least two steps including uploading logic, for making a picture sharper, and loading the picture itself from a cache location.
  • the behave runtime device 54 may send the manipulate bindings signal 66 to the server 40.
  • the signal 66 may manipulate stored bindings in the session server 40 to make the picture sharper so that future service requests will operate with the manipulated sharper picture.
  • the signal 66 is related to a binding pool that is created whenever a new session is created in the session server 40.
  • the binding pool includes all the data that is required to describe all the variables that are active depending upon the services that are currently loaded.
  • the binding pool may, for example, include the width, height and location of the picture.
  • the signal 66 may include instructions to make a text segment bold by manipulating the bindings, such as adding tags for bold text, that are related to the text segment.
  • the signal 66 does not involve any logic and requests less complicated changes of the picture compared to changes that require the execution of logic in the device 64. It should be noted that the information to actually make the actual display of the picture sharper for the user 11 is sent via the behave server 14 and the deliver response signals 96 and 98.
  • the system 10 may import information from a large number of databases and assemble and present the information in one document because all the external information 5 is adapted to the XDF format by the external content adaptation unit 90, which is an object connectivity component, before it is stored in the server 12.
  • the system 10 may import hundreds of databases for film reviews in many formats and merge all the database information into one database in one format that includes the film reviews from all the external databases.
  • imported databases must be kept separate ⁇ o within the system.
  • the user may gain access to very powerful services, functionalities and resources provided at the server although the communication device itself is relatively primitive because it is not necessary for the communication device to have any powerful programs installed. It is sufficient for the user to gain access to the resources of the system
  • More than one user may edit the same document simultaneously provided they work on different parts of the same document.
  • each behave server 14, service delivery system 16 and file delivery system 18 has a core module that may include the service runtime device, the behave runtime device, the XDF runtime device and the service processing unit.

Abstract

A method, system and computer program for processing data objects in a distributed data processing system, said distributed data processing system having a plurality of software and/or hardware nodes being communicatively connectable. The method comprises the steps of defining first and second environments for processing objects at differ levels of abstraction, namely a first platform independen level and a second platform dependent level operating with different categories of object aspects. Each object is defined according to two object models, one for the platform independent environment and one for the platform dependent environment. The two object models are syncronized and object instances generated on the basis of said models are processed in the respective environments dependent on the aspects of the current object instance.

Description

TECHNOLOGY INDEPENDENT INFORMATION MANAGEMENT
Technical Field
The present invention relates generally to management and access of information. More specifically, the present invention relates to technology or platform independent management and access of information, computer implemented services and computerized functionality.
Background As a consequence of the continuous development of computers and the increasing use of computers in a wide variety of applications, different branches of human activities such as telecommunications, business or work related tasks and entertainment are merging into a common mainstream of information technology. Whereas the concepts for the handling of information, services and computerized tools has come far ahead, the practical use of information technology is often hampered by the wide variety of different technical solutions and platforms for storing, displaying, executing and transferring information or data. There is thus a need for simpler access and handling of the different kinds and realizations of information technology.
Prior Art
There is prior art addressing the mentioned need. In for example the technical report Current Technologies for Device Independence, MarkH. Butler, Publishing Systems and Solutions Laboratory, HP Laboratories Bristol, HPL-2001-83, April 4th, 2001 there is a survey of current technologies related to the creation of device independent web content and web applications. This piece of prior art is mainly concerned with the access to internet web sites by means of different kinds of devises.
The patent documents EP1126681 and EP1130510 show different aspects of prior art object oriented technology. Object of the Invention
The overall object of the present invention is to solve the problem of achieving a technological platform where objects for example in the shape of information, executable software code or apparatuses with possibly heterogeneous properties can interact 5 and collaborate in manner that is perceived to be homogeneous.
Different aspects of the problem are:
- To enable availability and accessability of information as well as logic in the form of processing rules or executable program code for different types of processing and interfacing software or hardware devices independent of their basic technology or 0 platform.
To enable collaboration between different logic components, i.e. pieces of executable software code, independent of hardware configuration, network topology, program language semantics, transaction protocols, logic implementation language, physical differentiation and the like. 5 - To enable a more economic software development in terms of possibility to optimize the size of software modules. To provide a seamless transition between software objects and software components.
- To provide homogenous access to external resources, such as data sources, executable software code or hardware devices. o - To provide an environment for rapidly creating powerful, truly distributed systems in a manner that is simple and time efficient as well as production cost efficient.
- To enable implementation of objects, in the sense of object oriented programming technology, in one or more programming languages in order to allow for selectability of language dependent on the current purpose or task. 5
Summary of the Invention
The above mentioned object and the different problem aspects are in accordance with the invention addressed by means of an improved object oriented concept thinking realized in a distributed object oriented architecture (in short herein also called object architecture). The inventive distributed object oriented architecture comprises an object definition language, which is a subset of the extensible Markup Language. The Object Definition Language enables object developers to define objects, independent of hardware -technology, -configuration, network -topology, -semantics, -protocols, logic implementation language and physical differentiation. It provides the developer with an abstraction, enabling the developer to focus on the object's interface and functionality. This enables the developer to isolate the native/technology-dependent aspects of the object.
More generally, the objects of the invention is achieved by means of the below method for processing data objects in a distributed data processing system, and realizations in the form of a system or a computer program product. The distributed data processing system has a plurality of software and/or hardware nodes that are mutually communicatively connectable or couplable.
An embodiments of the method comprises the steps of: defining a first environment, called object runtime environment, for processing objects at a first level of abstraction that is independent of the software/hardware platform of said nodes; defining a second environment, called native environment, for processing objects at a second level of abstraction that is dependent on the software/hardware platform of said nodes; defining in said first environment a first object model with a first category of object aspects, i.e. generic or platform independent aspects; defining in said second environment a second object model with a second category of object aspects, i.e. native or platform dependent aspects; synchronizing said first object model of said first environment with said second object model of said second environment; defining an object in accordance with said first and second models associating a selectable set of object aspects from said first and second object aspect categories; generating an instance of said object; processing said object instance in said first and second environments dependent on said associated set of object aspects. 5 In a data processing system comprising hardware and software nodes in which the inventive environments are established objects are thus managed and processed in a manner that fulfills the objects of the present invention.
In a further development of the invention, predefined object connectivity means, in the shape of software code portions and protocols communicatively coupled to o said first, platform independent environment, are devised to interface with and execute data communications between an internal entity situated within and an external entity situated without said defined first and second environments.
In one embodiment, an instance of said first, platform independent environment is configured together with an instance of said second, platform dependent 5 environment and object connectivity means to constitute a service provider functionality. Preferably also an instance of said first, platform independent environment is configured together with an instance of said second, platform dependent environment to constitute an object consumer functionality.
Further, a object provider functionality is preferably configured together with o and a service consumer functionality constituting a consumer/provider subset of the distributed system, also called a federation (explained below) within which the processing of objects or object instances is performed.
Seamless transition between software objects and software components is achieved by providing a common development model for objects and for software 5 components.
According to the invention information is preferably stored in a common format, heresometimes called the extensible Document Format (below also referred to as XDF format) which is the single document format of the system. The XDF format is used to describe any type of functionality or content. There is no type attribute connected to an XDF document, and therefore there is no difference between a data file, such as a document or an image, and an application of executable program code, in the way the information is structured and stored. From the user's point of view, there is no difference between for 5 example a document and a data communications service.
A result and an important feature of the present invention is that a user that operates and interfaces with a data processing system or a data base designed in accordance with the inventive concept may conveniently gain access to the same information with any connectable data communication device independent of its technical platform. That is, the 0 information is accessible whether the user operates from for example a conventional computer, a WAP device, a mobile phone or any other communication device that is connectable to the system via the for example the Internet without the need for any cumbersome conversion or synchronization routines.
The system in accordance with the invention automatically performs any 5 required adaptation or profiling of the format of data for the user to gain access to an object e.g. in the shape of information or a service, such as the processing of data in a user-centric service. Thereby objects according to the invention are made platform independent. A user may thus start working with an object such as a document by means of a service, such as a word processor, by using one type of communication device or processing device, e.g. a o desktop computer. Then the user can continue working with the same document using a different type of communication or processing device such as a PDA or WAP phone.
The invention makes it possible to make available upon request different services, for example a word processing service provided at remote site or apparatus, e.g. a central site or another node in a distributed system. A user may thus gain access to the 5 requested word processing service without having a word processing program installed on the communication device that is used by the user to communicate with the system. More generally, a user may gain access to very powerful services, functionalities and resources provided at a remote site or apparatus, e.g. a central site or another node in a distributed system, although the communication device itself is relatively primitive because it is not necessary for the communication device to have any powerful programs installed.
In order to enable a more economic software development in terms of possibility to optimize the size of software modules, the inventive concept comprises functionality to treat objects and components alike. That is, the inventive object architecture does not make any semantic or programmatic difference between an object and a component. When an object becomes more complex, the complexity is delegated for example by means of compositions or aggregations. Objects that delegate functionality then seamlessly transfer to behave like or perhaps even be an entity that in prior art often is referred to as a component. In the invention an object can therefore be developed and treated either as a software component or an object, but the inventive object architecture makes no difference between the two and therefore a program developer is freed to develop a program solution that is neither larger nor smaller than necessary.
Definitions
In this section terms used in the description text are defined and explained. Some terms are also defined and explained in description text itself.
Object An entity that encapsulates information, processes and behaviors as specified by the accepted principles of Object Orientation. The word is in this text used to define an object built and based on the technology according to the invention, which in some respects differs from prior art definitions. Also the word object is used to identify a non-instantiated object.
Instance or object instance An instantiated object.
External actor From the point of view of a current first object, a second object interacting with the first object is an external actor.
ODL Abbreviation of Object Definition
Language.
The Object Definition Language is used within the technology according to the present invention to define objects and in this text refers to a specifically developed language. Federation A system according to the invention in which a
Provider functionality and a Consumer functionality (explained below) are available. Deployed object When an object is instantiated within an Object
5 Runtime Environment (explained below) for the first time, some additional steps are required; decoding object definition, merging object definitions, decoding runtime descriptor, cache object definition etc. These additional steps are referred to as deploying an object, object deployment or a deployed object throughout this description. In contrast with prior definition of deployment, here deployment refers to a process that is performed o autonomously and not by a system administrator or a developer.
Brief Description of the Drawings
Fig. 1 is a schematic collaboration diagram of the operating system of the present invention; 5 Fig 2 is a schematic block diagram of illustrating components in embodiments of the invention; and
Fig 3-5 show exemplifying scenarios of signal communication between different components in embodiments of the invention.
0 Detailed Description of Embodiments of the Invention
The invention is dependent on the application realized as a method, an apparatus or system, or as a computer program product. An apparatus or system would typically comprise data processing means having a central processing unit (CPU), data storage means, an input/output interface and data communication means. The apparatus or 5 system would then be set up to execute steps of the inventive method by means of specifically designed computer program code. The invention, when realized as a computer program product, would typically comprise computer program code portions that are devised to direct a data processing system to perform steps and functionality of the inventive method or apparatus. The invention is explained with reference to schematic drawings that depict functional units that in different embodiments may be realized as method steps, hardware units or computer program code portions. For the sake of simplicity the distinction between different realizations is not always mentioned in the below description of embodiments. The invention is preferably implemented in terms of an object oriented concept. Objects are created, that is defined and established, exist and operate in an object runtime environment constituted by a possibly distributed system of data processing devices provided with software for realizing a platform independent data processing method in accordance with the invention. Possibly, a plurality of different object runtime environments exists side by side, and may also communicate. There is also a platform dependent layer or environment called native environment in each of the devises in the system. Objects can also exist in the native environment and it is proper to define different aspects of an object, namely the generic, platform independent aspect and the native, platform dependent aspect. If an object contains one or more native aspects, the object is also defined native as such. Objects that are defined native have two object models, namely one in the Object Runtime Environment and one in the Native Environment. The model existing in the Native Environment is populated with all native aspects of the object. Both object models can interact with each other. For example, native methods can invoke non-native methods within the same object and vice versa (with the extension that objects can invoke native methods in other objects also). Also, any attributes defined native are always kept coherent in the two object models. For example, if the attribute value is changed in one object model, the change is propagated to the other object model.
Preferably, the majority of all objects that are created should be totally platform independent. Only a small number of objects will contain any native representations. Such objects (e.g. Image object, Text object, AudioPlayback object etc.) implement functionality that is futile to support as platform independent, without a devastating amount of development and administrative implementation work. Instead these native objects, i.e. objects containing native aspects, will be the most atomic building blocks for other objects to use.
An effect of the platform independent generic aspect of objects in accordance with the invention is that each object only has to be defined once, and can thereafter be delivered to all different types of devices for which there an object consumer runtime environment (further explained below).
Defining Objects
This section describes preferred embodiments of the object structure of the invention. Uniqueness:
In operation a number of objects are defined and established as object instances. All object instances are globally unique within the distributed system of nodes and devises that are involved in an implementation of the invention. When an object is instantiated, it is given a globally unique identification number (GUID/UUID). In accordance with the invention a globally unique identification number GUID must be guaranteed uniqueness on all involved software devices within the implementation. The effect of this is that the objects of the invention are or can be truly and entirely distributed in the sense that they can exist on an arbitrary number of clients and communicate with an arbitrary number of servers.
Attributes:
Information (data) is encapsulated in an object by means of attributes associated with the object. An attribute can hold or store basic entities called primitives, more specifically a primitive, a runtime primitive, a custom primitive, or it can hold a reference to another object. An attribute can be declared native, which means that it operates in an environment, called native environment, that is dependent on a specific technical platform at a level below the platform independent level. This is further explained below. In one embodiment of the invention, an attribute is unable to be exposed directly to other objects, instead attributes must be accessed through accessor and mutator methods defined in the invention.
Primitives:
Data of different kinds is accessed or stored through a set of primitives that is used to contain data. Data can also be stored in other objects or object instances that a first object has a reference to, in which case the reference is stored as an attribute. For example, a mail object can have a reference to a recipient object. The storage of more complex data can be realized as a mixture of primitives and objects, and example a mail object can have a collection of attachment objects. Different embodiments comprise one or more among the following primitives. It is also possible to define other primitives within the inventive concept.
Number A primitive that can contain any type of numerical value, for example integer, decimal (floating point) or big decimal. The type is determined by the value inputted by the developer of the implementation. String A string primitive contains a universal character set transformation format UTF. There are for example an UTF-8 or an UTF-16 string value.
Boolean A boolean primitive contains a boolean value, for example expressed as a single bit dependent on the implementation.
Collection A collection primitive is able to contain primitives (including collection primitives), runtime primitives, custom primitives and object references. In a preferred embodiment of the invention the data contained in the collection primitive should be contained in a structure independent way. The collection can then be treated as any type of collection, such as map, vector, array, list, linked list or the like.
Transaction A transaction resource contains a reference to a globally unique transaction that has been performed or executed.
Runtime primitives:
Runtime primitives are primitives that are local for the Object Runtime Environment in which they were created and populated. Runtime primitives are transient by nature, and they are not allowed to be serialized and/or distributed to another Object Runtime Environment. When an object is serialized it is stored in a format that can be transmitted over a network or it is stored on a persistent medium, such as a hard disk. In an alternative wording the complex format of an object is stored for example as a binary stream or as an XML-document. In contrast to serialization, when an object is transferred as binary data, an object is distributed by sending an object reference to certain recipients.
Embodiments of the invention comprises: Container A native container is a runtime primitive that represents a graphical user interface container (e.g. a window) that is used to project presentation objects. Custom primitives:
Custom primitives are custom defined primitives, defined by an object vendor or an object developer. An example usage of custom primitives is a primitive pertaining to a Java Technology Object. A custom primitive is by default not transient, but may be declared transient by the object vendor. Object References:
An attribute can contain a reference to an instance of another object. Such a reference is used to invoke methods that operate on the current object instance.
Object operation methods
An object is accessed or activated by means of an object operation method, which is a portion of executable software code designed to perform a specific task of the object. In a preferred embodiment of the invention, the object operation methods is the only part of the object that is directly exposed to other objects and is available in order on one hand to execute functionality or operations and on the other hand to access or manipulate data that is encapsulated in the object. Each object operation method has a definition that defines its name and its return value. For each object operation method an unlimited number of unique method implementations can be declared. The uniqueness of an object operation method implementation, or an object operation method signature, is based on the number of arguments, argument names, and argument types it requires. In one embodiment, in the case that two implementations have the same number of arguments, they are differentiated by the argument names; and if the number of arguments and the argument names are identical they are differentiated by the argument value types. An object operation method can be implemented in any programming language that is supported by the current embodiment.
An object operation method can be invoked synchronously or asynchronously. When invoked synchronously, the execution will block until the method invocation is complete, optionally resulting in a return value. If invoked asynchronously, the execution will not block. Instead, the external actor specifies an object instance that will be interfaced by the Object Runtime Environment when the method invocation is complete, attaching any return value as an argument. Also, an external actor such as a user, device or another object can specify a specific object instance to be used to monitor or observe the invocation of the object operation method. As mentioned above, an object that is defined as native have two object models, i.e. one in the runtime environment and one in the native environment. Both object models can interact with each other. For example, native methods can invoke non-native object operation methods within the same object and vice versa. Furthermore, objects can invoke native object operating methods in other objects too. Also, any attributes defined as native are always kept coherent in the two object models. For example, if the attribute value is changed in one object model, the change is propagated to the other object model.
Aspects of objects
An object exists in different aspects, in one embodiment comprising the following five aspects.
Object Definition: An object is defined by its Object Definition. It defines the object's attributes, methods, presentation, inheritance, concurrency, transaction isolation etc. Object Blueprint: An object blueprint defines an interface of an object, or blueprint, that is exposed to external actors. The blueprint is created automatically from the Object Definition.
Object Deployment Descriptor: An object deployment descriptor declares the usage and the level of usage of Object Runtime and Native Environment built-in services such as 5 transactions, concurrency, garbage collection, secure communication, etc. Two Deployment Descriptors can exist for any object; one that is a part of the object and one that can be supplied by other functionalities of the system.
Object Instance: When an object is instantiated or an object reference is de-serialized, i.e. when an object represented with binary data or XML is transformed to its proper format, 0 an object instance is created. An object instance can exist in two different modes, viz. active or inactive. An active instance is an object instance currently deployed in an Object Runtime Environment and its inactive counterpart is an object instance currently serialized. An active instance is always local for an Object Runtime Environment and is unable to be directly accessed or interfaced by an external actor. An object instance is always interfaced using an 5 object reference.
Object Reference: External actors never interact with an object instance directly. Instead there is always an object reference that references the object instance. So for example: If an object instance A (that is located in Object Runtime Environment A) wishes to interact with an object instance B (that is located in Object Runtime Environment B), the object instance o A must first acquire a reference to instance B. The acquired object reference is then located in Object Runtime Environment A, whilst the actual object instance is located in Object Runtime Environment B.
Objects in the Form of ODL Documents 5 Objects are preferably defined in the Object Definition Language, which is a subset of the extensible Markup Language. The Object Definition Language enables object developers to define objects, independent of hardware -technology, -configuration, network - topology, -semantics, -protocols, logic implementation language, physical differentiation . It provides the developer with an abstraction, enabling the developer to focus on the object's interface and functionality. This enables the developer to isolate the native/technology- dependent aspects of the object. The object definition language provides a syntax for inheritance, abstraction and encapsulation.
Objects in the Form of XDF Documents
An important feature of the present invention is that all information is preferably stored in the extensible Document Format (below referred to as XDF format) which is the single document format of the system 10. The XDF format can be used to describe any type of functionality or content. Since there is no type attribute connected to an XDF document,there is no difference between, for example, an image and an advanced e- commerce deployment service in the way that the information is structured and stored. From the user's point of view, there is no difference between a layout document and a mail Service. Several XDF documents may be merged together and form a new XDF document that contains the merged documents, i.e. the new XDF document inherits content and properties from the merged documents. In the architecture according to the invention there is devised inheritance from a single abstract or concrete definition of an object and from an unlimited number of object interfaces. In the invention polymorphism of the objects is devised through interfaces and an object inheriting content or properties from several interfaces can be morphed or transformed to any of these interfaces.
The XDF documents contain both the data, the presentation of the data and logic. Instead of opening the XDF document in different applications, the XDF documents may carry the information on how to present the XDF documents themselves so that the XDF documents may be adapted to any suitable format before the documents are sent to the requesting user.
An XDF document is, preferably, constituted of objects which represent the smallest piece of functionality in the system. For example, an object may be a button, an image editor or a shopping cart. An object has a clearly defined functionality. For example, an image object has, as its only purpose, to show the user an image. A controller object connects interface objects with server side logic. An object could be a derived object, i.e. constructed of a number of other objects, or an atomic object. An atomic object is a basic building block and is essential in the adaptation process. An object contains a number of properties. Some of these properties are general for all objects such as name, x-position, y- position, z-depth, width and height. Other properties are specific for the object type. In general, all services made available by the system 10 are a combination of objects.
Physical Objects According to embodiments of the invention an object can represent physical entities as well as software entities. For example, the physical entity can be a robot, a lamp or a dishwasher, and a software entity can be a user focused service such as a word processor or a control service in a physical device. In the case of a robot, a robot object instance would represent an actual robot, for example used in a production facility. The object instance would then represent an interface to the robot and other objects can be arranged to interface with the robot object to control the associated actual physical robot device. Common for physical entities that are represented by objects, is that the Object Runtime Environment and the object instances representing the robots would be deployed on a central location in the production facility. Meanwhile, the actual robot would only host the native aspects of the object representing it, thus in a Native Environment.
Platform overview - Embodiment of Architecture
The technology architecture of the invention is based on three major components, viz. the Object Runtime Environment, the Native Environment and Object Connectivity. These components are preferably implemented in software code and are in different embodiments available or located distributed in different possible configurations in different hardware nodes or are located together in a common hardware node. These components also represent three different perspectives from which any object can be viewed. The platform independent part of an object is deployed and managed by the Object Runtime Environment. The platform dependent or native part or parts of an object is deployed and managed by the Native Environment. The connectivity of an object to external systems, such as Enterprise Information Systems or databases, is handled by the Object Connectivity component. Inside 5 the Object Connectivity component, this connectivity is handled by Connectors, which are not a part of an object but are global for the Technology Provider they are deployed on. The Connectors are predefined software code portions and protocols that are devised to interface and execute data communications between an internal and an external entity. An internal entity is situated within and an external entity is situated without the defined runtime and l o native environments.
When combined together in different constellations and when certain extensions, such as routing are made, the three components Object Runtime Environment, Native Environment and Object Connectivity form two actors in the technology architecture of the invention, viz. a provider and a consumer. These actors build and constitute technology
15 federations (mentioned above.
Fig 2 shows a schematic block diagram of the technology architecture, thus comprising a predefined object runtime environment 202, a predefined native environment 220 and a predefined object connectivity component 230 in its turn comprising a connector 232. These components are mutually communicatively coupled or couplable in order to
20 communicate control data or information when operating on objects.
Object Runtime Environment
The primary function of the Object Runtime Environment 202 is to manage objects and to facilitate any request from the objects that are within its management. It also provides a number of predefined standard services to users and objects as well as implements a comprised security model. In Fig 2 an object 203 that is dwelling in the Object Runtime Environment 202 is symbolically depicted as a circle. The object runtime environment 202 comprises in different embodiments optional configurations of the following components.
An object model 204 is comprised in the object runtime environment to enable instantiation and managing of object instances. All object instances instantiated within a certain Object Runtime Environment is aggregated in the object model of this Object Runtime Environment.
A security module 206 is comprised to define a specific security enclosure for each object dependent on a predefined object specific security level or security clearance with regard to accessability and communication. Thus all objects deployed in an Object Runtime Environment are placed in such a security enclosure that can be more or less restrictive to an object, depending on its security level or clearance. For example, the security clearance is higher if an object is certified.
A number of execution modules 208 are comprised in the Object Runtime Environment 202 in order to support different programming languages (e.g. Java) that require support for code execution platforms (e.g. JVM). Preferably, the Object Runtime Environment 202 utilizes pluggable execution modules to execute object logic, i.e. modules that are simple to add or remove by means of a common predefined connection interface. Each execution module 208 defines which code execution platform it handles. The Object Runtime Environment 202 then delegates the execution of object logic to the different execution modules at runtime. In presently preferred embodiments, a JavaScript execution module is comprised in all deployments of the Object Runtime Environment 202.
In order to dispose with used up data the object runtime environment 202 preferably comprises a garbage collector module 210 that is devised to support distributed garbage collection. The distributed garbage collection is devised to remove an object instance that is no longer used by any other local or distributed (remote) object instance. Preferably, the use of or interaction of objects and/or deployments of objects with the garbage collector 210 at runtime is optional.
A Transaction Processing Monitor (TP Monitor) 212 is comprised for managing distributed transactions and interacts with all transaction participants. These participants can be objects as well as connectors. Distributed transactions are transactions that involve or runs on a plurality of nodes in a distributed data processing system, thus a plurality of transactional operations that all have to be successfully performed or all cancelled and rolled back. Preferably, only one monitor is engaged in a transaction, and that monitor is the one deployed in the Object Runtime Environment where the transaction was initiated. Preferably, the support of a TP monitor should be present in every Object Runtime Environment deployed. A TP monitor is used indirectly by objects in the sense that the TP monitor is activated to operate in transactions involving an object without being actuated or called by the object itself.
A Concurrency Monitor 214 is comprised in the Object Runtime Environment 202 to monitor access to object operation methods, i.e. invocations of object operation methods, and enforces the concurrency integrity that is specified by the object in its object definition. Preferably, a concurrency monitor should be comprised in every Object Runtime Environment 202 deployed.
Native Environment
Fig 2 thus further shows a Native Environment 220 communicatively coupled to the Object Runtime Environment 202. The Native Environment is used to deploy any native aspects of an object in a distributed data processing system, that is the native aspects of an object are those that are platform dependent. A Native Environment is typically deployed in a device or any other type of leaf node in a federation according to the invention. The Native Environment 220 comprises an object model 221, that should always be synchronized with the object model 204 of the Object Runtime Environment 202. There are two types of entities comprised in and managed by the Native Environment, viz. native elements 222 and native containers 224. A native element 222 represents an object in the Native Environment 220.
The native element contains all the native aspects of the object it represents. It can contain attributes, object operation methods and/or presentation. In a native element, the presentation is not a composition of attributes; instead it is a native logic (i.e. software code) interacting directly with the Graphical User Interface (GUI) Application Programming Interfaces (APIs) of the device.
According to the invention, a native element must preferably be coherent with the object is represents. If the value of an attribute that is defined native in an object's object definition is changed in the native element, the value must be also be updated in the object that the native element represents and vice verse. Moreover, a native object operation method that is comprised in a native element, can be invoked by the object it represents. A native object operation method can also be invoked by external actors, if it has been declared in the public scope. A native object operation method can, correspondingly, invoke object operation methods in the object it represents, but invocations of object operation methods in an object from a native element are restricted only to the object, which the native element represents.
A Native Container 224 represents a graphical container, e.g. a window, in a Native Environment 220. Native containers are optional in different embodiments because not all Native Environments will be deployed in environments where a Graphical User Interface is applicable or available. The Native Environment 220 and the Object Runtime Environment 202 are in different embodiments deployed on different or on the same hardware node. In both cases the Native Environment and the Object Runtime Environment are devised such that they are capable to communicate, in order to the meet the requirement concerning coherency in data. Consumer Functionality
A consumer functionality is established by configuring (again referring to Fig 2) an object runtime environment 202 associated with a native environment 220. Possibly, the native environment 220 is also associated with one or more input/output interfaces (not shown), for example a drawing API or audio playback device, dependent on the specific application. The consumer functionality enables objects to be autonomously deployed and instantiated at runtime and to collaborate with other, local as well as remotely situated, object instances. The consumer functionality is often deployed in the leaf (outmost) nodes of a federation, and are often positioned in network devices (e.g. internet appliances) where direct bi-directional user input and output is required.
Optionally a consumer functionality can also comprise an object connectivity function. The connectivity function is primarily used for interoperability with external data sources and systems, which however is seldom done in the outer or outmost nodes of a system. In presently preferred embodiments, the consumer functionality comprises the availability of a JavaScript Execution Module. Optionally, there may also be comprised availability of an additional execution module such as the Java Execution Module.
Provider Functionality A provider functionality is established by configuring (again referring to Fig
2) all the three major components, i.e. an object runtime environment 202, a native environment 220 and an object connectivity functionality 230, and additional provider specific components. The additional provider specific components comprise optional configurations of a routing component, a security (or authentication) component and a provisioning component (not shown), that all are communicatively coupled to the object runtime environment 202. Thus, the provider functionality provides all the functionality that a consumer functionality provides together additional functionality of said added components. Presently preferred embodiments of the provider functionality comprise the availability of JavaScript and Java execution modules, whereas availability of additional execution modules is optional.
The routing component enables routing of input data, output data and calls (stimuli) within a federation. This is described in more detail below. The authentication component provides authentication facilities for instances of consumer functionality that request to become a part of a federation. In presently preferred embodiments the activation of this component is optional. The responsibility for this component is primarily to authenticate a consumer establishing contact or participation in a federation, whereas the task to authenticate an actual user to the system is handled at another level.
The provisioning component enables provisioning of objects to consumers. It manages object inheritance as well as device profiling, thus relieving the consumer functionality from those, rather processing and I/O intensive tasks. For example, the provisioning component can be devised to provisioning objects over HTTP.
Federations
A federation in accordance with the invention comprises a provider functionality (also called provider) and one or more instances of consumer functionality (also called consumers). The provider functionality serves as a central hub in a federation and consumers are nodes. In a federation all the consumers are devised to have a direct communication channel with the provider functionality. Consumers can also have a certain level of awareness of or information about each other and can optionally even have direct communication channels between them. Between consumers where direct communication channels exist communication is performed using the communication channels. If direct communication channels does not exist, the provider is used to route communication between consumers.
Within a federation, objects can seamlessly collaborate and interact. When an object that is deployed within a first consumer wants to interact with another object that is deployed within another, second consumer, the stimuli in the shape of calls can normally be communicated in two different ways. If a direct communication channel exists between the two consumers, the action stimuli and, if applicable, re-action stimuli are sent using that direct communication channel. If no such direct channel exist, the action stimuli and the re- action stimuli is routed by the provider. When routing, the provider utilizes its direct communication channel with each of the two involved consumers to send and receive the stimuli.
If an object that is deployed within a consumer wants to interact with another object that is deployed within a provider within the same federation, there is always a direct communication channel and no routing is required.
Scenarios
Exemplifying scenarios of signal patterns according to embodiments of the invention are shown in overview sequence flow diagrams in Fig 3 -Fig 5. Fig 3 shows a scenario of a user requesting an object for utilizing an image editing service. Thus a user 302 signals by means of a signal (1 :request Image Editing Service Object) to a consumer functionality 304 (corresponding to a client in a client/server- architecture) that it wishes to use an image editing service accessed through a dedicated object. The consumer functionality 304 comprises a native environment 306 and an object runtime environment 308. The object runtime environment 308 has a device or technology profile that is dependent on the currently active user, for example specifying a user access device such as a mobile WAP browser or an stationary computer web browser.
The object runtime environment 308 of the consumer 304 (i.e. the client) then sends a request for the image editing service (2: request Image Editing Service with device profile) to the provider functionality 310. The provider 310 (corresponding to a server in a client/server-architecture) then profiles or adapts the requested object for the device or technology profile specified by the consumer object runtime environment 304 (3: profile object for specified device). Thereafter, the provider 310 returns or provisions (4: return/provision object) the requested and by now profiled object to the object runtime environment 308. When the object is received by runtime environment 308 of the consumer 304, the object is instantiated (5: instantiate object), i.e. an object instance is created. If the object contains any native aspects, these are propagated to the native environment 306 of the 5 consumer 304 (6: propagate native aspects) and a return signal (7: return) is sent back to the object runtime environment 308 as a confirmation. Thereafter, the thus profiled image editing service is made available to the user 302.
Fig 4 shows a scenario of a user invoking a local object operation method. A user 402 operates on an image by means of a user interface, for example a grafical user o interface (GUI) that in this example is assumed to comprise a native aspect in the shape of a field representing a control button for activating a service for sharpening the image. First, the user 402 clicks on the sharpen image button and thereby sends a signal (1 : click on location x,y in GUI). The user interface is normally a part of the native environment and therefore the user click event is handled by the consumer native environment 404. The consumer 5 native environment 404 resolves on which native aspect in the GUI the user has clicked (2:resolved click to be on sharpen image button). In this case the click was performed on the x and y coordinates of the GUI, which is predefined to be within the sharpen image button. The native environment 404 then sends an on-click event signal (3: send onclick event) to a sharpen image button native aspect 406. The sharpen image button native aspect 406 then 0 invokes an object operation method in the object it is associated to by means of a signal (4: invoke on-action operation method in object logic) to the consumer object runtime environment 408. The object operation method is dispatched by the object runtime environment 408 (5:resolve implementation for on-action operation method in button object), which resolves the adequate method implementation for the on-action object 5 operation method (6:resolve implementation language). When the adequate object operation method implementation is found, the the object runtime environment 408 activates (7:execute object logic for on-action object method) an execution module 410 to execute (8:execute) in a sharpen image button object 411 the object logic for the object operation method implementation dependent on the operation method implementation language (e.g. Java or Javascript) and returns (9:return). When the execution model returns (10:return) also the object runtime environment returns (11 :return) and the sharpen image button native aspect 406 becomes active again. In this scenario the button native aspect has accomplished 5 everything that it was designed to do and a current execution session in the button native aspect 406 terminates in a return (12:return) to the native environment 404. The aspect itself remains in an existing waiting state in order to respond to possible sequential events from the native environment 404.
Fig 5 shows a scenario of a consumer invoking a remote object operation
1 o method and is based on the previously described scenario of Fig 4 with a user invoking a local object operation method for manipulating an image. In Fig 5 a consumer object runtime environment 502 (1 :) resolves the implementation for an on-action object operation method in the button object and (2:) resolves the implementation language. Thereafter, (3:) object logic for on-action object operation method is executed by means of an execution module 15 504 that (4: execute) invokes execution of a sharpen image button logic 506. When the button object logic 506 is executed it interfaces a sharpen filter object reference 508, which is a reference to a remotely available / distributed sharpen filter object 512 that performs the actual sharpening of the manipulated image. The sharpen filter object 512 is deployed and is dwelling on a second, remotely situated object runtime environment 510 that in this
20 configuration constitutes a provider functionality.
When the button object logic 506 invokes the apply filter operation method (5: invoke applyFilter method) on the sharpen filter object reference 508, the latter communicates via the consumer object runtime environment 502 (6: invoke remote operation method apply filter) with the object 512 that it references to. The consumer object runtime 25 environment 502 sends an (7: invoke method request) invoke object operation method request to the remote provider object runtime environment 510. Thereafter a local object operation invokation procedure as described in the scenario of Fig 4 takes place within the remote provider object runtime environment 510. That is, the remote provider object runtime environment 510 (8: invoke local object method) invokes a local object operation method, whereupon (9: execute object logic) execution of object logic in the sharpen filter object 512 takes place. When the local object operation method returns (10: return) to the remote provider object runtime environment 510, the latter sends (11: invoke method response) an invoke object operation method response to the consumer object runtime environment 502. The consumer object runtime environment 502 (12: return) returns to the object reference 508, which returns (13: return) to the button object logic 506, and the returns goes on from the object logic 506 (14: return) to the execution module 504 and back (15: return) to the consumer object runtime environment 502. In fully functional scenarios some of the calls and signal communications would involve a number of arguments or parameters, but for the sake of simplicity in explanation this is not shown in the figures.
Embodiment Realizing an Data Network Based Operating System One embodiment of the invention is shown in Fig. 1, and comprises an operating system 10 designed in accordance with the present invention. This operating system 10 is a network based, such as an Internet based, platform that enables a user 11 to gain access to a wide range of services. In general, the user 11 may log into a web site and use the powerful resources of a content distribution and an object connecvtivity component in the shape of a synchronization server 12 and other functionalities connected to the system 10. For example, the user 11 may purchase, subscribe or lease services as they are required. The user 11 may conveniently gain access to the same information whether the user operates from a conventional computer, a WAP device, a mobile phone or any other communication device that is connectable to the system 10 via the Internet without the need for any cumbersome conversion or synchronization routines.
The system 10 has a provider object runtime environment in the shape of a behave server 14, a provider provision extension in the shape of a service delivery server 16 and a file delivery server 18 that may communicate with the user 11. The behave server 14 may directly be used by external actors to interact with services and to perform certain behave scripts such as data manipulation or execution of logic. The service delivery server 16 acts upon external requests for services, loads the service, adapts it and then delivers it to the external user 11 who requested it. The file delivery server 18 acts upon external requests for a certain file, loads the file, adapts it and then delivers it to the requesting user 11. For example, the user 11 may request access to a service, such as a word processing service or any other functionality or service made available by the system, by sending a request service signal 36, i.e. a request object signal, to the service delivery system 16.
The behave server 14 may be used when the user 11 needs to manipulate the information, such as documents, delivered by the service delivery system 16 and file delivery system 18, as described in detail below.
Upon proper authentication of the user 11, the user may send the request service signal 36 to the system 16 that receives the signal 36 and sends a session lookup signal 38 to a session server 40 to determine if there is a pre-existing session associated with the user's request. If there is a session stored in the session server 40, the server 40 sends back a deliver session signal 42 to the system 16 that in turn sends a deliver service signal 44, including the requested service, back to the user 11. If there is no session in the session server 40 then a new session may be set up.
The user 11 may start working with a document by using one type of communication device, such as a desktop computer, and then continue working with the same document using a different type of communication device such as a PDA or WAP phone. The system 10 automatically takes care of any required adaptation of the format for the user to gain access to a service. The user 11 may also request access to a previously stored file, such as a JPEG picture, sound clip or video file, by sending a request signal 22 to the system 18. A new file may be created by a service using a behave script using logic executed by the SPU. Upon receipt of the signal 22, the file delivery system 18 sends a load and adapt file signal 24 to a file adaptation unit 26. The unit 26 receives the signal 24 and sends a load signal 28 to the server 12. The server 12 receives the signal 28 and finds the requested file and sends back a deliver file signal 30 including the requested file information to the unit 26. As mentioned above a single document format (XDF or ODL) is used to describe any type of functionality or content. The user 11 may just open any document or start with an empty document.
Since there is no type attribute connected to an XDF document,there is no difference between, for example, an image and an advanced e-commerce deployment service in the way that the information is structured and stored. From the user's point of view, there is no difference between a layout document and a mail Service. New documents may be named at the time of creation and saved continuously and automatically.
The unit 26 receives the signal 30 and converts the file information to a format, such as JPEG, WBMP etc., that is suitable for the communication device used by the user 11. For example, if the user 11 is using a PDA when communicating with the system 18 then the unit 26 sends back a deliver adapted file signal 32 in a format that is suitable for the PDA. If the user is using a conventional computer, the signal 32 is in a format that is suitable for the computer and so on. In this way, the format is always adapted to the communication device the user 11 is using when communicating with the delivery system 18. The delivery system 18 receives the signal 32 and forwards the information in a deliver file signal 34 back to the user 11. As indicated above, the user 11 may also request a service by sending a request service signal 36 to the service delivery system 16. Preferably, a Service must be requested before files are requested. In general, a user 11 may always request a service before the file delivery system 18 and the behave server 14 are used. The service may provide access to a word processing service or any other type of service such as picture or video related services. Thus the user 11 may gain access to the requested word processing service without having a word processing program installed on the communication device that is used by the user 11 to communicate with the system 16. As mentioned above, the behave server 14 may be used when the retrieved services or documents require manipulation. For example, when the user 11 would like to make a picture sharper that is downloaded from the file delivery system 18, the user 11 may broadcast an object operation method invokation in the shape of a behave event signal 46 to the behave server 14 to inform the server 14 about the required event that the picture should be made sharper. The server 14 sends a session lookup signal 48 to the session server 40 to find out if there is a previously stored session in the session server 40 and to identify the user 11. Similarly, it should be noted that the system 18 also sends a session lookup signal 49 to the session server 40 when a file is requested, as described above. The system 18 then receives a deliver session 51 in response to the signal 49. If there is a previously stored session in the server 40, the server 40 sends back a deliver session signal 50 to the server 14 that receives the signal 50 and the server 14 sends a signal for executing an object operation method implementation in the shape of a execute behave script signal 52 to a behave runtime device 54, the latter being an objcet runtime environment core. The signal 52 may include object operation implementation logic, i.e. software code, in the shape of the script commands that are required to accomplish the requested event. The signal 52 may be in the XDF format or any other suitable format. The device 54 receives the signal 52 for the event of the behave script, i.e. the object operation method invokation, such as making a picture sharper, and obtains the required logic in the shape of a script. The device 54 then reads or interprets the script that constitutes the object operation method implementation and may, depending upon the type of event, execute logic or manipulate binding data. The latter is in principle mutation of attributes in an object by the object itself indirectly through the object runtime environment.
More particularly, the device 54 receives the signal 52 and loads the script, i.e. implementation logic for the object operations method related to the sharpness of the picture from a service runtime device 56 by sending a load behave script signal 58 thereto. Preferably, the signal 58 is always sent to the device 56 to obtain the required script. The device 56 receives the signal 58 and sends a prepare service signal 68 to a XDF runtime device 70, which is an object model that is a part of the object runtime environment. The device 56 may also receive an invoke service signal 82 from the service delivery system 16. The device 70 receives the signal 68 and sends a load service resources signal 72 to the server 12. The server 12 responds by sending back a deliver resources signal 74, including the requested resources, to the XDF runtime device 70. The device 70 may load one XDF document from the device 12 and then propagate data in the document to the current session binding pool. The device 56 may be designed to handle the request and response administration for the device 70. More particularly, the device 70 may then send a deliver service signal 76 to the service runtime device 56. The device receives the signal 76 and sends a deliver behave script signal 60 back to the device 54. If the device 56 activated the device 70 as a result of the invoke service signal 82, then the device 56 may send back an adapt service signal 84 to the service adaptation device 43, which is a part of the provision extension to the provider, that may forward the information in a deliver adapted service signal 86 to the service delivery system 16. However, before the signal 84 is sent to the system 16, the device 43 may send a load bindings signal 41 to the service adaptation unit 43 that sends back a deliver bindings signal 45 including the required bindings.
When the device 54 has received the script signal 60, the device 54 determines the next steps which may include sending an execute logic signal 62 to a service processing unit 64, i.e. an execution module, or a manipulate bindings signal 66 to the session server 40. The first time a service is loaded, one or more behave scripts may be executed even before the service has reached the requesting user 11. For example, if a credit card transaction service is to be delivered, it may be necessary to prepare the request by executing logic when the request is sent to the credit card company but before the service is delivered to the client. With reference to the above example of making a picture sharper, the device 54 sends the execute logic signal 62 to the device 64. Because the sharpness of the picture is a mathematical calculation that is applied to the picture, it is necessary for the device 54 to send the execute logic signal 62 to the processing unit 64. The unit 64 receives the signal 62 and sends a load logic and content signal 78 to the server 12. It should be noted that the device 64 may communicate with some external systems without using the device 12. The server may send a transaction signal 88 to an external content adaptation unit 90 that communicates with an external actor 92, such as a database. When the requested transaction is carried out by the server 12, the server 12 responds to the unit 64 by delivering a transaction state by using the deliver signal 80. When the unit 64 receives the signal 80, it sends a deliver resources signal 94 to the device 54 that, in turn, sends a deliver resource signal 96 to the behave server 14. The server 14 then sends a deliver response signal 98 back to the user 11. In this way, the unit 64 carries out at least two steps including uploading logic, for making a picture sharper, and loading the picture itself from a cache location.
As mentioned above, the behave runtime device 54 may send the manipulate bindings signal 66 to the server 40. For example, the signal 66 may manipulate stored bindings in the session server 40 to make the picture sharper so that future service requests will operate with the manipulated sharper picture. The signal 66 is related to a binding pool that is created whenever a new session is created in the session server 40. For example, the binding pool includes all the data that is required to describe all the variables that are active depending upon the services that are currently loaded. Regarding the picture example, the binding pool may, for example, include the width, height and location of the picture. If the session concerns a word processing document, the signal 66 may include instructions to make a text segment bold by manipulating the bindings, such as adding tags for bold text, that are related to the text segment. In general, the signal 66 does not involve any logic and requests less complicated changes of the picture compared to changes that require the execution of logic in the device 64. It should be noted that the information to actually make the actual display of the picture sharper for the user 11 is sent via the behave server 14 and the deliver response signals 96 and 98.
The system 10 may import information from a large number of databases and assemble and present the information in one document because all the external information 5 is adapted to the XDF format by the external content adaptation unit 90, which is an object connectivity component, before it is stored in the server 12. For example, the system 10 may import hundreds of databases for film reviews in many formats and merge all the database information into one database in one format that includes the film reviews from all the external databases. In conventional systems, imported databases must be kept separate ιo within the system.
The user may gain access to very powerful services, functionalities and resources provided at the server although the communication device itself is relatively primitive because it is not necessary for the communication device to have any powerful programs installed. It is sufficient for the user to gain access to the resources of the system
15 10 and utilize the processing power of the system 10 which substantially reduce the processing power required of the computer device used by the user 11. When the user 11 logs out from the system 10, all sessions in the session server 40 are, preferably, saved in the server 12.
When a user edits the document, changes are broadcast to the other
20 users. More than one user may edit the same document simultaneously provided they work on different parts of the same document.
Preferably, each behave server 14, service delivery system 16 and file delivery system 18 has a core module that may include the service runtime device, the behave runtime device, the XDF runtime device and the service processing unit.
25 The invention has been explained above by means of exemplifying embodiments, and it can be implemented in various other ways within the framework of the accompanying claims.

Claims

Claims
1. A method for processing data objects in a distributed data processing system, said distributed data processing system having a plurality of software and/or hardware
5 nodes being communicatively connectable, the method comprising the steps of: defining a first environment for processing objects at a first level of abstraction that is independent of the software/hardware platform of said nodes; defining a second environment for processing objects at a second level of o abstraction that is dependent on the software/hardware platform of said nodes; defining in said first environment a first object model with a first category of object aspects; defining in said second environment a second object model with a second category of object aspects; 5 synchronizing said first object model of said first environment with said second object model of said second environment; defining an object in accordance with said first and second models associating a selectable set of object aspects from said first and second object aspect categories; 0 generating an instance of said obj ect; processing said object instance in said first and second environments dependent on said associated set of object aspects.
2. The method as recited in any of the preceding claim, wherein predefined 5 object connectivity means, in the shape of software code portions and protocols, communicatively coupled to said first, platform independent environment, are devised to interface with and execute data communications between an internal entity situated within and an external entity situated without said defined first and second environments.
3. The method as recited in the preceding claim, wherein an instance of said first, platform independent environment is configured together with an instance of said second, platform dependent environment and object connectivity means to constitute a object provider functionality.
4. The method as recited in any of the preceding claim, wherein an instance of said first, platform independent environment is configured together with an instance of said second, platform dependent environment to constitute a service object functionality.
5. The method as recited in the preceding claim, wherein a service provider functionality is configured together with and a service consumer functionality constituting a consumer/provider subset of the distributed system.
6. The method as recited in the preceding claim, wherein routing means enables routing of data and control signals within said consumer/provider subset of the distributed system.
7. The method as recited in the preceding claim, wherein authentication means provides authentication functionality in accessing said consumer/provider subset of the distributed system.
8. The method as recited in the preceding claim, wherein provisioning means enables provisioning of objects to a consumer within said consumer/provider subset of the distributed system and adapts said objects to the technical configuration of the consumer apparatus.
9. The method as recited in any of the preceding claim, wherein said object instance when it is generated is associated with an identification indication that is unique within said distributed system.
10. The method as recited in any of the preceding claim, wherein an object is defined by means of a plurality of aspects comprising an object property definition, an interface definition, an object instance aspect and an object instance reference aspect.
11. The method as recited in any of the preceding claim, wherein data is encapsulated in an object instance by means of an attribute devised to store a selectable predetermined type of basic entity for containing data, said type of basic entity being dependent on the type of data to be stored.
12. The method as recited in the preceding claim, wherein an attribute of a first object instance is devised to contain a reference to a second object instance for accessing or activating a selectable content of said second object instance.
13. The method as recited in any of the preceding claim, wherein an object instance is accessed or activated by means of a portion of executable code associated with said object and devised to perform a predefined task of said object.
14. The method as recited in the preceding claim, wherein said portion of executable software code is available and devised to activate execution of functionality or operations of said object instance, or to access or manipulate data that is encapsulated in the object.
15. The method as recited in any of the preceding claim, wherein information is encapsulated in an object instance at a first node in said distributed system and is accessible, dependent on predetermined access parameters, from an arbitrary second node in said distributed system.
16. The method as recited in any of the preceding claim, wherein a service, possibly involving software logic, is encapsulated in an object instance at a first node in
5 said distributed system and is accessible, dependent on predetermined access parameters, from an arbitrary second node in said distributed system.
17. The method as recited in any of the preceding claim, wherein an object is devised to represent a physical entity, an object instance thus being defined to access,
10 interface with or control said physical entity.
18. The method as recited in any of the preceding claim, wherein all information within the distributed system is stored in common and single format and structured in a common way independent of the type of said information.
15
19. The method as recited in any of the preceding claim, wherein an object and a software component within said distributed system are expressed in a common predetermined language and with a common predetermined set of language rules.
20 20. A system for processing data objects in a distributed data processing system, said distributed data processing system having a plurality of software and/or hardware nodes being communicatively connectable, comprising means for realizing the steps and functions of any of the preceding claims.
25 21. A computer program product for processing data objects in a distributed data processing system, said distributed data processing system having a plurality of software and/or hardware nodes being communicatively connectable, comprising computer program code portions devised to direct a data processing system to perform the steps and functions of any of the preceding claims.
22. A network based system for enabling a user to gain access to services and files, with steps and functions according to any of the preceding claims, further
5 comprising: a distribution and synchronization server 12 devised for distribution and synchronization of service and file data; a behave server 14 devised to be used by external actors to interact with services and to perform scripts defining a predetermined behavior such as data
1 o manipulation or execution of logic; a service delivery server 16 that is devised to act upon requests for services, loads the service, adapts it and then delivers it to a requesting user 11 ; a file delivery server 18 that is devised to act in response to a request service signal for a certain file, loads the file, adapts it and then delivers it to a requesting user 15 11.
23. The system of any of the preceding claims, wherein the access to information is independent of the user access device, which may be a conventional computer, a WAP device, a mobile phone or any other communication device that is connectable to the
2 o system.
24. The system of the preceding claim, wherein the behave server 14 is used by a user 11 to manipulate information or a service.
25 25. The system of any of the preceding claims, wherein each behave server 14, service delivery system 16 and file delivery system 18 has a core module that includes a service runtime device, a behave runtime device, a document format (XDF) runtime device and a service processing unit.
26. The system of any of the preceding claims, wherein the system is devised to give access to different functionality dependent on the technical capabilities of the user communication device.
27. The system of any of the preceding claims, wherein a service is requested by a user 11 by sending a request service signal 36 to the service delivery system 16, whereupon any possibly needed software code is executed in the server system and the service is delivered by presenting the resulting information on the communication device of the user.
28. The system of any of the preceding claims, wherein the system constitutes an Internet based operating system enabling a user to gain access to services and files.
PCT/SE2002/001594 2001-09-05 2002-09-05 Technology independent information management WO2003021375A2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US10/525,769 US20060047709A1 (en) 2001-09-05 2002-09-05 Technology independent information management
AU2002329148A AU2002329148A1 (en) 2001-09-05 2002-09-05 Technology independent information management
EP02765744A EP1546877A2 (en) 2002-09-05 2002-09-05 Technology independent information management

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US31729601P 2001-09-05 2001-09-05
US60/317,296 2001-09-05

Publications (2)

Publication Number Publication Date
WO2003021375A2 true WO2003021375A2 (en) 2003-03-13
WO2003021375A3 WO2003021375A3 (en) 2003-10-09

Family

ID=23233024

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2002/001594 WO2003021375A2 (en) 2001-09-05 2002-09-05 Technology independent information management

Country Status (4)

Country Link
US (1) US20060047709A1 (en)
CN (1) CN1682186A (en)
AU (1) AU2002329148A1 (en)
WO (1) WO2003021375A2 (en)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070150480A1 (en) * 2005-04-11 2007-06-28 Hans Hwang Service delivery platform
US7917124B2 (en) * 2005-09-20 2011-03-29 Accenture Global Services Limited Third party access gateway for telecommunications services
US7920583B2 (en) 2005-10-28 2011-04-05 Accenture Global Services Limited Message sequencing and data translation architecture for telecommunication services
US7870478B1 (en) * 2005-10-31 2011-01-11 Adobe Systems Incorporated Repurposing subsections and/or objects
US7702753B2 (en) * 2005-11-21 2010-04-20 Accenture Global Services Gmbh Unified directory and presence system for universal access to telecommunications services
JP4677355B2 (en) * 2006-03-03 2011-04-27 キヤノン株式会社 Web service apparatus and sequential process transfer method
US9727604B2 (en) * 2006-03-10 2017-08-08 International Business Machines Corporation Generating code for an integrated data system
US9361137B2 (en) 2006-03-10 2016-06-07 International Business Machines Corporation Managing application parameters based on parameter types
US20080114819A1 (en) * 2006-05-16 2008-05-15 Mattel, Inc. Method and Apparatus for Storage, Retrieval, and Synchronization of Multimedia Data
US7778965B2 (en) * 2006-05-23 2010-08-17 Sap Ag Systems and methods for common instance handling of providers in a plurality of frameworks
US8099725B2 (en) * 2006-10-11 2012-01-17 International Business Machines Corporation Method and apparatus for generating code for an extract, transform, and load (ETL) data flow
US8160999B2 (en) * 2006-12-13 2012-04-17 International Business Machines Corporation Method and apparatus for using set based structured query language (SQL) to implement extract, transform, and load (ETL) splitter operation
US8219518B2 (en) 2007-01-09 2012-07-10 International Business Machines Corporation Method and apparatus for modelling data exchange in a data flow of an extract, transform, and load (ETL) process
US8250169B2 (en) * 2007-09-24 2012-08-21 Sap Ag Business context data companion tool
US8127237B2 (en) 2007-09-24 2012-02-28 Sap Ag Active business client
BRPI0916392A2 (en) * 2008-07-30 2018-02-06 Telcordia Tech Inc system and method for unifying multiple service environments for optimizing the provision of telecommunications services
US8782530B2 (en) * 2009-03-25 2014-07-15 Sap Ag Method and system for providing a user interface in a computer
US8712953B2 (en) * 2009-03-25 2014-04-29 Sap Ag Data consumption framework for semantic objects
CN102571939A (en) * 2011-12-26 2012-07-11 广州市玄武无线科技有限公司 Cross-platform communication method and system
US9240970B2 (en) 2012-03-07 2016-01-19 Accenture Global Services Limited Communication collaboration
US9690563B2 (en) * 2012-05-17 2017-06-27 International Business Machines Corporation Updating web resources
US10534633B2 (en) * 2015-10-12 2020-01-14 Computational Systems, Inc. Extensible asset classes in a monitoring system having a common platform

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1126681A2 (en) * 2000-01-14 2001-08-22 Sun Microsystems, Inc. A network portal system and methods
EP1202174A2 (en) * 2000-10-23 2002-05-02 Nec Corporation Stub search loading system and method, server apparatus, client apparatus, and computer-readable recording medium

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5157777A (en) * 1989-12-22 1992-10-20 Intel Corporation Synchronous communication between execution environments in a data processing system employing an object-oriented memory protection mechanism
US5740161A (en) * 1995-11-08 1998-04-14 Intel Corporation Method and apparatus for synchronizing viewed information in a conferencing environment
US6237142B1 (en) * 1996-11-12 2001-05-22 International Business Machines Corporation Method for synchronization between links and group definitions within an object-oriented system
US6134594A (en) * 1997-10-28 2000-10-17 Microsoft Corporation Multi-user, multiple tier distributed application architecture with single-user access control of middle tier objects
US6832120B1 (en) * 1998-05-15 2004-12-14 Tridium, Inc. System and methods for object-oriented control of diverse electromechanical systems using a computer network
US6829770B1 (en) * 1999-02-23 2004-12-07 Microsoft Corporation Object connectivity through loosely coupled publish and subscribe events
US6463427B1 (en) * 1999-03-16 2002-10-08 Microsoft Corporation Use of object signature property as a search parameter during synchronization of objects on a computer
US6467086B1 (en) * 1999-07-20 2002-10-15 Xerox Corporation Aspect-oriented programming
US6505200B1 (en) * 2000-07-06 2003-01-07 International Business Machines Corporation Application-independent data synchronization technique

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1126681A2 (en) * 2000-01-14 2001-08-22 Sun Microsystems, Inc. A network portal system and methods
EP1202174A2 (en) * 2000-10-23 2002-05-02 Nec Corporation Stub search loading system and method, server apparatus, client apparatus, and computer-readable recording medium

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
GAMMA ET AL.: 'Design patterns: Elements of reusable object-oriented software', 1995, ADDISON-WESLEY XP002958460 pages 151-161, 87-95 *
MEYER B.: 'Net is Coming' MICROSOFT WEB SERVICES PLATFORM. PUBL.: COMPUTER, IEEE COMPUT. SOC. USA vol. 34, no. 8, August 2001, pages 92 - 97, XP001103942 *
ROY J. ET AL.: 'XML: Data's universal language' IT PROF. (USA), IEEE vol. 2, no. 3, May 2000 - June 2000, pages 32 - 36, XP002958461 *
TILLEY T. ET AL.: 'GUI framework communication via the WWW', 2000, ASIA PACIFIC WEB CONFERENCE XP002962560 in "World Wide Web: Technologies and Applications for the New Millenium", Computer Science Research, Education and Applications Press * page 297 - page 302 * *
VINOSKI S.: 'CORBA: Integrating diverse applications within distributed heterogeneous environments' IEEE COMMUN. MAG. (USA), IEEE COMMUNICATIONS MAGAZINE, vol. 35, no. 2, February 1997, pages 46 - 55, XP000683401 *

Also Published As

Publication number Publication date
WO2003021375A3 (en) 2003-10-09
US20060047709A1 (en) 2006-03-02
CN1682186A (en) 2005-10-12
AU2002329148A1 (en) 2003-03-18

Similar Documents

Publication Publication Date Title
US20060047709A1 (en) Technology independent information management
US7188158B1 (en) System and method for component-based software development
US8473896B2 (en) Computer software development incorporating core and compound services
US5949998A (en) Filtering an object interface definition to determine services needed and provided
US7080092B2 (en) Application view component for system integration
US7627865B2 (en) Method and apparatus for accessing instrumentation data from within a managed code environment
US20040225995A1 (en) Reusable software controls
US20020184401A1 (en) Extensible information system
US20020078255A1 (en) Pluggable instantiable distributed objects
US8843938B2 (en) Methods, systems, and computer program products for asynchronous resumption of a dataflow
CA2376792A1 (en) Method and apparatus for providing network services
EP1723516A1 (en) System and method for building mixed mode execution environment for component applications
Ferrara et al. Programming. NET web services
EP1444609A1 (en) Application view component for system integration
Fayçal et al. Integrating legacy systems in a SOA using an agent based approach for information system agility
Srinivasmurthy et al. Web2exchange: A model-based service transformation and integration environment
EP1546877A2 (en) Technology independent information management
Newell et al. Interoperable object models for large scale distributed systems
Cupek et al. OData for service-oriented business applications: Comparative analysis of communication technologies for flexible Service-Oriented IT architectures
Domazet Enabling engineering collaboration in inter-enterprise design chains using collaborative agents
Vijayalakshmi An integrated development environment to establish web services in grid computing Using. NET framework 4.5 and Visual Basic 2012
GB2370658A (en) A modular software framework
Dünnweber et al. Component-Based Grid Programming Using the HOC-Service Architecture.
Cobb CORBA Components
Yang et al. Web Applications Development Using J2EE Architecture

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BY BZ CA CH CN CO CR CU CZ DE DM DZ EC EE ES FI GB GD GE GH HR HU ID IL IN IS JP KE KG KP KR LC LK LR LS LT LU LV MA MD MG MN MW MX MZ NO NZ OM PH PL PT RU SD SE SG SI SK SL TJ TM TN TR TZ UA UG US UZ VC VN YU ZA ZM

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ UG ZM ZW AM AZ BY KG KZ RU TJ TM AT BE BG CH CY CZ DK EE ES FI FR GB GR IE IT LU MC PT SE SK TR BF BJ CF CG CI GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
ENP Entry into the national phase

Ref document number: 2006047709

Country of ref document: US

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 10525769

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 809/DELNP/2005

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 20028295641

Country of ref document: CN

Ref document number: 2002765744

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2002765744

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10525769

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: JP