Mechanism and apparatus for accessing and addressing services in a distributed computing environment

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

(Background of invention) (1. Field of invention) The present invention relates to a distributed computing environment including a web-centric and Internet-centric distributed computing environment, and more particularly to a heterogeneous distributed computing environment based on a message passing model that connects network clients and services. [0002]

(2. Explanation of related technologies) Intelligent devices are becoming more widespread. Such devices include smart appliances, personal digital assistants (PDAs), mobile phones, laptop computers, desktop computers, workstations, mainframes, and even supercomputers. Networks are also becoming a popular way to interconnect intelligent devices that can communicate with each other. However, there are significant differences in the computing and memory capabilities of various intelligent devices. Devices with limited capabilities are sometimes referred to as space-saving devices or "thin" devices. Thin devices may not be able to participate in networks that interconnect more capable devices. However, it may be desirable to interconnect a wide variety of different types of intelligent devices. [0003]

Improving networking capabilities is even more desired. Business networks continue to grow to capture direct interaction between suppliers and customers. Mobile phones, personal digital assistants, and Internet-enabled computers have become commonplace in businesses and at home. Home networks can be used to interconnect audio / visual equipment such as televisions and stereo equipment to home computers and other devices that control intelligent systems such as security systems and temperature control thermostats. .. High-bandwidth media such as cable and ASDL can be used to improve services such as Internet access, video on demand, and e-commerce. Network systems are in the process of becoming widespread. It is desirable for intelligent devices to be able to communicate and share resources with each other without a formal network. [0004]

Today, traditional network setup, expansion and management is a complex task. For example, adding hardware or software to a network often requires the network administrator to load the drivers and configure the system. Even small changes to the network configuration may require the entire network to be down for a period of time. In addition, some intelligent devices do not support the interfaces required to communicate over a given network. [0005]

What is needed is a simple way to connect a variety of intelligent devices to enable communication and resource sharing while avoiding the interoperability and complex configuration issues found in traditional networks. There are various technologies that improve the ability to add devices to the network. For example, many modern I / O buses, such as the Universal Serial Bus, 1394, and PCI, support Plug and Play and dynamic discovery protocols, making it easy to add new devices to the bus. Can be done. However, these solutions are limited to specific peripheral buses and are not suitable for general networks. [0006]

A recent technology, Jini from Sun Microsystems, Inc., seeks to make it easy to connect and share devices such as printers and disk drives over the network. Devices that incorporate Jini make announcements to the network, give details about their device's capabilities, and immediately become accessible to other devices on the network. Jini enables distributed computing that shares the functionality of various devices over the network. Jini technology aims to allow users to share services and resources over the network. Another goal of Jini technology is to make it easy for users to access resources anywhere on the network, even if the user's network location changes. Jini also seeks to simplify the task of building, maintaining, and modifying networks of devices, software, and users. [0007]

Jini requires each Jini-enabled device to have a certain amount of memory and processing power. Jini-enabled devices typically include a Java® Virtual Machine (JVM). Therefore, the Jini system is centered on Java technology. Java is a high-level object-oriented programming language developed by Sun Microsystems, Inc. You can compile Java source code into a format called bytecode and run it in a Java virtual machine. [0008]

Bytecode is computer source code that is processed by a virtual machine, not a hardware processor that is a "real" computer machine. A virtual machine translates a generalized machine language instruction (bytecode) into a specific machine language instruction (instruction understood by a computer processor). You can use the language that comes with each platform's virtual machine to compile the source language statement only once and run it on the platforms that support that virtual machine. The Java programming language is an example of such a language, and the Java Virtual Machine (JVM) is an example of a virtual machine platform that supports programs written in the Java programming language. Java virtual machines are available on most computing platforms, so Java and therefore Jini have achieved some platform independence. The Jini architecture takes advantage of the assumption that the Java programming language is the implementation language for the components of the Jini system. The ability to dynamically download and execute Java code is central to many features of the Jini architecture. [0009]

The purpose of the Jini architecture is to combine multiple groups of devices and software components into a single dynamic distributed system. An important concept in the Jini architecture is the concept of services. A service is an entity that can be used by a person, program, or other service. There are two examples of services: a service that prints a document and a service that converts one word processor format to the other. Jini allows members of the Jini system to share access to services. Services within the Jini system communicate with each other by using a service protocol, a set of interfaces written in the Java programming language. Service exploration and solutions are done using lookup services within the Jini system. A lookup service maps an interface that represents the functionality provided by a service to a set of objects that implement the service. [0010]

Descriptive entries can also be associated with services. Devices and applications register with the Jini network using a process called discovery. Once registered, the device or application enters the lookup service. The lookup service not only stores pointers to these services on the network, but also stores the code to access these services. For example, when a printer is registered with the lookup service, it loads the printer driver and / or the interface with the driver into the lookup service. When a client requests the use of a printer, its drivers and driver interfaces are downloaded from the lookup service to the client. The ability to move code in this way means that services from the network can be used on the client side without pre-installing or loading drivers or other software. [0011]

Communication between services in the Jini system is done using Java Remote Method Invocation (RMI). RMI is a Java programming language extension to the traditional remote procedure call mechanism. RMI not only allows you to pass data from object to object within the Jini network, but it can also pass complete objects, including code. The Jini system relies on the ability of code to navigate the network in a form encapsulated as Java objects. [0012]

Access to services within the Jini system is lease-based. Leasing is the granting of guaranteed access for a period of time. Each lease is negotiated between the user of the service and the provider of the service as part of the service protocol. When a service is requested for a period of time, access can be granted for a period of time, probably the requested period. The lease needs to be renewed for the service to remain part of the Jini system. [0013]

Figure 1 shows the accumulation of Jini's basic technologies. Jini technology defines distributed programming model 12 (supported by JavaSpaces, leases, and object templates). Jini's object communication is based on RMI Layer 14 on TCP / IP enabled networking Layer 16. [0014]

Jini is a promising technology for simplifying distributed computing. However, depending on the type of device, Jini may not be suitable. The flow of computing technology is moving towards distributed web-centric services and content models, and the content of client services and content is changing rapidly. Future clients will be companion-type devices that users can take anywhere. As such a device, for example, a combination of a mobile phone and a PDA can be considered. It is desirable for such devices to be able to communicate and share resources not only with more powerful devices, but also with lighter, thinner or less powerful devices. [0015]

In addition, the advent of the Internet has resulted in an explosive increase in the number of devices connected to the Internet, requiring a distributed programming model designed to take advantage of this phenomenon. Realization technology is required to enable clients to connect to services in a reliable, secure and secure manner. A variety of clients and services, from thick clients to thin clients, need to be connected over the Internet, corporate intranets, and even within a single computer. It is desirable to abstract the distance, latency, and implementation from both the client and the service. [0016]

A key challenge in distributed computing technology is to make it scalable, from powerful chic clients to very lightweight thin clients such as embedded mobile devices. Current distributed computing technologies such as Jini are not scalable enough to meet the needs of all types of clients. Some devices, such as space-saving devices and embedded devices, do not have sufficient memory resources or sufficient networking bandwidth to fully participate in current distributed computing technology. The low end of client products, such as embedded mobile devices, often has a limited or fixed code execution environment. These devices may also have minimal storage capacity or may not be persistent at all. Most small embedded mobile devices do not support Java virtual machines. Most code-executable small clients execute only native code. In addition, most small devices have at best flash memory or battery backup RAM as their sole persistent storage media. The storage capacity is very small, often inherently read-only. In addition, the access time for this type of storage media is often an order of magnitude slower than the access time for more powerful clients' hard disks. [0017]

Existing connectivity technologies such as Jini cannot be as scalable as you would like due to their large size. For example, Jini requires all participants to support Java, but many small clients cannot reserve resources for the Java virtual machine. In addition, Jini uses RMI, so you need to be able to download code and content on the client side. Jini reinforces existing client platforms by downloading new classes, which can pose raw security and size issues for smaller devices such as embedded devices. Jini works by passing code and data so that clients and resources communicate. When the client activates the Jini service, the service returns the result to the client, which can contain a lot of code or content. In Jini, the client may call a method, return a large object, and download it. The client may not have enough resources to accept the returned object. In addition, RMI and Java itself require a lot of memory. Many space-saving devices may not have the resources to add virtually or even a small amount to current distributed computing technology. [0018]

Another problem with existing distributed computing technologies is that they often require multiple levels of connectivity and protocols. For example, Jini assumes that there is a reasonably fast network for connecting computers and devices. Jini also requires a device that supports the TCP / IP network transport protocol. However, many small devices have limited connectivity. Small devices may have long or slow network connection latency and may not support TCP / IP. [0019]

As mentioned above, Jini requires a device with a Java virtual machine that supports Java, and therefore requires processing power and storage capabilities not found in many smaller devices. This also limits Jini's flexibility in that non-Java-enabled devices cannot directly participate in the Jini system. Since Jini requires Java, it can be considered a homogeneous environment. However, it is desirable to have distributed computing capabilities that support heterogeneous distributed computing, from very small embedded devices to PDAs, mobile phones, and even laptops and the strongest computers. There are other heterogeneous solutions such as the Common Object Request Broker Architecture (CORBA). CORBA is an architecture that allows program objects to communicate with each other regardless of the programming language used to create them or the operating system on which they run. However, CORBA does not handle all the connection issues that Jini deals with. In addition, CORBA has similar scalability issues as Jini. [0020]

Technologies such as Jini and CORBA use a code-centric programming model to define interfaces between remote computers. The code-centric programming model defines program interfaces or APIs for communication between remote clients or components. The API can be defined in a particular programming language. The API must be consistent across all software components to ensure proper interoperability. All access to the components is done through these standard APIs, so the code that implements these APIs must exist within the client platform. The code can be statically linked to the platform or dynamically downloaded as needed. Many embedded or mobile devices can dynamically accept code from the network because they rely not only on quality control issues, but also on a single language and program execution environment. You can't. Data-centric models such as networking protocols avoid relying on code movement, but such protocols are not feature-rich enough to easily support distributed computing, and code and other code such as type safety. Programming with the programming function cannot be done easily. [0021] [0021]

Traditional distributed computing systems rely on the ability of programs running on the first device to remotely call programs on the second device, and the results are returned to the first device. Remote Procedure Call (RPC) is the basic mechanism for making remote calls to a program or procedure. Both CORBA and Jini are based on the ability to call program methods remotely. However, communicating by passing code or objects such as Jini or CORBA can be somewhat complicated. For example, as mentioned above, in Jini the Java Remote Method Communicate between services using Invocation (RMI). Clients need some means of serialization / deserialization to move Java objects to and from remote locations. These current features in the Java Development Kit (JDK) rely on the reflection API to determine the content of Java objects, which ultimately requires the code to query the virtual machine. This code is quite large and inefficient. [0022]

Current methods for serialization / deserialization have fundamental issues with size, speed, and object traversal models. Code outside the JVM is unaware of the structure or graph of the Java object, so you need to traverse the object graph, pull it apart, and finally call the JVM. Traditional serialization and reflection mechanisms for storing and moving Java objects are impractical for all types of devices, especially the lighter weight thin devices. The problem with Java reflection and serialization is that object graph (transitive closure) reflection is difficult to perform outside the JVM. Serialization requires a lot of code and is too big. In addition, serialization is a Java-specific object exchange format that cannot be used on non-Java-enabled devices. [0023]

The Jini distributed computing model requires moving Java objects between Java devices. Therefore, the serialization mechanism itself is not platform-independent because it cannot be used to ship and receive objects on non-Java-enabled platforms. Serialization is a homogeneous object format that works only on the Java platform. Since serialization uses the reflection API, it may be subject to security-related restrictions, which often need to be addressed using native JVM-dependent methods. The reflection API can provide a graph of objects, but it is inefficient because it makes multiple calls between the JVM and the code that calls the reflection method. [0024]

To serialize an object using Java reflection, the application must interact with the JVM like a ping pong and retrieve the object one field at a time when dynamically parsing the transitive closure of the object. .. To deserialize an object using Java deserialization, the application must work closely with the JVM to reconstruct the object one field at a time when dynamically parsing the transitive closure of the object. There is. As a result, Java serialization / deserialization is time consuming, cumbersome, and requires a lot of application and JVM code writing, as well as persistent storage space. [0025]

Even for thin clients that support Java, Jini RMI may not be practical for thin clients with minimal memory footprint and minimum bandwidth. Jini Serialization associated with RMI is a representation of Java-specific objects that is long-running, large in code size, requires a JVM reflection API. Java deserialization is also slow to execute, has a large code size, and requires a serialization object parser. Even Java-based thin clients may not be able to accept the huge Java objects (along the required classes) that are (always) returned to the client over the network when requested within Jini. A more scalable distributed computing mechanism is needed. Extendable to address security issues with a more scalable distributed computing mechanism, allow the passing of objects such as Java objects, and move processes from one network mode to the other. Is desirable. [0026]

Object-based distributed computing systems require persistent storage. However, as mentioned above, attempts at object storage are often language and operating system specific. Moreover, these object storage systems are too complex to be used in many small embedded systems. For example, Jini technology uses JavaSpaces as a persistent object container. However, JavaSpace only stores Java objects and cannot be implemented on small devices. Each object in JavaSpace. It is serialized and pays the above-mentioned penalties associated with Java serialization. It would be desirable to have a heterogeneous object repository for distributed computing from small to large devices. [0027]

Java Spaces from Sun Microsystems, Inc. utilizes the results of parallel processing by Professor David Gelernter of the Faculty of Computer Science, Yale University. Professor Gelernter's feature set named "Linda" creates a shared memory space called TupleSpace, which stores the results of computer processes or those processes themselves and makes them accessible to multiple CPUs. Linda therefore has global shared memory for multiple processors. [0028]

Another technology that extends Linda is IBM Corporation's TSpace. TSpace extends the basic Linda TupleSpace framework to provide real-world data management and download of new data types and new semantic features. TSpace has a set of network communication buffers and a set of APIs to access these buffers. Therefore, like many of the solutions mentioned above, TSpace uses a code-centric programming model and shares the shortcomings of such a model. In addition, because TSpace is implemented in the Java programming language, it requires other means, such as a Java virtual machine or a Java executable microprocessor that executes Java bytecode. Therefore, TSpace seems unsuitable for space-saving devices that cannot allocate sufficient resources exclusively for Java bytecode execution. [0029]

In an object-oriented distributed system, it is desirable to be able to identify object repositories and find specific objects within those repositories. As stated, the Jini lookup server seems impractical for small devices with a small memory footprint. It is desirable to have a more efficient mechanism for identifying object stores. [0030]

In a distributed network computing model, it is desirable for clients to have the ability to identify services. Current network protocols provide only a single standard service access interface with no security when accessing network services, or the entire service, including administrator or privileged features. Provides "all or nothing" access to the feature. Also, current network protocols for identifying services do not provide a flexible mechanism for finding services. Current protocols either have no selective search capabilities (eg UPnP) or only primitive keywords and attribute grammar mechanisms (eg SLP). As a result, current service discovery mechanisms may be too inflexible with respect to security and search criteria mechanisms. [0031]

In addition, current service discovery models use a symmetric model to identify services. However, it would be a waste of resources for some service devices, such as devices that can use proximity-based features, to support the discovery model. This is because such devices have already been identified because they are in close proximity (for example, one device that physically points to the other device). Therefore, an alternative lightweight discovery mechanism would also be desirable for such devices. [0032]

Distributed object access also requires an unbiased and efficient sharing mechanism. As mentioned above, Jini currently uses a leasing mechanism to share objects. However, Jini's leasing is time-based, which can lead to a variety of problems. For example, current object holders may have too long a retention period without the idea of how long to lease the object. In addition, time-based leasing requires time to be synchronized across multiple machines. In addition, time-based leasing may require operating system support. In addition, Jini's lease will be established and released via RMI. As a result, Jini's leasing mechanism has the above-mentioned problems of using RMI. In addition, Jini's leasing mechanism does not provide a security mechanism for establishing, renewing, and revoking leases. Other leasing mechanisms may also be desirable. [0033]

In general, mobile client devices with a small memory footprint should be able to run a variety of services in a distributed environment, both legacy and new services. Small clients include mobile phones and PDAs, which typically have a variety of low-bandwidth networking interfaces. These devices often have very small displays with limited graphics capabilities, but some laptops and notebook computers have large screen displays and advanced graphics capabilities. Services include control programs for devices such as printers as well as various applications. It is desirable for mobile clients to be able to use these services wherever they are available. [0034]

Mobile clients are often assigned a temporary dynamic network address, and networking messages sent by this client cannot be delivered beyond that networking interface (otherwise on a different network). Conflicts can occur when two different clients have the same dynamic address). Mobile clients often do not have full-featured browsers or other advanced software-aware features. In some cases, the display is limited and the client cannot run some applications. Traditional application models are based on a given user interface or data characteristics. Any changes to the application will require recompilation. [0035]

It may be desirable for such clients to have a mechanism for finding and invoking distributed applications or services. The client may need to run larger legacy applications that may not fit in the client's memory footprint. As mentioned above, current technologies such as Jini may not be practical for space-saving devices. In addition, the spread of mobile thin clients may further increase needs. For example, it may be desirable to identify a service based on the physical location of the user and the user's mobile client. For example, information about local services such as local restaurants, weather, road traffic maps, and movie information can be very helpful. Similarly, information about computational resources such as printers in a particular location is useful. Current technology does not provide an automatic mechanism to identify services based on the physical location of the client. Other raw needs of thin mobile clients deal with human factors. Thin mobile clients typically do not have an ergonomic keyboard and monitor. It is desirable to have the ability to provide such human factor services and / or identify such services in a distributed computing environment. The distributed computing model requires clients to have a means of finding temporary documents and services. It may be desirable to have a mechanism for finding generic documents (including services and / or service notifications) that are represented by platform-independent and language-independent types, such as those provided by Enhanced Markup Language (XML). Jini, Universal Plug and Play (UPnP), and Service Location Current approaches, including the Protocol (SLP) lookup mechanism, do not support such a generic document lookup mechanism. For example, the Jini lookup mechanism is limited to Java language typing and is therefore not language independent. UPnP and SLP support discovery protocols for services only, not generic documents. [0036]

(Gist of the invention) The problems outlined above are largely solved by various embodiments of systems and methods of notifying, addressing, and / or accessing services within a distributed computing environment. Distributed computing environments can rely on "spaces" or object repositories to provide rendezvous or catalyst for the interaction between clients and services. Service Pro "Biders can notify services in a space. Clients can find notifications in a space and use the information from the notifications for XML (extended markup language) messaging in a distributed computing environment. The service can be accessed using the mechanism. There can be a large number of spaces, each containing an XML notification that describes the service or content. Therefore, the spaces relate to raw data or data such as results. It can be a service XML notification and / or a repository of XML data, which can be a notification. [0037]

In one embodiment, the space itself is a service. Like any other service, the space has a notification, which must first be obtained in order for the space's clients to be able to run the space service. Space-specific notifications can include an XML schema, one or more certificates, and a Uniform Resource Identifier (URI) that indicates how to access the space. Clients can build gates from space service notifications to access the space. The space's clients themselves can be service providers seeking to look for notifications within the space or modify existing notifications. Alternatively, the space's client can be an application that seeks access to the services or content listed by the space. Thus, space can catalyze the interaction between clients and services in a distributed computing environment. [0038]

The space can contain a set of named notifications. Spaces can be created with a single route notification that describes the space itself. Additional notifications can be added to the space. The name of the notification allows you to identify the notification in the space, including specifying the required graphing information, such as the name hierarchy. In a preferred embodiment, the structure of the space is not dictated by the distributed computing environment. That is, the space can be configured, for example, as a flat, unrelated set of notifications or a graph of related notifications (eg, a commercial database). In a preferred embodiment, the distributed computing environment does not specify how the space actually stores its contents, so that the space can be supported by small to large devices. For example, a simple space can be adjusted to fit on a small device such as a PDA. More advanced space can be implemented on large servers using large commercial databases. [0039]

As mentioned above, the space can contain notifications about services in a distributed computing environment. Notifications can provide a mechanism for addressing and accessing services and / or content within a distributed computing environment. In the notification, you can specify the URI of the service. In some embodiments, URIs allow services to be accessed over the Internet. The notification can also include an XML schema for the service. The XML Schema allows you to specify a set of messages that a service client can send to a service to call a function of the service. XML Schema allows you to define the interface between a client and a service. The URI and XML specified in the notification can be combined to show how to address and access the service. Both the URI and the schema can be provided in XML as notifications in spaces. Therefore, the addressing and access mechanisms of services in a distributed computing environment can be published as notifications in the space. The client can discover the space and then look up individual notifications about the service or content. A space and all notifications within a space can be addressed using a URI. In one embodiment, the space name and notification name may be subject to a URL (Uniform Resource Locator) naming convention. In some embodiments, the space can be addressed throughout the Internet by using a URI, such as a URL, for addressing the space. [0040]

After a client in a space finds a notification for a space service, that client in the space can run the space service just like any other service. Note that the space service client may be another service (for example, a service that looks for notifications in the space). In one embodiment, in order to perform a space service, a space client can first perform an authentication service on the space to obtain an authentication token. The authentication service can be specified in the service notification of the space service. The space client uses the authentication token, the space XML schema (from the space service notification), and the space URI (from the space service notification) to build a gate for the space. Space clients can then execute the space service by using the gate to send a message to the space service. [0041]

For embodiments that use authentication, when the space service receives the first message with an embedded authentication token from the client, the space service provides the same authentication service (specified in the space service service notification). Use to authenticate the client and therefore identify the client. The space service can determine the capabilities of the client and bind them to the authentication token. [0042]

Space clients can perform various space functions by sending messages to the space service. In one embodiment, when the space client sends a request to the space service, it passes an authentication token on the request so that the space service can inspect the request for a particular function of the client. [0043]

Each space is usually a service and can have an XML schema that defines the core functionality of the space service. XML Schema allows you to specify the client interface to the space service. In one embodiment, all space services can provide a base level for space-related messages. The base level space feature can be a basic space feature that can be used by most clients, including small devices such as PDAs. It would be desirable to provide additional functionality, for example for more advanced clients. Extensions to the base-level space can be achieved by adding more messages to the XML schema notifying the space. For example, in one embodiment, the base level message does not impose any relationship graph on the notification. For example, a message that traverses the notification hierarchy can be a space extension. Providing such additional functionality can be achieved by providing one or more extended XML space schemas or schema extensions for spaces. The extended schema can include the base schema, so that clients of the extended space can still access the space as the base space. [0044]

In one embodiment, the space can provide the ability for the client to instantiate the service notified within the space. Instantiation of a service is an initialization act that causes a client to execute a service. To instantiate a service, the client can first select one of the service notifications published in the space. Clients can use different features, such as the lookup feature provided by the space, to look up the different notifications that are notified within the space. The client can then request the space to instantiate the service. [0045]

In one embodiment, the service instantiation can include the following actions: After the client requests the space service to instantiate the selected service, the space service verifies that the client is allowed to instantiate the requested service. The space service can perform this validation by inspecting the authentication token contained in the client message. An authentication token is a certificate that a client receives when establishing a session with a space service. The space service can verify whether the client is allowed to instantiate the requested service according to the client's authentication token and the capabilities shown for that client. [0046]

Assuming the client is allowed, the space service can also get a lease for a service notification about the client with the lease request time specified by the client. The space service can then send a message to the client containing service notifications for allocated leases and services. In one embodiment, the client can perform the authentication service specified in the service notification and obtain an authentication token. The client can then build a gate for the service (for example, using the authentication token and the XML schema and service URI from the notification). The communication between the client and the space service mentioned above is performed using XML messaging in a distributed computing environment. The client can then run the service using the configured gates and XML messaging. The service can also build a service gate for XML message communication with the client. [0047]

In one embodiment, the service notification includes substantially all of the information a client needs to access a particular service. Services can publish service notifications within the space. The space can be a network addressable storage location for documents such as extended markup language (XML) documents. In one embodiment, the notification can include the uniform resource identifier (URI) and schema of the service. The URI can specify the network address that can access the service, and the schema can specify one or more messages that can be used to call one or more functions of the service. In one embodiment, the schema and message can be represented in a data representation language such as XML. Clients can access the space and find notifications. For example, a client can use the discovery service to find a space and the lookup service to find notifications in the space. [0048]

The client can read the notification from the space. In one embodiment, the client can use the URI and schema in the notification to build a gate to access the service. The client can send a first message to the service at the URI to call one or more functions of the service, and this first message is specified in the schema. In response, you can call a function of the service. In one embodiment, the service can send a second message (eg, a message containing the result of the called function) to the client, which is specified in the service's schema. [0049]

The present invention allows for a variety of modifications and alternatives, the particular embodiment of which is illustrated by way of example and will be described in detail below. However, the drawings and detailed description thereof are not intended to limit the invention to the particular aspects disclosed, and conversely, all modifications within the spirit and scope of the invention. It should be understood that it includes aspects, equivalents, and alternative aspects. [0050]

(Detailed Description of Embodiments of the Invention) Overview of Distributed Computing Embodiments Figure 2 shows a programming model for a distributed computing environment. This model includes API Layer 102, which makes distributed computing easier to use. API layer 102 has an interface that facilitates the connection between the client and the service. API Layer 102 is involved in client and service discovery and connectivity. API layer 102 includes message sending and message receiving functions. This messaging API provides an interface for simple messages in representational or metadata formats, such as Extended Markup Language (XML). Although embodiments are described here for adopting XML, it should be noted that other embodiments may use other metadata type languages or formats. In some embodiments, the API layer can also include a message interface for communication between objects and passing objects, such as Java objects. There may be APIs for discovering object repositories or "spaces", finding specific objects, requesting and releasing objects, writing objects to object repositories, and retrieving objects from object repositories. .. Objects accessible through API Layer 102 can be represented in a representational data format such as XML. Therefore, as opposed to the object itself, the XML representation of the object can be manipulated. [0051]

API layer 102 is above messaging layer 104. Messaging layer 104 is based on a representational data format such as XML. In one embodiment, the XML message is generated by messaging layer 104 in response to a call to API layer 102. Messaging layer 104 includes predefined static messages that can be sent between the client and the service. Messaging layer 104 also supports dynamically generated messages. In one embodiment, objects such as Java objects can be dynamically transformed into XML representations. Messaging layer 104 allows XML object representations to be sent as messages. Conversely, messaging layer 104 can receive an XML representation of the object. The object can then be reconstructed from that message. In one embodiment, the message sent by messaging layer 104 can include multiple basic elements such as an address, an authentication certificate, a security token, and the message body. The sending and receiving mechanism of the message system can be completely unstated. The concept of state can be embedded in the message stream between the sender and the receiver. Therefore, the message is sent asynchronously. In a preferred embodiment, no connection model is imposed. Therefore, no transport such as TCP is required. Also, error conditions are limited to non-delivery or security exceptions. [0052]

The messaging layer 104 is above the message-enabled networking layer 106. In a preferred embodiment, messaging layer 104 does not need to use a particular networking protocol. TCP / IP and UDP / IP are examples of message-enabled protocols that can be used for message-enabled networking layer 106. However, other specialized protocols such as Wireless Application Protocol (WAP) can also be used. Other possible message protocols are IrDA and Bluetooth network drivers below the transport layer. Networking Layer 106 is not limited to a single trusted connection protocol such as TCP / IP. Therefore, it is possible to connect with various devices. [0053]

In one embodiment, message-enabled network layer 106 can be implemented from networking classes provided by the Java2 Micro Edition (J2ME) platform. The Java2 Micro Edition platform is suitable for space-saving devices that do not have the resources for the full Java platform or are inefficient to run the full Java platform. Small devices that already include distributed computing capabilities for the space-saving cost of adding messaging layer 104 because J2ME already has a message-enabled family of networking protocols (supporting sockets). Can be provided for. [0054]

Message-enabled networking layer 106 is also available in the java.net networking class of the Java Development Kit (JDK). Alternatively, the message-enabled networking feature can be used for message-enabled networking layer 106. In a preferred embodiment, no trusted transport is required, so embedded devices that support untrusted datagram transport, such as UDP / IP, can also support the messaging layer. Therefore, thin clients can participate in a distributed computing environment by simply adding thin messaging layer 104 on top of the underlying networking protocol stack. As shown in FIG. 3, the underlying system has a messaging layer 104 on top of the networking layer 106. The networking layer can handle trusted messages, such as TCP, or untrusted messages, such as UDP. The Internet Protocol (IP) is shown in Figure 3 as an example of a protocol that can be used at Networking Layer 106. However, IP is not required in a distributed computing environment. In addition to IP, other protocols can be used in a distributed computing environment. Network drivers such as Ethernet, Token Ring, and Bluetooth can also be part of the networking layer. Many small clients already have network drivers and transport protocols such as UDP / IP. So, when adding a thin XML-based messaging layer, devices can participate in a distributed computing environment. [0055]

So the basis of a distributed computing environment is a simple message communication layer implemented on top of trusted connections and / or untrusted datagrams. This messaging technology is quite different from the communication technology used in other distributed computing systems such as Jini, which employs Java Remote Method Invocation (RMI). Message communication layer 104 supports asynchronous style distributed programming that does not hold state, rather than synchronous style that holds state described in RMI. Further, the message communication layer 104 is based on a data expression language such as XML, and therefore, unlike RMI, it copies data from the copy source to the copy destination, but does not copy the code. Since Java code is not intended for message senders or recipients, messaging layer 104 can seamlessly achieve interoperability with non-Java and non-Jini platforms by using a representational data language such as XML. .. Moreover, unlike RMI, messaging layer 104 does not require a reliable transport mechanism such as TCP / IP. [0056]

The message communication layer can provide simple send () and receive () methods, for example, to send a message specified as an array of bytes or a string of bytes. The send () method returns immediately and the data transfer can be performed asynchronously. For flow control, you can provide a callback method that will be called if the send () method throws an exception indicating that it cannot handle the send () request. The receive () method is a synchronous method that returns the next available message. [0057]

This message communication layer can also include methods that store XML representations of objects, services, and content within "spaces." Spaces are named and accessed on the network using URIs (Uniform Resource Identifiers). The URI may be a URL (Uniform Resource Locator) or a simplified version of the URL. In some embodiments, the URL class may be too large. In such an embodiment, a simpler resource locator is used to specify the protocol, protocol-dependent host ID, protocol-dependent port ID, and space name used to move messages between the client and server. [0058] [0058]

You can add an XML representation of an object to a space using the write () method provided at the messaging layer. In one embodiment, a client-specified name and an object can be given as parameters. In one embodiment, the write method transforms an object into its XML representation. You can provide a take () method to return an object and remove it from the space. You can provide a find () method to return the specified object from the XML representation in the space. The find () method can also be used to return an array of matching objects in space given a class. Each of these space methods is implemented using the message communication layer. A leasing mechanism can also be provided as described below. [0059]

The discovery service can be provided to the client as a general search function that the client can use to find a particular space. Rather than trying to define a complex search protocol that thin clients may not be able to implement, the discovery service offloads the actual search to XML-based search functionality, and the discovery service provides the interface functionality to the client. Make it easy to provide. This approach is shown in Figure 4. In one embodiment, the discovery service receives a string that specifies what it identifies, sends an XML message to a known discovery front end (probably found in the default space), then parses the string to the search function. Execute the corresponding XML query (this may be the Internet search function). The discovery front end can parse what it receives from the search function, repackage it as an array of strings (each string is the URI of each space found), and send it to the client in an XML message. Note that the discovery service does not require messaging to be on top of the connection-oriented transport. Therefore, even very lightweight thin clients without TCP can use such discovery services. The discovery front end allows clients to discover spaces on the client without a browser or search function. The client only needs a simple function to send a string specifying the keyword to the front end that interfaces with the search function. [0060]

The client can be any platform that can send messages using at least a subset of the API and messaging layers. In one embodiment, the API layer can accommodate both static (or raw) and formatted (or cooked) messages. The server can be any platform that can receive and execute message requests. You can send an explicit raw message to move a byte sequence from a client to a server or to another client. The message type can be specified as a trusted message (eg TCP) or an untrusted message (eg UDP). The smallest of the devices use raw untrusted message communications as the sole means of participating in a distributed computing environment. The device uses these messages to announce its existence and status. Such a small device can also receive raw messages and perform some functions such as turning features on and off. [0061]

Message-based services such as spaces can send and receive trusted formatted messages. Space messages should be in a well-defined header format and use XML. In one embodiment, the formatted message causes the client to use the space method to request an object in space, write an object to space, or retrieve an object from space. The message content can be dynamically formatted in XML and has well-defined headers. Figure 5 shows a client profile that supports formatted static messages. Static messages allow smaller devices to participate in a distributed computing environment with a smaller profile of code. For example, a small device can only send basic pre-defined messages. Depending on the client, static predefined messages may occupy less memory (for example, less than 200 bytes). Static messages may also be an option for larger devices. Dynamic XML messages, on the other hand, are useful when object values are not known at compile time. [0062]

Figure 6 shows a distributed computing model that combines a messaging system with XML messages and XML object representations. The platform's independence from XML can be used to make the system compatible with heterogeneous distributed computing environments. Therefore, the client 110 can be implemented on almost any platform rather than a specific platform such as Java. Messaging systems can be implemented at the network-enabled messaging layer, such as Internet Protocols (eg TCP / IP and UDP / IP). Therefore, the computing environment can be distributed over the Internet. In one embodiment, the messaging system can also use shared memory as a fast interprocess message passing mechanism when clients and / or space servers and / or services are on the same computer system. .. The distributed computing model in Figure 6 is also highly scalable because it can be configured to allow clients of almost any size to send and / or receive XML messages. [0063]

As shown in Figure 6, the distributed computing model can run two types of software programs, service 112 and client 110. Service 112 can notify clients who want to use the service of its functionality. Service 112 announces the function in space 114. As shown in Figure 7, client 110 and service 112 may or may not reside within the same network device. For example, devices 120 and 124 each support one client, while service 112a and client 110b are implemented within the same device 122. Also, as shown in Figure 7, the device does not require a specific platform to support clients and services. For example, device 120 is Java-based and device 124 has a native code runtime environment. [0064]

A device is a unit that can be addressed by a networking transport. Examples of devices include, but are not limited to, PDAs, mobile phones, laptops, laptops, desktop computers, more powerful computer systems, and even supercomputers. Both clients and services can be URI-addressable instances of software (or firmware) running on the device. Clients run services using a distributed computing environment architecture. Space is a service that manages a repository of XML documents. Even if this is verbose, we use the term space service here for readability. Software components may be clients and services at different times. For example, when a service uses a space (for example, to notify itself), the service becomes a client of the space. [0065]

FIG. 8 shows a basic model of a distributed computing environment in one embodiment. This distributed computing environment connects clients 110 to services 112 throughout the network. The network may be a wide area network such as the Internet. The network can also be a combination of networks such as a local area network (LAN) connected to a wireless network via the Internet. As shown in Figure 8, service 112 publishes a notification 132 (represented in XML) to itself within space 114. Notification 132 specifies the XML schema and URI address of the service. The client 110 then looks up notification 132. Client 110 uses notification 132 to instantiate gate 130. At gate 130, client 110 executes (and receives) XML messages to (from) service 112 at service 112. [0066]

Part of the result of executing the service can be returned to the client as an XML message. However, because other results are too large for a small client to receive and consume at once, service 112 puts the XML representation of those results or result 134 in space 114, as shown in Figure 9. , Returns to client 110 by reference (by XML message) instead of returning by value. Examples of ways to return a reference to a result include, but are not limited to, returning a URI that references the result in a space in a message, or returning an XML document containing the result URI in a message. Later, the client 110 can access the result or pass the result to another service by reference. The space for storing the results may be different from the space in which the service is notified. [0067]

In one embodiment, the distributed computing environment uses XML to define, notify, and describe content. New content in a distributed computing environment (for example, messages and notifications) is defined in XML. Existing content types (for example, those developed for other environments) can also be described using XML as a level of indirectness (metadata). XML provides universal data in a manner similar to Java's provision of universal code, making it a powerful way to represent data throughout a distributed system. XML is a language-agnostic means and self-descriptive. XML content is strongly typed and can be validated using a schema. The system can ensure that only valid XML content is passed in the message when using the provided XML schema. XML content can also be converted to other content types such as HTML and WML. Therefore, even a client that does not recognize XML can use the services of the distributed computing environment as it is. [0068]

In one embodiment, messages in a distributed computing environment can define protocols used to connect clients to services and handle content in spaces and stores. Defining a protocol using messages allows different types of devices to participate in the protocol. Each device is free to implement the protocol in a way that best suits its capabilities and roles. For example, not all devices can support the Java runtime environment. The protocol definition of a distributed computing environment does not imply that Java should or will be used on the device. Nor is it excluded. [0069]

The functionality of a service can be represented with respect to the messages it accepts. The service message set can be defined using XML Schema. The XML message schema uses XML-typed tags to define each message format. Tag usage rules can also be defined in the schema. The message schema may be a component of XML notification along with the message endpoint of the service used to receive the message. In a distributed computing environment, clients can use all or some subsets of the functionality of a service. Adopt a security policy to enforce the feature set given to the client. For example, after giving a set of features to a client, the client cannot modify the set without proper approval. This feature definition model allows for service levels from basic feature sets to extended feature sets. Extensions can be added to the service by adding to the number of recognized messages. [0070]

In one embodiment, all operations within a distributed computing environment are implemented as XML messages sent between the client and the service. Storage (both temporary and continuous storage) providers are examples of services that allow clients and services to store, notify, and address content. Clients and services can use temporary storage space to find each other and broker content. The service places content or service notifications in the space. Notifications can be used to describe the functionality of a content type or service. The client then browses the space for notifications that match the desired feature set. When the client finds a matching notification, it establishes a communication channel to allow two-way message communication with the service that supports the notification. In one embodiment, the communication channel is authenticated. The result of the service's operation (which is just another content type) is returned directly to the client in a response message and either notified and stored in space, or notified in space but permanently stored. To. The stored result is handled using a URI (for example, returned in a response message) and is assigned the associated authentication certificate. [0071]

Message gate As mentioned above, a distributed computing environment uses a data description language such as XML. You can use XML to write a target entity (for example, a document, service, or client) and generate code to access that entity. The code generated to access the target entity is called the message gate. Thus, in one embodiment, this distributed computing environment can access an object or target XML description in this distributed computing environment instead of passing the required code between the objects needed to access other objects. It differs from other distributed computing environments in that it generates code based on XML descriptions to access the target in this way. In a distributed computing environment, XML Schema can be used to ensure a programming model (eg, supported messages) with type safety by XML Schema alone, without relying on language-specific APIs. it can. Code generated from XML Schema can also incorporate the language, security, type safety, and execution environment characteristics of the local platform. Therefore, the local platform controls the generated code to prevent bugs from entering and to generate only valid data according to the schema. The generated code fits into the client's code execution environment (eg Java, C ++, Smalltalk) as well as its management and security framework (web server and / or operating system). [0072]

Note that distributed computing environments do not require code generated from XML Schema to be generated "on the fly" at runtime. Instead, pre-generate some or all of the code for the service category (or class) and then link it during the platform build process. Pre-generation of code is useful for certain clients, such as embedded devices, where some XML schemas are already known. In one embodiment, some or all of the code may not actually be generated at all. In one embodiment, a private code loading method (in the client) can be used to reinforce the generation process. In addition, in some embodiments, an interface can be specified for downloading additional feature code when accessing services in a distributed computing environment (see, for example, Message Conductor below). Such code that is usually downloaded is small and the client has the option of downloading or not downloading the code. [0073]

The phrase "generated code" is generated within the client under the control of the client code execution environment or elsewhere (on the service system or space service system) and after generation. Refers to code that can be downloaded to the client system. However, the binding time is the execution time. At run time, the generated code is bound to a service address (URI) and a message is sent to an instance of that service. [0074]

As mentioned above, you can specify an interface to a service in a distributed computing environment with an XML schema and define a collection of messages that a client sends to (and receives from) that service. As shown in FIG. 10, the client 110 and the service 112 each construct a message gate 130 and communicate according to the specified XML schema. From the XML schema notified about service 112 (and possibly other information in service notifications), clients 110a or 110b can build message gates 130a or 130b, respectively. The corresponding message gate 130c generated from the same XML schema also exists on service 112a. Gate 130 is a message endpoint that can send and / or receive type-safe XML messages and that can verify the type correctness of XML messages when sending and / or receiving messages. Message Gate also supports authentication and / or other security mechanisms that ensure that message endpoints are secure. In one embodiment, the message gate is always secure. [0075]

The messaging layers of the distributed computing environment described above can be combined with or part of the gate. The messaging layer uses networking transport asynchronously to send a sequence of bytes from the sender to the receiver, where both the sender and the receiver have one atomic unit, or message. Maintain the concept. In a distributed computing environment, we do not make the assumption that networking transport is IP-based. Instead, the messaging layer is topped up no matter what networking transport layer is supported by the device. [0076]

The message gate can provide a mechanism for sending and receiving XML messages between the client and the service. XML messages can be "typed". For example, a message can be tagged to indicate whether the message data field is, for example, integer, floating point, text data, and so on. Message gates can be constructed to verify the type of messages sent or received. The Message Gate can also authenticate the sender of the received message (for example, using security features to identify it). An XML schema can be provided to the service that describes the set of messages accepted and / or sent by the service. The message gate verifies the correctness of the message sent or received according to the XML schema in which the gate was constructed. [0077]

Gates are built as a single atomic unit of code and data that performs type verification and / or message correctness verification and / or sender identification for messages between clients and services in a distributed computing environment. can do. In one embodiment, once an atomic unit of code and data for a message gate is created, it cannot be modified with respect to its typing, message descriptor, and sender identification. In other embodiments, the gate, after creation, can be modified with respect to the contents of the message schema, including deleting, adding, or modifying messages in the message schema. [0078]

A message gate is a message endpoint for a client or service in a distributed computing environment. The message gate has a secure message endpoint that sends and receives type-safe XML messages. Message gates allow clients and services to exchange XML messages in a secure and reliable manner with the appropriate message transport (eg HTTP). On the client, the message gate represents the right to use some or all of the functionality of the service. Each function can be represented by a message that can be sent to the service. Each such message can be sent through a client message gate that verifies the correctness of the message. To receive a message, use the service message gate to authenticate the message and verify its correctness. [0079]

The message gate can be equipped with a secure communication endpoint that performs type checking of XML messages. As described below, the message gate can also be equipped with a mechanism to limit the flow of messages between the client and the service. In one embodiment, when a client attempts to access a service, a client-service message gate pair is created, unless it already exists. In one embodiment, the service message gate is created when the service receives the first message from the client message gate. In one embodiment, one or more service message gates can be created at service initialization and used to pair with client message gates during creation. When creating a message gate, you may need an authentication service that negotiates the desired level of security and a set of messages that can be passed between the client and the service. In one embodiment, the authentication service describes a client ID token (also referred to as a client token), a service ID token (also referred to as a service token), and a set of data representation language messages that can be sent to or received from the service. Can accept data representation language message schemas. For example, you can write a message sent from a client to a service to call the service or to call some part of the service. You can also describe messages sent from the service, such as response messages and event notification messages. See the Authentication and Security section below for more information on how to use the Authentication Service to build and use MessageGates. [0080] [0080]

A client message gate and service message gate pair allows messages to be sent between the client and the service. In one embodiment, it is possible to create a message gate that only ships and / or receives a subset of the entire message set as described in the service's message schema. By taking advantage of these restricted access in a distributed computing environment, it is possible to enforce a minimum privileged policy that allows clients only access to specific individual message types based on security policies. it can. For more information on how to use gates and how to create gates, see the "Authentication and Security" section below. [0081]

The client gate and service gate use the protocol specified in the service notification (the URI of the service in the service notification) to actually send (and receive) the message from the client to the service. The client executes the service with this message passing. The message gate provides a level of abstraction between the client and the service. Clients can access the service object through the message gate instead of accessing the service object directly. The gate abstracts the service from the client, so you don't have to load and start the service code until the client first uses the service. [0082]

The client gate also performs message validation against the XML schema, or service gates against the XML schema, for example, if the client indicates that the message has not yet been validated. Can be done by. In some embodiments, validation is impractical for simple clients and may not be needed on the client side. In some embodiments, validation can be performed on the service side. The gate can also perform authentication enablement and / or security methods. In one embodiment, the correct gate may not be built if the client does not support the protocol specified in the service notification. To avoid this issue, service notifications (used to build gates) should be able to support a variety of clients, including a list of URIs available for the service. [0083]

The basic message gate can implement APIs for sending and receiving messages. This API moves data (for example, XML messages) to and from the gate and validates the messages before sending and / or after receiving them. In one embodiment, the message gate can support a defined minimum API for sending and receiving messages. As described below, this API can be extended to other features. As shown in Figure 10b, gate 130 can be generated according to XML Schema 132. The generated gate code validates the message based on the XML schema. This gate verifies that the message type and / or content is correct through the message API. As shown in Figure 10b, the validated message is sent to the service through the Message API. This message is received at the corresponding gate on the service side. In response to this message, the service can produce a result of 180. The service returns result data 182 through its gate. The result data is either the result itself or a reference to the result, such as a URI to the result stored in a space. In various embodiments, the message APIs are, for example, synchronous messages (request response), asynchronous messages (response is disconnected from the request), unicast messages (between two points), multicast messages (broadcast), and publish. And subscribe (event messages) can be supported. It can also support other types of messages, such as remote method call messages. [0084]

Each message sent by the gate can include a certificate of authentication for the receiving gate to authenticate the message. Each message also includes a token containing information for the receiving gate to verify that the message has not been compromised or altered. For example, the sender can calculate the hash or checksum of the message that the recipient validates. The sender can also use the sender's private key to encrypt this token and / or the entire message, allowing the recipient to verify that the token has not changed, including the public key that corresponds to the encrypted message. To do so. See the Authentication and Security section below for more information. [0085]

A pair of message gates provides a mechanism for communicating client-to-service requests and service-to-client responses. Two associated message gate endpoints can be used to create a secure bidirectional atomic message channel for request-response message communication. Therefore, in a distributed computing environment, the message gate employs a message transport that exists on both the client and service sides. The two gates work together to provide a secure and reliable message channel. [0086]

FIG. 11a shows a diagram of an embodiment showing that a gate 130a is constructed within the client 110 from a service notification or other service description 132. The client includes a gate factory 140, which is reliable code on the client that generates gates based on the XML service description. You can use Gate Factory 140 to ensure that the generated gate is also a trusted code and that the code is correct for service notifications. As shown in Figure 11b, gate 130c can also be built into service 112. The client gate 130a and the service gate 130c provide a message endpoint for communication between the client and the service. In one embodiment, the fragments required by the gate factory to build Gate 130 are the XML Schema of the service (from the service notification) and the URI of the service (from the service notification). In other embodiments, the service can further obtain an authentication certificate and use it in gate construction by executing the authentication service specified in the notification. [0087]

The gate factory has a reliable mechanism for creating message gates. In some embodiments, the code used to create the gate needs to be trusted code to ensure that the message gate is a trusted message endpoint. Gate Factory 140 can be a trusted package of code used to create gates. In one embodiment, each client and service device platform wishing to send and receive messages in a distributed computing environment comprises a gate factory. In some embodiments, the gate is pre-built by another gate factory so that the device with the pre-built gate does not need a complete gate factory, or the gate is You can have a partial gate factory that binds to a pre-built gate when you run the service URI and / or authentication certificate (for example, when message communication is required). [0088]

The gate factory for the device can generate gate code that incorporates the language, security, type safety, and / or execution environment characteristics of the local device platform. By building the gate itself, the device can verify that the generated gate code is bug-free, produces only valid data, and is type-safe. The advantage of generating your own gate code on the device instead of downloading the code to access the service is that you have control over the client code management environment. The generated code fits into the client's code execution environment (eg Java, C ++, Smalltalk) as well as its management and security framework (web server and / or operating system). The generated code is also reliable because the client's runtime environment was involved in the code creation. Therefore, trusted security information can also be added by trusted generated code. Therefore, the device can receive an XML message schema for the service and then build a gate based on that schema to access the device. XML Schema can be thought of as defining a contract with a service, and the generated gate code can be thought of as providing a secure means of executing that contract. Note that open devices running untrusted (for example, downloaded) code can only be configured to generate gates with trusted code. Open devices employ a process model in which the gate is contained in a protected and isolated code container that is inaccessible to tools, such as a gate implementation, especially a debugger that can discover the gate authentication certificate. be able to. [0089]

Gate Factory 140 negotiates with the service on behalf of the client and creates a gate for sending messages to the service. Similarly, a gate can be built with a service to receive a message from the client gate and send the message to the client gate. At the same time, the client and service gate can form a secure bidirectional communication channel. [0090]

The gate factory provides some level of abstraction when creating a gate. For example, if a client wants to use a service, the gate factory can create a gate as part of instantiating the service, instead of creating a gate for the client to access the service directly. [0091]

The gate factory can create or provide its own trusted message gate that is used to communicate with the authentication service (for example, specified by the service notification) to receive the authentication certificate for the gate it builds. For services with restricted access, gates can be built without an authentication certificate. Since the service does not restrict access, the gate of such a service may not need to send an authentication certificate with each message. The authentication service is, in one embodiment, an example of a service that does not restrict access. Therefore, the gate factory can be configured to optimize gate construction by checking if the service restricts access. If the service does not restrict access, the gate factory can circumvent the execution of the authentication service as part of the gate construction, and can circumvent the incorporated provisions for the authentication certificate as part of the constructed gate. The gate factory can also receive or download an XML message schema (for example, specified by a service notification) and create a gate that matches that schema. The gate factory can also receive or download the URI for the service and / or service message gate used to create the client message gate that communicates with the URI. [0092]

In addition, different gate building optimizations can be adopted for some clients who do not want to perform message checking against the service's XML schema. The client may be too lightweight to perform the check, rely on the service gate to perform the check, or simply do not choose to perform the check (for example, to reduce the gate memory footprint). .. You can configure the gate factory to receive an indication as to whether to build a gate to validate the message against the provided XML schema. In some embodiments, some clients may include a gate factory that does not have the ability to validate messages against the schema of the constructed gate. In some embodiments, the gate is pre-built so that the message is not validated. In some embodiments, the gate can be constructed to validate only the outgoing message or only the received message. Thus, in some embodiments, the client may choose to avoid or avoid building some or all of the gate code that checks the message against the XML schema. [0093]

In some embodiments, the device can maintain a cache of gates to avoid building each time the same service is executed. For example, when a new gate is built by the gate factory, gate the gate can be kept in the cache . When the gate is no longer in use, keep it in the gate cache instead of deleting it. When the gate cache is full, one or more gates can be removed from the gate cache according to a cache replacement algorithm, such as an algorithm that expels the least recently used data. When a gate factory is called to build a gate, the gate factory first checks the gate cache to see if a matching gate already exists so that it can avoid building a new gate. [0094]

Gate construction can be made lighter by properly reusing the fragments used to build other gates. Some parts of each gate can be the same and can be reused from gate to gate, such as part of the message validation code. In addition, for some devices, the common gate code can be embedded in the device's system software and shared with all gates on that device. Therefore, the gate factory can avoid rebuilding this common code for each gate. Instead, the gate factory can simply bind the gate to this part of the system software. For example, you can have a part of the system software that can handle the message layer no matter what transport is provided to the device. [0095]

In particular, space services are opposed to many of the gate building optimizations mentioned above, because the service gate built for the space service can perform the same many functions as the other service gates for that space service. It can be said that it is an appropriate candidate. For more information on space services, see the "Spaces" section below. [0096]

In some cases, there may be a more efficient method call format. For example, if the target service runs in the same Java virtual machine as the client application, a more efficient method call format is to create a Java Dynamic Proxy Class for the service. In such cases, calling java.lang.reflect.Method may be faster than sending a message. The gate bind time procedure checks for such optimizations and uses it instead of running a gate factory to create a gate or bind an existing gate. [0097]

In one embodiment, run-time gate code generation may not be desirable in terms of memory consumption and code generation time, such as in the case of dedicated clients or small embedded devices. Therefore, instead of providing a gate factory that creates a gate at run time, in some embodiments the gate is pre-generated and incorporated into the device. For example, when building embedded software, you can generate a message gate as a means of including a built-in secure message endpoint that you do not have to build at run time. Therefore, a client with a built-in gate does not need a full gate factory or has a partial gate to perform some kind of run-time binding to the built-in gate, such as a URI and / or authentication certificate. Only the factory is needed. [0098]

A generation tool can be prepared for pre-building the gate. The gate generation tool includes an XML parser, a code generator, and a code compiler. In one embodiment, the code generator is a Java source code generator and the code compiler is a Java code compiler. When building software for which a built-in message gate is desired, the generation tool runs with input from all relevant XML schemas for which a gate is desired. [0099]

For example, if it is desirable for the device to have a built-in message gate that can send and receive messages to and from the digital camera, building the device software is the task of running the gate generation tool with the camera's XML message schema as input. including. The XML schema can be parsed by an XML parser that transforms the XML schema into an internal format suitable for fast access in the message validation process. The tool's code generator can provide the source code for the gate that corresponds to the camera's schema. In some embodiments, the generation tool further compiles the source code and the gate code can be linked to the device's software package. At runtime, you can discover camera services in a distributed computing environment. The camera service message URI can be bound to the camera's built-in gate within the device. The binding of the URI to the pre-built gate is done by the gate constructor in the device. This gate constructor is a fairly small, simple gate factory. When the camera service is instantiated, the camera service URI is passed to the gate constructor as an XML message. The gate constructor then binds the URI to the pre-built gate. [0100]

Therefore, the gate is partially or completely generated at run time, or the gate is pregenerated before run time in a binding process (eg, URI or certificate) that runs at run time. In one embodiment, a gate generation tool such as a gate factory or a pre-built gate generation tool can be a Java-based tool that achieves a level of platform independence. Apart from that, gate generation tools can be provided in any language, such as native code for a particular device in a distributed computing environment. Note that in a distributed computing environment, the device cannot download some or all of the gate code. For example, in some embodiments, the service provides a gate code that can be downloaded by a client wishing to access the service. However, the downloaded code may indicate a size, security, and / or safety risk. [0101]

A detailed diagram of a possible gate component of an embodiment is shown in FIG. The gate has its address (or name) 150, destination gate address 152, valid XML schema (or internal format) 154, and transport URI. It can be equipped with 153. In other embodiments, the gate may include certificate 156. Some gates are also equipped with a lease 158 and / or a message conductor 160 to verify message ordering. The gate name 150 can be a unique ID that only references the gate (during the life of the gate). The gate can be addressed using the gate name 150. In one embodiment, the gate name can be generated as a combination of an XML Schema string (eg, a string from a service notification) and a random number, such as a 128-bit random number. When using name 150, clients and services can migrate with respect to the network and work together as-is. In a preferred embodiment, the gate address is independent of the physical message transport address and / or socket layer. Therefore, the gate name can give a virtual message endpoint address that can be bound and unbind to the message transport address. In one embodiment, the name of the gate may be a Universal Unique Identifier (UUID) that only references the gate for the life of the gate. [0102]

The gate name survives as long as the gate survives, allowing different applications and clients running within the same device to repeatedly find and use a particular gate. For example, you can create a gate for the first client process running inside the device to access the service. Release the gate after the first client process completes its activity on the service. The task of releasing the gate requires unbinding the gate to the message transport address (for example, IP and / or port address) of the first client process. Gates can be stored in the gate cache or repository. A second client process running within the same device that needs to run the same service identifies the gate by name and uses that gate to access the service. To use a gate, the second client process binds the gate to its message transport address, and the message endpoint for the second client process is the gate name and the transformer of the second client process. Make it a combination with the port address. In other embodiments, the client can receive a dynamic IP address (for example, a mobile client). When the client's transport address changes, the gate name (s) is rebound to the client's new transport address, leaving the client as is without relocating the service and recreating the gate. You can access services that you have already accessed. The gate name can also be used for process migration. Processes and related gates can be checkedpointed or saved to one node in a distributed computing environment and moved to another node. Restart the process on a new node and bind the associated gate to the transport address on that new node Then, the process can directly access the external service that was the access destination before the migration. A gate can track the current location of other gates that it is paired with. Therefore, even if the service or client is migrated, it can be accessed as it is. For example, a replication or load-balanced service implementation can be abstracted from a service client by a gate. Therefore, the gate name 150 provides a flexible mechanism for addressing message endpoints in a distributed computing environment. Gate names can be used to identify and / or address gates on a variety of networks, from local networks to the Internet. The gate name is independent of the message transport and is transported by unbinding and rebinding to a different transport address (for example, IP / port address pair) on which the message endpoint (gate) is based. Can be moved from to transport. [0103]

In one embodiment, the gate can be further separated from the service and the same gate can be used to send requests to different services over time. This requires unbinding the gate's destination gate address 152 and binding a new destination gate address to the gate. [0104]

The gate can be implemented as a layer above the transport layer of the device (for example, a networking socket). Each gate contains a transport reference 153. The gate name 150 is bound to transport reference 153 as described above. Multiple gates can share the same message transport. For example, multiple gates can have a transport reference 153 to the same TGP / IP socket. By sharing the same message transport, the size and complexity of each gate can be reduced. Devices in a distributed computing environment may require more gates to send and receive messages. The complexity of message processing for multiple gates is reduced by sharing a common message transport. Transport reference 153 is a transport URI (eg, URL) or socket reference that can name the underlying transport and provide a mechanism for sharing that transport with other gates. Multiple local gates contain a reference 153 to the same transport, but each local gate operates independently of the other local gates that send and receive messages to and from the pair of remote gates. [0105]

Schema 154 can be downloaded from space into the gate by the gate factory. The schema can be compiled into an internal format suitable for quick access during the message validation process. In one embodiment, the schema can specify two groups of messages: client service messages and provider service messages. The client service message group contains a description of all the messages that the client can send (supported by the provider), and the provider service message group is all that the provider can send (receive by the client). Includes a description of the message. In one embodiment, either the client or the provider sends a particular request to the space service, the entire client service message, the entire provider service message, the entire client and provider service message, or the client service. · Get a response message along with one of the specific messages, either a message or a provider service message. In addition, after the gate is built, the client can query the functionality of the service without the gate actually sending a message, but instead by inspecting the gate's set of messages. .. [0106]

As mentioned above, the message gate can validate the message content for type safety, the sender of the message using the certificate, according to the XML schema. However, it is desirable to verify that the messages are sent in the correct order between the client and the service. It is desirable to be able to provide an application (service) for a client that runs without certain existing functionality related to the application on the client (for example, if the application on the client does not have a GUI). For example, you can use a web browser on the client as the service GUI and not use the application-specific GUI. Of the possible messages in the XML Schema, the client needs to know which message to send to the service next. It is desirable for the client to be able to determine the next message to send without specific information about the service. In one embodiment, the service can continuously send a response message indicating the required next input. The service then only accepts the corresponding message from the client for which request input is specified. Other ad hoc methods for message ordering can also be adopted. [0107]

In other embodiments, the message conductor 160 is employed in the gate, as opposed to verifying the syntax of each message (which may already be running in the gate according to the schema). You can associate it with a gate and verify the correct order of messages. Message Conductor 160 can take a more general approach to the preparation of applications. The message conductor 160 can be specified in the service notification. The message conductor instructions in the schema can be generated on the client or downloaded to the client during gate construction and provide the choreograph needed to determine the next message to send to the service. Message conductors can be implemented as Java applications, Java Script, and WML scripts, or in other programming or scripting languages. [0108]

In one embodiment, the message conductor can accept the input as an XML document (eg, from a service notification) that displays the valid order of messages or choreographs that can be sent between the client and the service. This XML document can also specify user interface information and other rules. The conductor parses this XML document, puts it in an internal format, and enforces message ordering (and / or other rules) according to the enclosing ordering information. The conductor can prevent the messages from being out of order. Alternatively, if the messages are out of order, an exception can be raised within the shipping device. If the messages are received out of order, the conductor sends an autoresponder message declaring an ordering error. The sender can now resend the messages in the correct order. Note that in some embodiments, some or all of the conductor can be shared by multiple gates. Therefore, the conductor can be linked to a plurality of gates. [0109]

In one embodiment of a distributed computing environment, a service front end (service interface) can be incorporated into the client. In one embodiment, the service interface can be a pre-built user interface provided by the service to the client. In one embodiment, a service interface can be provided to the client with a service notification. The service interface can interact with the user of the service on the client, get the input to run the service, and display the result of running the service to the client. The "user" can be a human being, an embedded system, another client or service, and so on. In one embodiment, the client device can only run services that incorporate the front end and may not be able to provide any services. In one embodiment, the service interface of the service can be implemented in a web browser on the client. [0110]

In one embodiment, the message conductor and / or service interface may be outside the gate and can therefore be abstracted from the gate and client. The abstract message conductor can provide any service to any client device. In one embodiment, the message conductor can be written in code that can be executed on virtually any platform. In one embodiment, the message conductor is written in the Java language. In one embodiment, the message conductor does not require any download of the object, eg, a Java object, returned to the client device. For example, if it returns a very large object, the message conductor may choose not to download such a very large object. In one embodiment, the message conductor can send an XML message from the client device to the service on behalf of the client. The message conductor can interact with the user of the service to receive input and display the results. [0111]

In one embodiment, a service interface is provided that interacts with a client (eg, through a user interface) to obtain all information for executing a service, thereby providing the result or result of executing the service. Any of the information about the location can be displayed as appropriate. The service interface may be part of the Message Conductor 160 or may be associated with it in addition to the Message Conductor 160. The service interface is one of the following: 1. Built into the client device and run on the client. 2. Downloaded from the space server to the client device. 3. Runs on the space server. 4. Run on the service provider. [0112]

In one embodiment, to the client, the space server in the distributed computing environment always supports # 1 and indicates if # 2 is supported (with a notification in the space), # 3 and # You need to indicate that at least one of the four is supported. Note that support for # 4 depends on the service provider's support for # 4. In one embodiment, it is necessary to indicate to the service provider that the space server in the distributed computing environment always supports # 4, and if it supports # 3, that is the case. [0113]

No matter where the service interface runs, after the service is activated, the service interface interacts with the client, displaying the request for input (remotely) on the client's display, and displaying the service execution result (remotely). Can be displayed. Such interactions with the client are implemented as XML messages. Such service interfaces and / or message conductors meet the needs of client users who have discovered the service but usually do not want to read the mostly dry computer manuals to know how to use the service. When the service interface and / or message conductor interacts with the user to request all the input required by the service, it can even provide a short description of the requested input if requested by the user. .. After the service interface gets the required information from the client, it sends an XML message to the service provider running the service. The order of the messages is verified by the message conductor 160 in the gate. [0114]

In a preferred embodiment, all messages flow through the gate. The gate can be configured to provide a flow control mechanism. For example, the service needs to handle a large number of incoming and outgoing messages. Flow control allows services to keep up with high traffic volumes. Gates can be configured to monitor messages for flow control tags. When the gate receives the message, the gate looks at the flow control tag for that message. The flow control tag can be an XML tag. For example, the message can contain either an OFF tag or an ON tag. If the received message contains an OFF tag, the receiving gate will stop sending messages to the pair's destination gate. When the gate receives the message containing the ON tag, it resumes sending the message. [0115]

Therefore, the service-side gate monitors the usage of the resource and activates flow control when the usage of the resource exceeds the threshold value. For example, the service can reduce the load by sending a message containing an OFF tag to one or more client gates. The client gate that receives the message containing the OFF tag stops sending the message to the service. Pending messages in the client can be buffered or processed by an internal flow control mechanism. When the service is able to process further requests, it sends a message to one or more clients that contain an ON tag, and the client resumes sending messages. In other embodiments, other flow control tags may be supported in addition to ON and OFF, or instead of ON and OFF. Other flow control tags can indicate a reduction in message flow or increase that message flow. [0116]

The message gate can be configured to perform resource monitoring. For example, all messages flow through the gate, so the gate can be configured to manage and / or track how clients use services (and possibly related resources such as memory and threads). it can. Gates can be configured to track the activity of software programs such as clients by monitoring how much resources such as services are being used and how much of which service resources are being used. In one embodiment, the gate either generates a client activity log or makes it easy to generate a client activity log. Each message and its destination or sender can be logged. [0117]

In addition, the gate can be configured to perform resource monitoring for flow control from the local (shipping) side of the gate pair. If the client exceeds the bandwidth of the allocated service (or resource) usage, for example, the gate will automatically throttle the message flow. Therefore, the client-side message gate can automatically activate different flow control modes by monitoring the flow of outgoing messages. If the outgoing message flow exceeds the threshold, the gate reduces or blocks the outgoing message flow. You can specify thresholds in the service's XML schema or notifications. In some embodiments, the threshold can be specified for only or for all messages that use a particular service resource. [0118]

The gate can also be configured to determine if the message flow is increasing or resuming. In one embodiment, the gate can keep a count of outgoing messages sent without receiving a matching reply. When a matching response arrives at the client-side gate, reduce the count of outstanding request messages. When this count drops below the specified threshold for outstanding request messages, the gate can either add new request messages or resume their shipment. [0119]

The gate can be configured to support message-based billing capabilities. A billing system can be implemented based on the number and / or type of messages sent and / or received at the message gate. All messages sent to and from the client go through the gate, so you can configure the gate so that you can easily charge the client for service usage, for example, on a per-message basis or in a "pay-as-you-go" approach. it can. Thus, for example, a billing system in which software running on behalf of a user can charge the user for sending and / or receiving messages can be implemented in a distributed computing environment. [0120]

In one embodiment, the message gate receives billing information from an XML schema, for example, with respect to the service. The billing information can represent a billing policy and a chargeback URI. The chargeback URI is used when the message gate charges on behalf of the user on an hourly or usage basis. The message gate performs chargeback by sending a billing message to the chargeback URI specified in the XML schema. A gate configured in this way is called a billing gate. The billing policy indicates the billing amount per message or the billing amount for the total cumulative messages. Billing policies indicate how and / or how often users are charged (for example, after sending and / or receiving x messages). This policy indicates that only certain types of messages will incur charges and that the service resources specified by such messages will be requested. Billing policies may also present different billing models for different clients or classes of clients. For example, you can configure a billing policy (for example, in the service's XML Schema) to pay for a one-time charge when some clients create a gate to access the service. The policy may indicate clients that pay instantly (for example, per message), or it may indicate clients that are not charged at all. [0121]

In some embodiments, the client may be too lightweight to support a complete gate, or the client may not be able to embed software to directly participate in a distributed computing environment. In such an embodiment, the server (such as a space server or other server to which the service is notified) can be a full or partial proxy gate to that client. The server instantiates a service agent (which may include a gate) for each service used by the client. The service agent confirms the permission to send the message, sends the message to the provider, and in some cases queues it until the provider is ready to accept the next message and sends the message to the client. , In some cases, you can queue the client until it accepts the next message and manage the work of storing the results in the results or active space. See the "Bridge" section. For example, as shown in FIG. 13, the client can be a traditional browser 400 that does not support the gate to directly participate in the messaging scheme described above. Browser 400 is assisted by Proxy Servlet (Agent) 402. Browser users can use search engines to find web pages that are in front of (and display their contents) space notification services in a distributed computing environment. Users can point to and click on a web page in the space to access the service with the help of a Servlet. Web pages can contain scripts, such as Java and WML scripts, which are used to connect the browser to the proxy Servlet. You can also use a script to send a message to a proxy Servlet. Servlet agent is a browser client Translate web page actions into messages on behalf of Ant. These actions include navigating spaces, launching services, and returning results. The result page URI (referring to the page containing the XML) is returned directly (or converted to HTML or WAP if necessary) to the browser and displayed to the user. Therefore, the browser-based client does not need to know how to start the service, nor does it need to know the message sent during the service usage session. For example, a WAP browser user (for example, on a mobile phone) can connect to a space page, browse its content (service), launch a service, but all can be pointed and clicked. Agent 402 provides a client interface between a traditional client and a distributed computing environment. [0122]

A distributed computing environment can include several types of message gates for communication between clients and services that support different functions. For example, as mentioned above, some gates support flow control or billing functions. Other types of message gates support certain forms of remote method invocation. This type of gate is called a method gate. [0123]

A gate is a secure message endpoint that sends and receives type-safe messages, such as XML messages. Remote method invocation (RMI) style gates are called method gates. The direct data center gate is called the message gate. The method gate can be implemented as a "layer" above the message gate. The exact implementation can be defined in the platform bindings. [0124]

Figure 14 shows how to use a method gate to provide a remote method invocation interface to a service. The method gate provides a method interface between the client and the service. Method gates can be bidirectional, allowing client-to-service and service-to-client remote method calls. Method gate 172 can be generated from XML Schema information 170 (for example, from a service notification in a space). XML Schema Information 170 contains XML that defines the method interface. From this information, the code for the interface with one or more methods can be generated as part of the gate. Each method in the generated code can be called (for example, from client application 176) to send a message to the service containing the marshalled method parameters. Specify the syntax and parameters of the included message in the XML schema. Therefore, method gate 172 provides an XML message interface that calls service methods remotely. The method gate can be spawned on the client or proxied to a server such as a space server or special gateway server in which the service method is notified. [0125]

A service can implement an object method set that corresponds to a method message set defined in the service's XML Schema, or can have a corresponding method gate linked to it. There is a one-to-one correspondence between the object methods implemented or linked by the service's method gate and the method messages defined by the service's XML Schema. When the corresponding method of the service receives a message from the client and calls one of the methods of the service, the method gate of the service unmarshalls or unpacks the parameters of the message call, calls the method indicated by the received message, and unmarshalls it. Pass the marshalled parameters. [0126]

The method gate provides a synchronous request-response message interface that clients can use to remotely call methods and the service to return results. The underlying message passing mechanism is completely hidden from the client. This form of remote method call can process the result of the method as follows: In one embodiment, instead of downloading the result object (and associated class) to the client, only the result reference is returned in an XML message. Object reference 178 is a generated code proxy (eg, result gate) that represents the actual object result 180 (eg, stored as-is on the net). In other embodiments, the client may choose to receive the actual result object. In addition, after the client receives a result object reference, the client can use this reference to receive and manipulate the actual result object. In one embodiment, the result reference includes one or more URIs to the actual result. [0127]

The actual result object is stored in the service result space (which can be dynamically created by a Servlet, for example). This temporary result space can serve as a query result cache. Server software (garbage collector) that cleans up the old result area crawls through the result cache (space). The result returned for each method call is reported in the result space. The client may be a method that can remotely instantiate the result itself and generate its own method gate, or it may include such a method. Therefore, recursive remote methods can be called and supported in a distributed computing environment. [0128]

As mentioned above, when a client calls a service method remotely using a method gate, the service method gate returns a reference to the method result instead of the actual result. From this reference, generate a result gate to access the actual result. Therefore, the client or client method gate receives the result URI, and possibly the result XML schema and / or authentication certificate, which is used to build the gate and access the remote method results. [0129]

In one embodiment, the service gate creates a "child gate" for the result. This child result gate can share the same authentication certificate as the parent gate. In some embodiments, the result has a different set of permissions and therefore does not share the same authentication certificate as its parent. For example, a payroll service allows different groups of users to activate it to read the results (payroll) of a payroll service. [0130]

The service method gate returns the child result gate as the result of the method to the client gate. The client then uses the result gate to access the actual result. In one embodiment, the software program (client) that receives the result gate cannot distinguish between the result gate and the result itself, in which case the result gate becomes an object proxy for the actual result object. The result gate can also be a method gate that supports remote method calls to the result object. In this way, you can create a chain of parent-child method / result gates. [0131]

In one embodiment, the message gate and remote method are written in Java. In this embodiment, the method result is correctly input according to the Java input system. If you call the Java method remotely as described above, the result gate can be cast to a Java type that matches the result type. In this embodiment, method gates can be used in a distributed computing environment to allow remote Java objects to act as local Java objects. Method calls and results are displayed in the same way as Java software programs, regardless of whether the actual object is local or remote. See the Space section below for more information on using space for results. [0132]

Message Gate also supports publishing and subscribing message communications for events. A message gate with event support is called an event gate. The service's XML schema represents a collection of one or more events published by the service. Event gates can be constructed from XML Schema. The event gate can be configured to recognize some or all of the collection of events published by the service, subscribe to those events, and distribute each event along with what is generated by the service. [0133]

A collection of events for a service can be described in the service's XML message schema. For each event message in the XML Schema, the event gate subscribes as a consumer of that event. In one embodiment, the event gate subscribes to all events represented by the XML Schema. Name each event message using XML tags. The event gate can subscribe by sending a subscribe message containing the XML tag of the event to which it subscribes. [0134]

When a corresponding event occurs on a service, the service sends an event message to the subscriber to signal that the event has occurred. The event message contains an XML event document, and this message is sent to each subscribed gate. When the subscribed gate receives the event message, the XML event document is removed from the message and the distribution process begins. Event distribution is the process of distributing event documents within the client platform. Each event consumer within the client platform can subscribe to the event gate for each type of event. On the Java platform, the input system is Java (converted from XML event types). The event consumer supplies the event handler callback method to the event gate. The event gate stores a list of these subscribes. When each event message reaches the gate (from the service that raised the event), the gate traverses the list of client consumers, calls each handler method, and passes the XML event document as a parameter. In one embodiment, the XML event document is the only parameter passed to the handler callback method. [0135]

In one embodiment, the event gate automatically subscribes to the event for local consumer clients. When the client registers the interest with the gate, the gate registers the interest with the event producer service. The client also unsubscribes from the interest, which causes the gate to unsubscribe from the service that generates the event. [0136]

Event gates use XML Schema to typecheck event documents in exactly the same way that regular message gates do in the standard request-response message communication style described above. The event gate can also include the certificate in the message sent and validate the certificate in the event message received. [0137]

Note that the above combination of gate functions is supported by a single gate. Each type has been described separately for clarity. For example, gates are message gates, method gates, and event gates that support flow control and resource monitoring. [0138]

Service discovery mechanism In one embodiment, the distributed computing environment comprises a service discovery mechanism that provides a means for a client to find a service and negotiate authority to use some or all of the functionality of the service. Note that space is an example of a service. The service discovery mechanism is secure and can track outbound client requests and match incoming service responses. [0139]

The service discovery mechanism is not limited to them, but can provide various functions such as the following. The ability to find services using flexible search criteria, the ability to communicate to clients the right to use the entire feature set of services or a subset thereof, authorization mechanisms such as requesting authentication certificates, the ability to ask clients for services Some include the ability to request certificates, documents, or other objects to convey the interface. In one embodiment, the interface of the service can include an interface with a requested set of functions of the service. [0140]

Discovery tracking responds to the first request. In one embodiment, each client request contains a set of data returned in a matching response, and the request-response correlation can be determined. [0141]

In one embodiment of a distributed computing environment, the service discovery mechanism can provide flexible search criteria based on an extensible grammar. In one embodiment, the service name, service type, and other elements to be searched can be matched with the elements in the XML document. In one embodiment, the XML document is a service notification to the service. XML provides a flexible and extensible grammar for searching. XML also has the characteristic of being type-safe for matching elements. In one embodiment, the service name and service type can be type checked against the element type of the XML service notification. [0142]

In one embodiment, the distributed computing environment can provide a mechanism for clients to negotiate service access rights. In one embodiment, this mechanism can be used to negotiate a subset of the full functionality of the service. The result of the negotiation is approval, such as an authorization certificate, that conveys to the client the authority to use the requested subset of the service's capabilities. [0143]

In one embodiment, when using the service discovery mechanism, the client can request a security capability certificate from the service. In one embodiment, the client can present the service with the desired set of features in the form of secure notifications. The service, on the other hand, can respond with a certificate of competence that can convey to the client the authority to use the requested functionality described in the protected notification. [0144]

In one embodiment, a distributed computing environment is a security certificate that a client can use to negotiate service access privileges and then present the service's access interface to a set or subset of service features requested by the client. It can be equipped with a mechanism for retrieving books or documents. [0145]

In one embodiment, the client receiving the certificate of competence from the service can generate a custom service access interface document called "full notification". In one embodiment, the full notification is an XML document. The generated notifications can be used to access the service features allowed to the client by the certificate of competence received. In one embodiment, the notification provides an interface only for service functions that the client has been granted access by a capability certificate. In one embodiment, the client can be granted access with access privileges only for the required functions. [0146]

In one embodiment, the distributed computing environment can provide a mechanism for clients to negotiate services and features. In one embodiment, the client can negotiate features for the service. The service then customizes the results based on the parameters negotiated with the client. For example, a client capable of 1-bit display at 160x200 resolution negotiates those parameters with the service, which allows the service to customize the results for the client. [0147]

The following is an example of an XML functional message, but it is not intended to be restricted in any way. <type name = "Capabilities"> <element name = "display" type = "string" /> <element name = "memory" type = "string" /> <element name = "mime" type = "string" /> .... </ type> [0148]

A distributed computing environment provides a mechanism that allows clients to negotiate how a service returns the result of a service call. In one embodiment, the service can be informed of a means of selecting one of the results return methods when a capability certification request is made. The service then generates a custom service notification to the client that can convey the outcome mechanism to use, as well as the service interface. [0149]

In one embodiment, the distributed computing environment comprises a mechanism for tracking service discovery search requests and responses to requests. In one embodiment, search request and response messages include a field that can be used to include a string or XML document. In one embodiment, the string or XML document contained in the request message field is also returned in the response message. In one embodiment, the string or XML document should be returned in a response message. In one embodiment, the string or XML document can contain additional information that is inserted or added within the string or document when returned in a response message. In one embodiment, this mechanism can be used for debugging complex systems. In one embodiment, the mechanism further selects services to access by using strings or XML documents to pass custom search information between the client and service that only the client and service can understand. A method can be provided for. [0150]

Component (service) interface matching A distributed computing environment can include a mechanism for matching a component (eg, service) specification interface with a requested interface. For example, a client (which may be a service) may need a service that meets a set of interface requirements. Each component contains a description of the interface to which it fits. The specification interface matching mechanism allows you to place components that best match the requester's interface requirements. The specification interface matching mechanism can also perform "fuzzy" matching of interface requirements. This means that you can use this mechanism to perform matching without having to specify exactly all aspects of the interface, and you can implement a recent matching (fuzzy) mechanism. In one embodiment, the specification interface matching mechanism can be implemented as a multi-level subclassing model that does not require specifications at a single interlaced level. [0151]

In one embodiment, the component can describe its interface using XML Schema Definition Language (XSDL). XSDL enables a human-interpretable language that describes interfaces and simplifies activities that require human intervention, such as debugging. In one embodiment, the interface description can be provided as part of a notification (eg, a service notification) as described elsewhere in this document. [0152]

A specification interface matching mechanism can be used to compare a basic desirable interface with a set of interface descriptions for a component. One or more components are identified that match the basic desired interface. The interface description includes a subclass description that more specifically describes the interface provided by the component. The search process can examine the class type hierarchy to determine if a given class is a subclass of the search type. In one embodiment, the subclass inherits the properties of the base class. Subclass-specific information cannot be examined during this phase. Therefore, it can be said that the search is generally executed. The identified components can be searched at the next (subclass) level. The search is specific to the subclass and can be performed by interpreting the subclass information contained in the interface description. The search continues for one or more subclasses until it finds one or more components that have recently matched the interface desired by the requester. [0153]

In one embodiment, the interface matching mechanism comprises the ability to distinguish between two or more components that implement similar interfaces. In one embodiment, the interface matching mechanism comprises the ability to distinguish between different revisions of the same component. [0154]

In one embodiment, a component description can be presented that includes the specifications of the interface to which the component applies. The component description can also include information about the component itself. Interface descriptions and / or component information can be used to distinguish between different implementations of a given interface. The component description can contain standard identifiers and version information. Version information can be used to distinguish between component revisions. In one embodiment, the component description may be provided as part of a notification (eg, a service notification) as described elsewhere in this document. [0155]

In one embodiment, the component is searched for a particular standard identifier. It can identify two or more components with matching standard identifiers. You can select one or more components from the components that have matching standard identifiers. The selection procedure uses the interface specification version, component implementation specification, component implementation specification version, and other information or combination of information from the component description to best match the requester's requirements with one or more collections of components. Can be output. [0156]

space As mentioned above, distributed computing environments are space-dependent and have a rendezvous mechanism that mediates services or content to clients. FIG. 15 shows the basic usage of space 114. The service provider can notify the service in space 114. Client 110 finds the notification in space 114, uses the information from the notification, and leverages the XML messaging mechanism of the distributed computing environment to access the service. There are many spaces, each containing an XML notification that describes the service or content. Thus, a space can be thought of as a repository of XML notifications for services and / or XML data, which can be raw data such as results or notifications of data. [0157]

The space itself is a service. Like a service, a space has a notification, and the space's clients must first get it to run the space service. Space self-notification can include an XML schema, one or more certificates, and a URI that indicates how to access the space. Clients can build gates from space service notifications to access the space. A space's client is itself a service provider that seeks to notify or modify existing notifications within that space. Alternatively, the space client is an application that seeks access to the services or content listed by the space. Therefore, space acts as a catalyst for dialogue between clients and services in a distributed computing environment. [0158]

A space is a collection of named notifications. In one embodiment, the task of naming a notification is the process of associating a name string with the notification. This association occurs after storing the notification in space. Removing the notification from the space breaks the association between the name and the notification. Spaces can be created with a single route notification that describes the space itself. Additional notifications can be added to the space. The name of the notification can identify the notification in the space, including the operation of specifying the required graphing information, such as the name hierarchy. In a preferred embodiment, the distributed computing environment does not define the structure of the space. That is, for example, a space is structured as a flat collection of unrelated notifications or a graph of related notifications (eg, a commercial database). In a preferred embodiment, the distributed computing environment does not specify how the space actually stores its contents, so that it can support spaces from small to large devices. For example, a simple space can be tweaked to fit on a small device such as a PDA. More advanced spaces can be implemented on large servers that employ large commercial databases. [0159]

As mentioned above, the space can contain service notifications in a distributed computing environment. Notifications provide a mechanism for addressing and accessing services and / or content within a distributed computing environment. The notification allows you to specify the URI of the service. In some embodiments, URIs allow access to services on the Internet. The notification may also include the XML schema of the service. XML Schema allows you to specify a set of messages that a service client sends to the service to call the service's functionality. XML Schema defines a client service interface. At the same time, the XML specified in the URI and notification specifies the address of the service and dictates how to access the service. Both the URI and schema are XML and are provided as notifications in spaces. Therefore, it is possible to specify the address of the service in the distributed computing environment and expose the mechanism for accessing the service as a notification in the space. The client discovers the space and looks up individual notifications about the service or content. [0160]

FIG. 16 shows a notification structure according to one embodiment. Notification 500, like other XML documents, can include a set of hierarchically arranged elements 502. Each element 502 contains data or additional elements. The element also has attribute 504. The attribute is a name-value string pair. Attributes store metadata, which makes it easy to describe the data within an element. [0161]

In some embodiments, the notifications may exist in different states. One such state is the draft state. In one embodiment, the notification is first constructed in a draft state that is outside the space. Notification authors can build it in a variety of ways, including using an XML editor. Access to drafted elements and attributes is done at the raw and metadata levels using appropriate means. Normally, no event is fired for changes made to notifications in draft state. Therefore, notification authors are free to add, modify, or delete elements, as well as publish notifications for the rest of the distributed computing environment to prepare and review the desired set of attributes. [0162]

In one embodiment, another possible state for notification is the publish state. Notifications transition to the published state when inserted into a space. Once the notification is inside the space, the associated client and service can identify it, for example, using the name and / or its elements as search criteria. For example, the search criteria can be specified as an XML template document that can be compared with notifications in spaces (for example, by space services). Published notifications represent "online" services that are available to clients. The service's message address (URI) can be stored as an element in the notification. Notifications that are removed from the space transition back to a draft state that is either discarded or retained. The deletion raises an event and the associated listener notices the change. Message gates are usually created from published notifications. [0163]

In one embodiment, another possible state for notification is a permanent archive state. The archiving procedure transforms a live publish notification into a stream of bytes that can be permanently stored for later reconstruction. Archive notifications are sent from space to the archive service (for example, raw) In XML format). The notification archiving service URI can be stored as an element within the notification. XML can provide a format that stores and retrieves notifications and represents the state of the notification element sufficient to reconstruct the notification object. Notifications can be stored in other formats, depending on the implementation of the archiving service. The process of making published notifications permanent prepares notifications of persistent archiving status. Persistent notifications (for example, through archiving services) can be stored in persistent storage locations such as files and databases for future use. Spaces can store notifications via archiving procedures, but spaces do not necessarily play an important role in actually storing persistent notification entries. The method of storing persistent notifications is determined by the notification archiving service. Normally, no event is generated in place of an archive notification. In addition, changes may not be allowed for notifications in the persistent archive state. Notifications can only be archived and deleted, or archived. When a notification is archived without removing it from the space, the space stores a shadow version of the notification. When you access an archived service, notifications "fault in" from the persistent backing store on demand. This feature allows you to enter notifications from LDAP (Lightweight Directory Access Protocol) entries, for example, on demand. [0164]

FIG. 17 is a diagram showing an example of a notification state transition in which a notification is placed during its lifetime. First, notifications can be constructed as shown in 1. At build time, the notification is in draft state. The notification is then inserted inside the space, as shown in 2. Notifications can be inserted as published parents. The notification has been published since it was inserted in the space. An event (for example, AdvInsertEvent) is generated when a notification is inserted inside a space. The event will be described in detail below. Notifications are archived and made persistent, as shown in 3, which causes the notification to transition to a persistent archive state. Notifications can also be published from a persistent archive state, as shown in 4. The notification is removed from the space and transitioned back to the draft state, as shown in 5. An event (for example, AdvRemoveEvent) is generated when a notification is removed. [0165]

In one embodiment, the archived persistent state is not used. In this embodiment, state changes 3 and 4 are also not used. In this embodiment, the notification is either in draft or published state. [0166]

Notifications stored in spaces include version (which can be an element), creation date (which can be an attribute), modification date (which can be an attribute), implementation service URI (which can be an element), and / Or with standardized elements and / or attributes such as a persistent archive service URI (which may be an element). [0167]

The space itself is usually a service. Space services include the ability to search for notifications within a space, including searching for spaces by type of notification. Space services can also provide the ability to read notifications, write (publish) notifications, and take (delete) notifications. Space also has the ability to subscribe to space event notification messages. Spaces have the ability to navigate space-related graphs by position, read, write, or retrieve notification elements, read, write, or retrieve notification attributes, and subscribe to notification messages for notification events. Some have extended functions. The function of the space will be described in detail below. The function of space is embodied in the message schema of space notification. From the message schema, space address, and authentication certificate, you can create a client message gate to access the space and its features. [0168]

Spaces and all notifications within spaces can be addressed using URIs. In one embodiment, spaces and notification names follow a URL naming convention. In some embodiments, using a URI, such as a URL, to address the space makes the space accessible from the entire Internet. To specify the space message recipient (space service), use the URI received in the service notification for that space. The URI can include the protocol, host, port number, and name. The protocol names the protocol that can be used to move messages between the client and the space (for example, a trusted socket or an untrusted socket). The host and port numbers are protocol-dependent IDs. The name is the space name followed by the notification, element, and / or attribute name. In one embodiment, the pathname can be used to identify the notification in the space. The path name is either an absolute path or a relative path. With the absolute path name, you can specify not only spaces but also notifications. Relative pathnames are relative to designated notifications within the expected space. In one embodiment, the syntax applied to the creation of pathnames is the URI (unified resource identifier) syntax. Therefore, in that embodiment, notifications and space names cannot contain URI reserved word characters or a series of characters. Pathnames to elements and attributes can also be specified using URIs. In general, element names and attribute names can be added to notification pathnames such as http://java.sun.com/spacename/advertisement/element/attribute. [0169]

In one embodiment, the distributed computing environment provides a mechanism that allows clients to discover the URI of a space, but restricts access to service notifications for that space. In one embodiment, instead of returning the full notification back to the space, it returns the URI of the space and the URI of the authentication service for the space. The client first self-authenticates to the authentication service with the URI given in the return message in order to access the document or service notified in the space. The authentication service returns an authentication certificate that allows clients to perform partial or full access to the space. When the client receives the certificate, it connects to the space and attempts to access the document or service notification in the space. [0170]

A distributed computing environment provides a mechanism that allows clients to connect to a space. Embodiments of the connection mechanism correspond to client-space addressing, client authorization, security, leasing, client capability determination, and client-space connection management. A client-space connection is called a session. In one embodiment, a session can be assigned a unique session identification number (session ID). The session ID can uniquely identify the client-space connection. In one embodiment, the session lease mechanism is used to perform transparent garbage collection of sessions when the client does not renew the lease. [0171]

An example of using such a connection mechanism according to one embodiment is shown below. The client gets an authentication certificate. In one embodiment, the space provides an authentication service that is performed in response to a client requesting access to the space. The client can obtain the authentication certificate through the authentication service. Upon receiving the certificate of authentication, the client can initiate a connection with the space by sending a connection request message. In one embodiment, the connection request message may include the URI address of the space service, the client's authentication certificate, and information about the connection lease requested by the client. After receiving the connection request message, Space validates the message. One embodiment can use XML Schema to validate the message. The client can be authenticated using the authentication certificate. In one embodiment, the information received in the connection request message can be used to determine the client's ability to use the space. In one embodiment, each client of the space can be assigned a collection of their respective abilities to use the space. In one embodiment, an access control list (ACL) containing capacity information about one or more clients in a space can be used in client capacity determination. In one embodiment, the information received in the connection request message can be used to look up the client's capabilities within the ACL. [0172]

After authenticating the client and determining the client's capabilities, the connection lease that allows the client can be determined. After the lease is determined, you can generate a structure that maintains a client-space connection. Generate a session ID for the connection. In one embodiment, each client-space connection is assigned a unique session ID. In one embodiment, an activation space can be created and assigned to a client-space session, or an existing activation space can be assigned to a client-space session separately. In one embodiment, an activation space can be used to store the results of a client's service when the space is used. In one embodiment, the ability of the client is used to determine if an activation space is created for the client. For example, the client may not have the ability to access the activation space for storing and retrieving results. You can send one or more messages to the client to notify the client that the connection has been established. The one or more messages can contain information about the session ID and lease. The client can then use spaces such as, but not limited to, notification lookup, notification registration, and notification retrieval. In one embodiment, the connection remains open until the allocated lease expires or the client sends a message to the space requesting the cancellation of the lease. In one embodiment, the client needs to renew the lease before it expires. If the lease expires before the client renews the lease, the connection will be lost and the connection between the client and the space will be lost. In one embodiment, the client needs to repeat the connection procedure to reconnect. [0173]

In one embodiment, the space client can get the space notification in several different ways. Figure 18 shows some of the ways clients get space notifications. For example, a space discovery protocol can be provided as part of a distributed computing environment. Space discovery is a protocol that a client or service uses to find a space. Listener Agent 202 can be configured in association with one or more spaces to monitor for discovery requests. Discovery Listener Agent 202 waits on various network interfaces and receives broadcast or unicast requests (at the agent's URI) from client 200a looking for space. The listener agent 202 then responds with a service notification or URI regarding the service notification for the requested space. In one embodiment, the listener agent is generally separated from the space because its function is orthogonal to the function of the space service. However, the listener agent can be implemented on the same device as the space service or on a different device. [0174]

In one embodiment, the discovery protocol may be a service notified within the default space. The client instantiates the discovery protocol from the client's default space to discover additional space. The discovery protocol can be pre-registered in the client's default space. Alternatively, the discovery protocol can also self-register in the default space, for example, by placing a notification in that space when a client connects to the local network processed by the discovery service. [0175]

In one embodiment, the space discovery protocol can be mapped to a basic device discovery protocol for other platforms such as SLP, Jini, UPnP. The client then uses the discovery protocol of the distributed computing environment to find services in other environments. Provide a bridge with these other environments and send notifications to services within those other environments so that clients in the distributed computing environment described here can access them. See the "Bridge" section. [0176]

For each discovery protocol notified, a distributed computing environment can create a trailing result space to hold the results of the discovery protocol. In one embodiment, space services within a distributed computing environment can be announced over a LAN using Multicast Announcement Protocol (Multicast UDP). The listener agent records this information. The device (client or service) is Multicast Request Start discovering the space manager using Protocol (Multicast UDP). In one embodiment, the space manager responds with information indicating the URI of each space. Apart from that, the listener agent can respond for multiple spaces. The discovery response is also used to set up a TCP connection with a short string that labels each space (for example, taken from the space keyword) and each space manager that performs operations on each space, for example. Can contain information that can be included. This information is useful when the client chooses the space to connect to, as the requesting device receives responses from multiple space managers (or multiple space listings from the listener agent). [0177]

In addition to the multicast discovery mentioned above, the discovery service also provides unicast messaging (eg TCP) that can be used to discover space managers at known addresses on the network (eg Internet, other WANs, LANs, etc.). You can also use) to perform the discovery. The unicast discovery message can include a request for a space service with a known URI to send a service notification. Multicast discovery and unicast discovery protocols are defined at the message level and are therefore used regardless of whether the device participating in the discovery supports Java or other specific languages. be able to. [0178]

The discovery protocol makes it easy to spread clients independently of spreading server content that supports them in a distributed computing environment. For example, a mobile client can incorporate its initial default space into its local platform. In addition to the local services notified in the default space, mobile clients may have services to search for additional spaces, such as services to access the discovery protocol and services to access the space search engine. it can. [0179]

In one embodiment, the space discovery protocol in a distributed computing environment defines a set of XML messages and their responses, allowing the client to: -Broadcast the protocol definition space discovery message on the network interface. · Receive XML messages from listeners that describe the candidate spaces represented by those listeners. Select one of the discovered spaces as the default, even if the client does not know the address of the selected space. · Get information about the selected space, such as its address, and allow the client to later find the same space by means outside the discovery protocol (this is because the client later became non-local but still the client). Useful for accessing the spaces involved). [0180]

In some embodiments, the multicast and unicast discovery protocols require an IP network. While these discovery protocols meet the requirements of IP network-enabled devices, many devices are not directly supported by these discovery protocols. To meet the requirements of such devices for space discovery in a distributed computing environment, use the pre-discovery protocol to find an IP network-enabled agent. Pre-discovery protocols can include devices that send messages over non-IP network interfaces that require network agents. The network agent sets up a connection between itself and the device. Once the connection between the device and the agent is set up, the agent participates in the discovery protocol on the IP network for the device it will be used as the agent. Network agents are also typically interfaces for connecting devices to distributed computing environments. For example, a gate can be built in the agent for the device to run the service notified within the discovered space. See the "Bridge" section. [0181]

Another way for clients to identify a space in a distributed computing environment is to notify the space within another space. Spaces are services, so you can be notified within other spaces just like any other service. As shown in FIG. 18, client 200b finds notification 206 in the first space 204a for the second space 204b. Space 204b then contains a notification to the additional space. Services (implementing spaces) also act as clients, so spaces exchange or chain together notifications to achieve a base federation, as shown in Figure 19. A distributed computing environment can contain any number of spaces. The number of spaces and the topology are implementation dependent. For example, the spaces implemented on an IP network may correspond to different subnets. [0182]

A third way to identify space on the client is to run service 208, as shown in Figure 18. Service 208 runs and, as a result, returns a service notification for the space service. Since the service notification is an XML document and the distributed computing environment includes the Internet, the service 208 can be a web-based search tool. An example of such a service is the space lookup service described in Figure 4. In one embodiment, the space in a distributed computing environment can be implemented as a web page. Each web page base can contain keywords that can be searched to identify the web page as a space within a distributed computing environment. The space not only contains other searchable keywords, but can further define the space. The client connects to search service 208 and supplies the keywords to the search service in the form of XML messages. Search services receive keywords from clients and send them to Internet search engines, which may be traditional search engines or third-party search engines. The search service returns the results from the Internet search engine to the client, either directly as an XML message or by referencing the result space. The result is the URI of the space that matches the search request. Separately, the search service contacts the spaces identified by the search, retrieves service notifications for each such space, and space service notifications, either directly as an XML message or by reference in the result space. Can be returned to the client. The client can then select a space from the search results, build a gate (either by itself or through a proxy) and access the selected space. Access selected space [0183]

As mentioned above, the space can be an XML-paced website, so it can be searched by a search mechanism on the Internet Web. Spaces can contain Internet searchable keywords. Some devices, such as small client devices, do not support Internet browsers. However, even such devices can perform Internet searches for spaces within a distributed computing environment. The device has a program that accepts a sequence of keywords, and these keywords are sent to a proxy program on the server (for example, a search service). The proxy can send these keyword strings to a browser-based search function (for example, the Internet search function) to perform a search. The proxy receives the output of the search, parses it into a string representing each URI in the search result (for example, an XML string), and sends the response string back to the client. Therefore, the client can identify the space via the Internet even if it does not support a program such as a Web browser. On more sophisticated devices, you can avoid the use of proxies and start Internet-based lookup services directly. [0184]

A fourth way for a client to identify a space is to get or receive information about the newly created empty space or the created space when an existing space is created. An existing space can have an interface to generate an empty space that has the same functionality as the source space (eg, the same XML schema). The generation of space will be described in detail below. [0185]

When a space client finds a space service notification, that space client can run the space service as it would for any other service. Note that the space service client may be another service (for example, a service that requires notification within a space). In one embodiment, to perform the space service, as shown in FIG. 20, the space client first performs an authentication service on the space, and as shown in 300, the authentication certificate. get. The authentication service can specify the service of the space service in the notification. The space client uses the space's authentication certificate, the space's XML schema (from the space's service notification), and the space's URI (from the space's service notification), as shown in 302. Build a gate. The space client then executes the space service by sending a message to the space service using its gate. The first such message is shown in 304. [0186]

In an embodiment that employs authentication, when the space service receives the first message from the client with the authentication certificate embedded, the space service is specified in the same authentication service (the space service's service notification). Authenticate the client and establish its identity as shown in 306. The space service determines the client's capabilities and binds the client to the certificate of authentication, as indicated by 308. [0187]

As shown in 310, a space client can perform various space functions by sending a message to the space service. In one embodiment, when a space client sends a request to a space service, the client passes a certificate in the request, allowing the space service to check the request for a particular ability of the client. [0188]

Each space is typically a service and may have an XML schema that defines the core functionality of the space service. The XML Schema specifies the client interface with the space service. In one embodiment, all space services can issue basic level space-related messages. The basic level space feature is a basic space feature that can be used by most clients, including small devices such as PDAs. For example, for more sophisticated clients, it may be desirable to add more functionality. Base-level space expansion can be achieved by adding more messages to the XML schema notifying the space. For example, in one embodiment, the base level message does not force a relationship graph for the notification. For example, a message that traverses the notification hierarchy is a space extension. Such additional functionality can provide one or more extensions of space through an XML space schema or schema extensions. The extended schema contains the base schema, so clients in the extended space can also access the space as the base space. [0189]

In one embodiment, the base space service comprises a temporary repository of XML documents (eg, service notifications, results of running services). However, the basic space service of one embodiment may not support advanced features that support space content persistence, space structure (eg, hierarchy) navigation or creation, and transactional models. Mechanisms that support persistence, hierarchies, and / or transactions are achieved by extending XML Schema. The extended space still contains the base XML schema, so the client can treat the extended space as the base space if it is needed or can only support the functionality of the base space. [0190]

In one embodiment, the basic space can be temporary. The basic space can be accepted for a variety of purposes. Service providers can register services in various spaces. In one embodiment, the service needs to continuously renew the lease after publishing the information in the space. Due to this nature, service notifications are often temporary in that they are rebuilt and / or reconfirmed. However, it is desirable to achieve some persistence in the space. For example, a space with results can provide some persistence to users who want to keep the results from being lost for a period of time. In one embodiment, persistence can be achieved by specifying a space interface that allows the client to control the objects in the space backed by the persistent store and manage the maintenance of that persistent store. it can. Persistence interfaces can be specified in the extended XML schema of the space that defines the interface for persistence. [0191]

In one embodiment, the base space comprises an interface in which the XML document is added to the space and can be identified by a string. Base spaces cannot provide a hierarchy of various named XML documents within a space. In embodiments where hierarchy support is desirable, it is advisable to define additional interfaces that allow the user to specify the hierarchy (extending the XML Schema). You can also specify other interfaces to navigate the hierarchy and navigate the relationship graph by position. However, other users can still use the basic space interface to access the same document without using a hierarchy. Extended space schemas can also provide interfaces to the structure of other spaces. [0192]

The extended XML space interface can also be implemented for the space transaction model. For example, an extended space XML schema specifies an interface for ACID transactions. ACID is an acronym used to describe the four characteristics of enterprise-level transactions. ACID is an acronym for Atomicity, Consistency, Isolation, and Durability. Atomicity means that the transaction is either completely completed or undone. In the event of a failure, all operations and procedures must be undone and all data must be rolled back to their previous state. Consistency means that a transaction transforms a system from one consistent state to the other consistent state. Independence means that each transaction occurs independently of other transactions that occur at the same time. Durability means that a completed transaction is permanent without loss of content, for example, in the event of a system failure. Other transaction models can also be specified in the extended space schema. [0193]

The extended space schema can be an XML document that specifies the features, functionality, or message interface (for example, XML message) of the extended space to use. Spaces can have a base schema and multiple extended schemas. This makes it possible to easily provide different levels of service to different clients depending on the client's authentication. [0194]

In addition to space persistence, structure, and transaction extensions, you can specify other space extensions as needed. To work with notifications at the element or attribute level, for example, the ability to read, write, or retrieve notification elements, the ability to read, write, or retrieve notification attributes, and the ability to subscribe to notification messages for notification events. It can also be equipped with the extension function of. Spaces can virtually provide any number of features and can be arranged in the base and extended schemas as needed. In one embodiment, all basic spaces need to have the ability to read, write, capture, and look up notifications, as well as the ability to subscribe to space events. Various space functions can be prepared. In some embodiments, it may be provided with a function for establishing a session with the space. In such an embodiment, the remaining functions of the space function will not be available until this is completed. In other embodiments, the concept of a session is absent or optional and / or implementation dependent. [0195]

Other space features include adding service notifications to the space and removing service notifications from the space. In addition, you can provide a space feature to add or remove XML documents (probably the result in the space, not the notification). The space service checks the uniqueness of an item before allowing it to be added. For example, each item added to a space can be associated with a user-specified string that can be used to identify the item and check its uniqueness. [0196]

In one embodiment, the client may request a listing, tree, or other representation of all services notified within the space. The user then scrolls or steers the notification to select the desired service. Spaces also have a lookup feature that allows clients to search for services by giving them keyword or string names. In one embodiment, the space function comprises a mechanism for looking up the space entry added to the space. The lookup feature can be looked up with a string that matches the name, or a wildcard, or a database query. The lookup feature returns multiple entries that the client can select, or even perform a refined search. In one embodiment, the lookup function comprises a mechanism for identifying service notifications that match a particular XML schema. The client can specify a particular XML schema or part of a particular XML to search within the space. Therefore, the service can be searched in the space according to the interface function. [0197]

Another space feature that can be provided in a distributed computing environment is a mechanism by which services and clients can find temporary documents based on typing models such as XML. This mechanism is a general-purpose typed document lookup mechanism. In one embodiment, this lookup mechanism is based on XML. This lookup mechanism allows clients and services to generally find documents, including services via service notifications. [0198]

In one embodiment, space lookup and response message pairs can be used to allow clients and services to find XML documents stored in the network temporary document store (space). A space is a document space used to store various documents. In one embodiment, the document is an XML document or a non-XML document encapsulated in XML. Space will be discussed in more detail elsewhere. Lookup messages work on any kind of XML document stored in a space, including service notifications and device driver notifications. In one embodiment, the client (which may be another service) can use the discovery mechanism as described elsewhere to find one or more document spaces. The client can then use the space lookup message to identify the documents stored in the space. [0199]

The distributed computing environment provides a mechanism for services and clients to subscribe and receive events related to the publication of XML documents. Events can include the ability to publish and remove XML documents from temporary XML document repositories such as spaces. In one embodiment, the event is an XML document that references another XML document. [0200]

In one embodiment, a space event subscribe and response message pair can be used to subscribe to events related to documents that clients and services are added to or removed from the space. In one embodiment, event subscriptions can be leased using the leasing mechanism described elsewhere. In one embodiment, the subscription can be canceled when the lease is canceled or its expiration date has expired. In one embodiment, the subscription can be renewed when the lease on the subscription is renewed. [0201]

In one embodiment, the event subscribe message can include an XML schema that can be used as a document matching mechanism. Documents that match the schema are handled by the subscribe. In one embodiment, the document added to the space and matching the XML Schema produces a space event message. [0202]

It can also provide a space feature that allows clients to register (or unregister) to get notifications when something is added to or removed from a space. Spaces can store temporary content, which reflects services added to or removed from the space. For example, you can provide a mechanism to notify the client when a service becomes available or becomes unavailable. The client can register with the event service to get such notifications. In one embodiment, the client notifies when adding or removing services from a space that have a name that matches the specified string or a schema that matches the specified schema (or schema part). You can register to do so. Therefore, the query registered in the space event notification function is the same as or similar to that of the service lookup function described above. [0203]

FIG. 43 is a flow chart showing a search for a space using a search service in a distributed computing environment according to one embodiment. In one embodiment, a device client may interact with a search service on the same or different device to find space for storing and / or retrieving data (ie, a network accessible object repository). it can. Embodiments of this dialogue are further shown in Figures 46a and 46b. Client 110 can send a search request to search service 2102, as shown in 2000. The search request can include one or more desired properties that are searched from the space. In one embodiment, the search request is represented in a data representation language such as Extended Markup Language (XML). In one embodiment, the desired characteristics of the search request may include one or more keywords. Clients can include program 2100, which accepts keywords and sends them to search service 2102. In one embodiment, the keyword can be sent as XML message 2106 and / or using the gates described herein. [0204]

Based on the search request, the search service 2102 can perform the search. In the embodiment shown in FIG. 46a, the search service 2102 can interact with a search engine 2104, such as an Internet search engine, when performing a search. In this way, the search service can act as a proxy between the client and the search engine. Proxies may be particularly desirable for clients on small devices that do not have the resources to interact with search engines, such as by using a web browser or receiving an entire set of search results. Search engines can include network-accessible third-party search engines, such as browser-accessible Internet search engines. In the embodiment shown in FIG. 46b, the search service 2102 may include a search engine 2104 or be tightly coupled in some other way. As shown in 2002, search service 2102 can translate search requests from a data representation language (eg XML) into a text format that can be used by search engines 2104. As shown in 2004, the search service 2102 can send the translated search request to the search engine 2104. [0205]

As shown in 2006, the search can be performed by the search engine 2104 to generate search results. Search results can include space locations (eg URIs) in one or more results, such as 2120a, 2120b, and 2120c. In one embodiment, the space may include one or more web pages accessible via the Internet 2110. Web pages can contain identifying keywords that identify the web page as a space in a distributed computing environment. The search request can include this keyword along with one or more other keywords that describe the desired characteristics of the space. [0206]

As shown in 2008, the search service 2102 can receive search results in text format from the search engine 2104. As shown in 2010, search service 2102 translates text-formatted search results into data representation language (eg XML) search results and sends the results to client 110. In one embodiment, the search service 2102 can obtain service notifications for the resulting spaces 2120a, 2120b, and 2120c, respectively. Each service notification contains information that can be used to access your space. Search service 2102 sends references to these notifications (eg, Uniform Resource Identifiers) or the notifications themselves as search results, allowing clients to access the resulting space at each location, as shown in 2012. To do so. In one embodiment, the space at the result location contains a Uniform Resource Identifier (URI). [0207]

In one embodiment, when sending search results to client 110, search service 2102 stores the search results in a result space (ie, a network accessible storage repository) and addresses the result space to the client. Can be sent to 110. Client 110 can access the search results in the result space at any time. The use of result space is especially desirable for small clients who do not have the resources to receive and display the entire set of results. In this situation, according to one embodiment, the user can read the result from the result space using different clients. [0208]

In some embodiments, the search service limits or filters the space that can be found through the search service, or causes the client to search only a small number of supported spaces in a distributed computing environment. Can be restricted. The scope of allowed searches can be determined according to client authentication. [0209]

FIG. 47 is a flow chart showing a search for documents in a space in a distributed computing environment of one embodiment. In one embodiment, the client can interact with the space via a search message to find the document in the space. As shown in 2200, the client can send a lookup message to the space. The space can contain a network addressable storage location that is operational to store one or more documents. The stored document can be represented in a data representation language such as Extended Markup Language (XML). You can specify the desired characteristics of the document in which the lookup message is stored. In one embodiment, the document can include XML service notifications and XML device notifications as well as generic XML documents. For example, an XML document in a space can contain the results of a service, expressed in XML. [0210]

You can find a set of documents that match the lookup message, as shown in 2202. The documents found can include all stored documents that match the desired characteristics specified in the lookup message. Zero or more stored documents may match the desired characteristics. In one embodiment, the lookup message can include the desired name. In one embodiment, the desired name specified in the lookup message can include one or more wildcards. Each of the documents found can have a name that matches the desired name, and the name can identify the document found in the space. In one embodiment, the lookup message can include the desired schema expressed in the data representation language. Each of the documents found can have a schema or part of a schema that matches the desired schema. In one embodiment, the lookup message can include both the desired name and the desired schema. In this case, the set of discovered documents can include both the discovered document with a name that matches the desired name and the discovered document that has a schema that matches the desired schema. In one embodiment, the lookup message may not include the desired name or the desired schema. In this case, the lookup message is essentially a request for all documents in the space, and the set of documents found can include virtually all of the documents stored in the space. .. [0211]

After finding a matching document, Space can send a search response message to the client, as shown in 2204. In one embodiment, the search response message may include the name of the document found. In one embodiment, the search response message may include a notification message for each of zero or more found documents. Each notification can include information available to the client to obtain each discovered document or to access the resources (eg, services) that the document notifies. In one embodiment, each notification is a Uniform Resource of a location where each discovered document (or a resource such as a service notified by the document) is accessible. It can contain an Identifier (URI). In one embodiment, at least one of the documents found can be a notification about the service. Notifications about a service can include a schema, which specifies one or more messages that can be used to call one or more functions of the service. Notifications can be expressed in a data representation language such as XML. [0212]

In one embodiment, the lookup message and the search response message are represented in a data representation language such as XML. The space schema allows you to specify the format of lookup and search response messages. In one embodiment, the pair of messages can be expressed in XML as follows. Lookup message <Space> <Lookup Advertisement> <AdvertisementName> Name </ AdvertisementName> <AdvertisementSchema> Notification Schema </ AdvertisementSchema> </ Lookup Advertisement> </ Space> Search response message <Space> <LookupAdvertisementResponse> <Advertisement> Notification </ Advertisement> <AdvertisementName> Name </ AdvertisementName> </ LookupAdvertisementResponse> </ Space> [0213]

In XML lookup messages, the "name" can be a string value, and the name can specify a unique identifier within a space. Identifiers may not be unique if wildcards are used. "Adv Schema" is a schema in which lookups are expected to match. In one embodiment, both fields are optional. In the XML lookup response message, "Adv" is a group of zero or more matching notifications and "Names" is a group of names corresponding to the notifications. [0214]

FIG. 48 is a flow diagram showing addressing of a service using notifications stored in a space in a distributed computing environment according to one embodiment. In one embodiment, the service can publish service notifications within the space, as shown in 2300. The space can be a network addressable storage location where documents such as extended markup language (XML) documents are stored. Publishing notifications will be described in detail elsewhere in this detailed description. In one embodiment, the notification is a Uniform Resource of the service. It can include an Identifier (URI) and a schema. The URI can specify the network address that can access the service, and the schema can specify one or more messages that can be used to call one or more functions of the service. In one embodiment, the schema and message can be represented in a data representation language such as XML. As shown in 2302, the client can access the space and find the notification. For example, a client can use the discovery service to find a space and then use a lookup service such as the one shown in Figure 47 to find notifications in the space. [0215]

In one embodiment, the notification includes substantially all of the information that the client needs to access a particular service. As shown in 2304, the client can read the notification from the space. In one embodiment, the client can use the URI and schema in the notification to build a gate to access the service. As shown in 2305, the client can call one or more functions of the service by sending the first message specified in the schema to the service at the URI. In response, you can call a function of the service, as shown in 2308. In one embodiment, the service can send a second message (for example, a message containing the result of the called function) to the client, which second message is specified in the service's schema. is there. [0216]

When a client of a space contracts to be notified when an XML document (eg, a service notification) is added or removed from the space, the client may obtain a lease for this contract for notification. Leases can be used to know if Space Services will continue to send notifications to specific clients. For example, a lease for the notification feature can be made to expire after some time if it is not renewed. Note that leasing may not be required while the client is establishing an active session with the space. After disconnecting the active session with the space, the client can continue to receive event notifications according to its event contract as long as the corresponding lease remains active. See the lease section below. [0217]

Clients can subscribe to different types of events. An example is a service notification that is added or removed from a space, as described above. The client can also be notified when the results from a service initiated by the client (or someone else) are placed in the space. For example, a client and a service can mutually choose a name that refers to the result of the service. The client can register with the space service where the results are posted or notified in order to receive an event when the results referenced by the selected name are added to the space. [0218]

Spaces can generate different types of events that clients can contract with. As a composite of space changes, events can be created for clients and services contracted for such events. In one embodiment, there are two main space event categories: spaces-related categories (insertion and removal of notifications) and categories used to indicate changes to notifications (addition, removal, modification of elements or attributes). Can be provided. Which events are supported can be indicated by the space's XML message schema. [0219]

The event below is an example of an event that may be created by the space service to indicate a space event or notification event. [0220]

[table 1]

<img file="JP2003533766A_D0001.tif" /> 【0221】

The event is typed. In some embodiments, space-supported event functionality allows event listeners to utilize, for example, a Java class (or XML type) hierarchy. For example, by waiting for an AdvElementEvent to occur, the listener receives all events of type AdvElementEvent and its subclasses (XML type). Therefore, in this example, all events related to element changes (although there is no insertion or deletion of notifications) are received. [0222]

In another example, all space events are received when subscribing to or waiting for a top-level event class or type, such as SpaceEvent. Event class types can be distinguished, for example, through the Java instance of operator or the XML type system. [0223]

The event contains a URI to the affected notification or element. For example, AdvertisementEvent and all its subclasses contain a reference (for example, a URI or URL) to the affected notification. AdvElementEvent and its subclasses can investigate the names of the affected elements. For example, the previous element value (URI or URL) can be used from AdvElementRemoveEvent and AdvElementValueChangeEvent. [0224]

Figure 21 shows the type hierarchy of space events in one embodiment. Types can be defined in XML and used in other suitable object-oriented languages such as Java and C ++. [0225]

The space has the ability for the client to instantiate the service notified within the space. Service instantiation is an initialization performed to allow a client to execute a service. An embodiment of service instantiation is shown in FIG. To instantiate a service, the client first selects one of the service notifications published in the space, as shown by 320. Clients can use various features provided in the space, such as the lookup feature, to look up different notifications in the space. The client then requests the space to instantiate the service, as shown in 322. [0226]

In one embodiment, service instantiation involves the following operations: After the client requests the space service to instantiate the selected service, the space service instantiates the requested service, as shown in 322, as shown in 324. Confirm that it can be converted. Space Services performs this verification by examining the authentication certificate contained in the client's message. A certificate of authentication is a certificate that a client receives when establishing a session with a space service. The space service verifies whether a client can instantiate the requested service according to the client's credentials and capabilities indicated to the client. See the "Authentication and Security" section below. [0227]

Assuming the client is authorized, the space service can also take a lease of the service notification to the client at the lease request time specified by the client, as shown in 326. Leasing will be described in detail below. Space Services sends a message to the client containing service notifications for assigned leases and services, as shown in 328. In one embodiment, the client performs the authentication service specified in the service notification and obtains an authentication certificate, as indicated by 330. For more information on authentication services, see the "Authentication and Security" section. The client then builds a gate for the service, as shown in 332 (for example, using the XML schema and service URI from the certificate and notification). See the "Gate" section. The above-mentioned communication between the client and the space service is performed using XML messaging in a distributed computing environment. The client then runs the service using the constructed gate and XML messaging. The service also builds a service gate for communicating with the client via XML messages. [0228]

As a summary, an example of using space will be described below. Clients can access (for example, connect to) space services. (The service acts as a client to access or otherwise use the space.) A space service is stored within one or more service notifications and / or other content paces. And each of the service notifications contains information that can be used to access and perform the corresponding service. A space service can have a schema that specifies one or more messages that can be used to invoke a function of the space service. For example, a schema can read notifications from a space and specify a method to publish the notifications within the space. Schemas and service notifications can represent objects such as extensible markup language (XML) in a representation language. When accessing the space service, the client sends information such as an XML message (specified in the schema) to the space service at the Internet address. When accessing a space service, the client searches for one or more service notifications stored in the space. The client can select one of the service notifications from the space. In one embodiment, the client sends an instantiation request to the space after selecting the desired service notification from the space. Acquires a lease for the desired service and sends the selected service notification to the client by the lease and space service. The client then builds a gate for access to the desired service. You can run the desired service for the client. [0229]

Other features provided by the space service include the ability to create or create empty spaces. When using this space feature, clients (which may be services to other clients) can dynamically create new spaces. In one embodiment, the space feature may include an interface that creates an empty space with the same functionality (same XML schema or extended schema) as the source space. This feature can be used to generate spaces (for example, dynamically) for the result. For example, the client can generate a space that either puts the result in the space where the service generated it or requests that the result be notified in the generated space. The client passes the generated space URI and / or authentication certificate to the service. Alternatively, the service creates a space for the result and passes the generated space URI and / or authentication certificate to the client. In some embodiments, once a space is created, like any other space, the space described here can be discovered using one or more of the discovery mechanisms. [0230]

You can efficiently create new spaces using mechanisms that create spaces through interfaces within other spaces (for example, the space generation feature). For example, in one embodiment, storage for the generated space can be allocated using the same functionality used in the original space for storage. Also, the created space can share common service functionality with the original (or parent) space. For example, you can assign a new URI to a new space. In one embodiment, the new URI can be a redirection to a common space feature shared with the original space. Therefore, the newly generated space can use the same service code or part of it as the original space. [0231]

The space function also includes, for example, security management functions for updating various security policies and other management functions of the space. For example, the number of notifications and elapsed time can be controlled and monitored by the route space service. You can collect and dispose of old notices. For example, see the Lease section if the notice can be considered out of date. The service that implements the space is under the control of the administrator. The administrator can set the policy in a service-dependent manner. The Space feature also has the ability to remove empty spaces. [0232]

Some spaces may be equipped with features or services that further support the spread of certain clients, such as mobile clients. For example, a service in a space that a mobile client can discover through a discovery protocol, etc., supports the mobile client as follows: -Assign and manage temporary network addresses for clients. -Pass message communication to the client through a proxy. -Prepare a search function for the additional space. For example, services allow clients to specify keywords through a simple interface. The service then uses the keyword in a web search engine to search for spaces on the web, as detailed here. In other embodiments, the search service constrains the client to search for a very small number of supported spaces within a distributed computing environment. [0233]

As mentioned earlier (see Figure 9 and the accompanying text), spaces provide a convenient mechanism for storing results from services run by clients. When using space for results, small clients can receive the results of running a service in pieces. Some services can produce a large amount of results. By using spaces to store results from a service, the service can be used by clients who do not have the resources to receive all the results at once. In addition, space is used to store results, freeing services running on fast, in-use servers from direct interaction with slow clients when large numbers of results are returned. it can. Therefore, the service can be released immediately and used by other clients. [0234]

Spaces provide a convenient mechanism for accessing results by different clients and / or at different times. For example, a client may not be able to use the entire result, but the user wants to use another client that can access the result later to access the rest of the result. For example, results include stock market conditions, current stock price views (accessible from PDAs), and stock price chart views (later accessible from laptops). Also, using space for results in a distributed computing environment allows clients to supply the results of one service to the other, without having to download the results first. For example, in the case of the stock market above, the PDA can send the chart to another service, where it can be printed, without the need to download the chart itself on the PDA. Therefore, the result space provides a mechanism for a client to pass the result to another client or service without processing or receiving it. [0235]

In different embodiments, the decision to use space for the result is dictated by the service, dictated by the client, and / or required by the client. The service may, for example, propose to use space for the result in its notification. In one embodiment, either the client or the service can create new space for the result or use the existing space for the result. See the description of space generation. [0236]

In one embodiment, using a space for a result does not necessarily mean that the service needs to put all the results in that space. There may be alternatives to the results produced by the service. For example, some or all of the results can be sent inline to the client by message. Alternatively, you can put the result in a space and then send a notification message to the client to refer to the result (for example, include a URI to the result or a URI to the result notification). Another option is to put the result in a space and send a notification by an event from the space. For example, clients and services call results with some specific name, and clients receive events when adding such named results to spaces (using space features such as those above). You can register in the space. See the description above for event notifications. [0237]

Therefore, several different mechanisms by which a service returns results to a client can be used within a distributed computing environment. The actual result is returned to the client with the value in the XML message, or the result is returned to the client with a reference by the actual value (or notification of the actual result) placed in the space, and the client is the result in the space. Receive a message that references. In addition, results or result notifications can be placed in spaces to notify clients with events. [0238]

Other mechanisms that process results specify other services for the results supplied by the client. For example, when a client runs a service that outputs results, it can instruct that service (for example, via XML messaging) to send the results to other services for further processing. This requires the client to tell the other service the URI of the notification and the result output service to generate a gate to the other service in order to run the other service and pass the result. In this example, the result output service may be a client of another service. In some embodiments, the client sends a schema or pre-built gate to the results output service to access the service for further processing. An example of a service to process further is a display service that can display the results of the original client. This display service is on the same device as the client or is associated with such a device. [0239]

FIG. 41 is a flow chart showing the creation of a new space in a distributed computing environment according to one embodiment. As shown in 1900, the client can access (ie connect to) the first space service (the service can act as a client for access to space or other uses). The first space service can store one or more service notifications and / or other content in the first space, and each of the service notifications can be used to access and run the corresponding service. Can be included. The first space service can contain a first schema that specifies one or more messages that can be used to call the functions of the first space service. For example, the first schema allows you to specify a method to read notifications from the first space and a method to publish notifications in the first space. The first schema and service notifications can be expressed in an object representation language such as Extended Markup Language (XML). When accessing the first space service, the client may send information such as XML messages (specified in the first schema) to the first space service at the first internet address (eg URI). it can. When accessing the first space service, the client can search for one or more service notifications stored in the first space. [0240]

In one embodiment, the space can include the ability to create a new space. As shown in 1902, a client can request the creation of a second space, such as by sending an appropriate request to the interface of the first space. In one embodiment, the request can be formatted as an XML message according to the first schema in the first space. In response, a second space service with a second space can be created, such as with a second internet address (eg URI), as shown in 1904. As above, the second space service can include a second schema that specifies one or more messages that can be used to call the functions of the second space service. The second schema can contain at least the first schema, and the second schema can also include additional functionality. In one embodiment, the schema of the second space can include part of the first schema, or the second schema can be specified at the time of creation of the second space. As shown in 1906, the client can access the second space by sending at least one of the messages specified in the second schema to the second space. [0241]

Space creation can include administrative initializations such as those related to security. In one embodiment, when the requesting party creates a space, initially only the requesting party is allowed access to the created space. Restricting access to such created spaces will be useful when clients and services use the created spaces to store results. See the Authentication and Security section for information on the authentication and security of the created space. After creating a new space, the client can build a gate to access the created space. [0242]

Therefore, in various embodiments, the results can be obtained in multiple ways, for example, in a message, in a space, in a space where the client is notified via an event, and with a notification returned in the message. It can be returned to the client using the notifications returned in the space and the notifications returned in the space that the client is notified of via the event. These various methods of returning results are shown in Figures 44a-44g. The availability of these multiple methods can enhance the flexibility and adaptability of a distributed computing environment in a variety of situations, such as those for clients with different capabilities. For additional flexibility, the results can also be efficiently passed to another service, as shown in Figure 45. [0243]

FIG. 44a is a flow chart showing a method of storing service results in a space in a distributed computing environment according to one embodiment. As shown in 2050, the client can send a first message to the service requesting a call to one or more functions of the service. The service's schema allows you to specify multiple messages that can be used to call the service's functions, including the first message. Messages and schemas can be represented in platform-independent and / or programming language-independent data representation languages such as XML. [0244]

As shown in 2052, one or more functions of the service can be called in response to the first message. The service can generate a set of results, as shown in 2054. The results can be expressed in a data representation language (eg XML). As shown in 2056, a service can store a set of results in a location within a space, which contains a network addressable storage location. In one embodiment, a space can be created in preparation for storing the set of results. [0245]

As shown in 2058, the client can access and read the set of results from the space. In one embodiment, a second client (ie, a client different from the client that sent the message calling the function) can read the set of results from the space. In this way, the user uses the second client to read and view the results when the first client may not have sufficient resources to accomplish tasks such as reading and displaying the results. can do. In one embodiment, the client can send a message to the service requesting that the service pass the address of the set of results to the second service, so that the second service sets the results from the addresses in the space. Will be able to read. Uniform Resource for notification of the second service in the second message An Identifier (URI) can be included, and this second service notification contains information that can be used to access the second service. In this way, the result can be efficiently passed from the first service to the second service without passing it to the client. [0246]

FIG. 44b is a flow chart showing a method of storing the result of the service in the space and notifying the client by using an event according to one embodiment. As shown in 2050, a client can send a first message to a service requesting a call to one or more functions of the service. As shown in 2052, one or more functions of the service can be called in response to the first message. The service can generate a set of results, as shown in 2054. The results can be expressed in a data representation language (eg XML). As shown in 2056, a service can store a set of results in a location within a space, which contains a network addressable storage location. As shown in 2057, an event can be generated and sent to the client to notify the client that the result is stored in space. As shown in 2058, the client can access and read the set of results from the space in response to the event. [0247]

FIG. 44c is a flow chart showing a method of sending the result of the service to the client in a message according to one embodiment. As shown in 2050, the client can send a first message to the service requesting a call to one or more functions of the service. As shown in 2052, one or more functions of the service can be called in response to the first message. The service can generate a set of results, as shown in 2054. The results can be expressed in a data representation language (eg XML). As shown in 2055, the service can send a message containing the results to the client. The message can be represented in a data representation language (eg XML) and, in one embodiment, in the schema of the service. [0248]

FIG. 44d is a flow chart showing a method of returning the result of the service using the notification according to one embodiment. As shown in 2050, a client can send a first message to a service requesting a call to one or more functions of the service. As shown in 2052, one or more functions of the service can be called in response to the first message. The service can generate a set of results, as shown in 2054. The results can be expressed in a data representation language (eg XML). In one embodiment, the service can store a set of results in a location within a space, which space includes a network addressable storage location. The service can generate notifications about the results, as shown in 2060. Notifications can include information that can be used to access and read results, such as from spaces. For example, in a notification, a Uniform Resource where you can access the results It can contain an Identifier (URI). In one embodiment, the notification may include a schema that specifies the format of the result (eg, an XML schema). In one embodiment, the notification can be expressed in a data representation language such as XML. As shown in 2068, clients can access and read the set of results by using notifications. In one embodiment, a second client (ie, a client different from the client that sent the message calling the function) can read the set of results by using the notification. [0249]

FIG. 44e is a flow chart showing a method of returning the result of the service by using the notification sent to the client in the message according to one embodiment. As shown in 2050, a client can send a first message to a service requesting a call to one or more functions of the service. As shown in 2052, one or more functions of the service can be called in response to the first message. The service can generate a set of results, as shown in 2054. The results can be expressed in a data representation language (eg XML). In one embodiment, the service can store a set of results in a location within a space, which space includes a network addressable storage location. The service can generate notifications about the results, as shown in 2060. Notifications can include information that can be used to access and read results, such as from spaces. For example, in a notification, a Uniform Resource where you can access the results It can contain an Identifier (URI). In one embodiment, the notification may include a schema that specifies the format of the result (eg, an XML schema). In one embodiment, the notification can be expressed in a data representation language such as XML. As shown in 2061, the service can send a message containing a notification to the client. The message can be represented in a data representation language (eg XML) and, in one embodiment, in the schema of the service. As shown in 2068, clients can access and read the set of results by using notifications. [0250]

FIG. 44f is a flow chart showing a method of returning the result of the service by using the notification stored in the space according to one embodiment. As shown in 2050, a client can send a first message to a service requesting a call to one or more functions of the service. As shown in 2052, one or more functions of the service can be called in response to the first message. The service can generate a set of results, as shown in 2054. The results can be expressed in a data representation language (eg XML). In one embodiment, the service can store a set of results in a location within a space, which space includes a network addressable storage location. As shown in 2056, a service can store a set of results in a location within a space, which contains a network addressable storage location. The service can generate notifications about the results, as shown in 2060. Notifications can include information that can be used to access and read results, such as from spaces. For example, in a notification, a Uniform Resource where you can access the results It can contain an Identifier (URI). In one embodiment, the notification may include a schema that specifies the format of the result (eg, an XML schema). In one embodiment, the notification can be expressed in a data representation language such as XML. Notifications can be stored in spaces, as shown in 2062. The space can be the same as or different from the space where the results were stored in 2056. As shown in 2066, the client can read the notification from the space. In one embodiment, a second client (ie, a client different from the client that sent the message calling the function) can read the notification from the space. As shown in 2068, clients can access and read the set of results by using notifications. [0251]

FIG. 44g is a flow chart showing a method of returning the result of the service by using the notification stored in the space and the notification to the client by using the event according to one embodiment. As shown in 2050, a client can send a first message to a service requesting a call to one or more functions of the service. As shown in 2052, one or more functions of the service can be called in response to the first message. The service can generate a set of results, as shown in 2054. The results can be expressed in a data representation language (eg XML). In one embodiment, the service can store a set of results in a location within a space, which space includes a network addressable storage location. As shown in 2056, a service can store a set of results in a location within a space, which contains a network addressable storage location. The service can generate notifications about the results, as shown in 2060. Notifications can include information that can be used to access and read results, such as from spaces. For example, in a notification, a Uniform Resource where you can access the results It can contain an Identifier (URI). In one embodiment, the notification may include a schema that specifies the format of the result (eg, an XML schema). In one embodiment, the notification can be expressed in a data representation language such as XML. Notifications can be stored in spaces, as shown in 2062. The space can be the same as or different from the space where the results were stored in 2056. As shown in 2064, an event can be generated and sent to the client to notify the client that a notification about the result is stored in the space. As shown in 2066, the client can read the notification from the space. As shown in 2068, the client can access and read the set of results from the space by using the notification. [0252]

FIG. 45 is a flow chart showing a method of sending the result of one service to another service in a distributed computing environment according to one embodiment. As shown in 2070, the client sends a first message to the first service requesting a call to one or more functions of the service and passing the result of the function to the second service. be able to. The schema of the first service allows you to specify multiple messages that can be used to call functions of the first service, including the first message. Messages and schemas can be represented in a platform-independent data representation language such as XML. In one embodiment, the first message can include the Uniform Resource Identifier (URI) of the notification of the second service, and the notification of the second service contains information that can be used to access the second service. .. [0253]

As shown in 2072, the function of the first service can be called in response to the first message. As shown in 2074, the first service can generate a set of results. The results can be expressed in a data representation language (eg XML). As shown in 2076, the first service can send the result to the second service in a message instead of sending the result directly to the client. In this way, the result can be efficiently passed from the first service to the second service without passing it to the client. [0254]

The result space and method gates allow distributed computing environments to provide simple remote method calls that are practical for thin clients with minimal memory and very low bandwidth. This is because there is no annoying side effect that a huge program object (along with the required classes) is (always) returned to the client on the network like the traditional remote method calling method. Instead, the result is the actual object that can be returned to the result space and downloaded to the client only when needed (and resident on the client). [0255]

The mechanisms that a distributed computing environment provides for invoking remote methods are as follows (see also the method gate description in the "Gates" section): Objects can be advertised in spaces (for example, as a service or as part of a service). The notification includes a reference that includes the object's URI (eg, URL) along with other access parameters such as security certificates and XML Schema. The client sets or builds a client method gate on the object, which takes method parameters for all methods of the object (or service) itself and creates a request XML message for the object. It has a wrapper method that calls the method of. The XML message is sent to the service gate that calls the actual method on the service object. When the method returns a result object, the service gate posts the result object in the result space and returns a message to the client with a reference to the result object. [0256]

Therefore, in order for a client to call a remote method, the client first sends a message that instantiates an object (eg, a service), as described above. In one embodiment, to instantiate an object, create or create a result space. In other embodiments, creating a result space is separate from instantiating an object. Instantiation returns the object URI to the client, and the client and service gate are dynamically created when the client requests instantiation. In some embodiments, the result space already exists and is signaled by the object (service). Some or all of these gates are also pre-built or reused. [0257]

If the client instantiates the object and then calls the appropriate client method gate locally, the remote call to the actual remote object is affected, as described above. The method of remote method invocation in a distributed computing environment is recursive, and when a client gate is called, an object reference is returned to the client rather than the object itself. Note that such returned objects are already instantiated. In some embodiments, the client side decides not only to call remotely, but to download the entire object itself. [0258]

The method or service called as described above produces a child gate associated with the result document. The method returns the child gate of the reference (or the schema, URI, and certificate for the client to build the child gate), not the reference itself. The client can then access the reference through the child gate. The child gate may be a method gate. [0259]

As mentioned above, this remote method call provided in a distributed computing environment allows the actual result object to be stored in the service result space (which can be dynamically created by a Servlet, for example). The result space is temporary. The result space can act as a query result cache. Server software (garbage collector) that cleans up the old result area crawls through the result cache. We adopt distributed garbage collection because the result space is filled until it is destroyed, either by indicating that the client no longer needs space or by setting an appropriate limit by the server administrator. Is. [0260]

Returning to Figure 23, a diagram of the default space 350 is shown. A distributed computing environment provides at least one default space that allows clients to find an initial set of notifications. The device can have a locally existing default space that incorporates a pre-built gate. Services notified in that default space reside locally on the device and include system software that enables or facilitates the device's participation in a distributed computing environment. [0261]

The default space 350 comprises one or more mechanisms 352 that identify the external space, as shown in FIG. One service in the default space can run the space discovery protocol described above to find the external space. You can also notify the external space within the default space. In addition, it informs the service (for example, a search engine or a proxy server to the search engine) within the default space that determines or finds the external space. Each space resembles a file system mount point. Therefore, a distributed computing environment can provide searchable dynamic mount points for services. The default space is the initial mount point for clients in a distributed computing environment. [0262]

You can incorporate the default space or the ability to access the default space into your device. You can provide a client execution environment for a distributed computing environment through the default space and local services that exist on the device. The device's local service and default space service incorporate a prebuilt gate. One of the built-in services listed in the default space is the service that runs the discovery protocol, allowing clients to identify additional (for example, external) spaces. The default space includes a built-in service that provides an execution environment for the client that the client user uses to browse the space, select and instantiate the service. Such services allow the client to manipulate the entire string (for example, a keyword for a space search), view or reference a result reference (for example, a space listing, or a service listing within a space), or an item (for example). It has a simple user interface for selecting (to select and instantiate a service), and so on. [0263]

Devices that primarily serve will also have a default space, which can include built-in services that allow the service to manage self-notification within different spaces. For example, devices such as printers have a built-in default service that finds a space on the local area network (perhaps using a discovery protocol) and adds printer service notifications to that space. The service can also maintain printer service notifications in the LAN space, for example by renewing the lease or updating the printer's XML schema. [0264]

On some servicing devices, the overhead of notifying the service and finding space to maintain that notification is undesirable. In one embodiment, instead of searching and maintaining one or more spaces to publish service notifications, the services of some devices send those notifications in response to a connection request. For example, printer devices that have accessibility-based printer services do not maintain notifications in space (either on or outside the device). Instead, when another device establishes a connection with the printer device (for example, the user who owns the laptop running the client attempts to print a document), the printer service sends a service notification and the printer -The device can connect to a service that provides printing functions and provide an XML service schema that executes that service. In addition, some devices only maintain notifications for services in some neighborhood or local network. Such devices may not want or may not have widespread support for access to the transport in terms of accessibility. [0265]

An example of a service device where it is desirable for the device to avoid or limit service notifications in space is a device whose functionality is available on an accessibility basis. Accessibility-based services can notify features when requested. These notifications may not be widely accessible. For example, accessibility-based services can be provided by wireless communication systems. The term "wireless" means a communication, monitoring, or control system in which electromagnetic waves or sound waves transmit signals through the atmosphere rather than through wires. Most wireless systems use radio frequency (RF) or infrared (IR) wavelengths. Generally, in proximity-based wireless systems, devices with transceivers must be within reach (proximity) of other devices in order to establish and maintain a communication channel. The device can also be a hub for connecting other devices to a wireless local area network (LAN). [0266]

As mentioned above, embodiments of a distributed computing environment provide a mechanism for clients to use lookup space to rendezvous with services. In a proximity computing environment, one embodiment of a distributed computing environment provides a service discovery mechanism that clients use to discover services without using lookup space as a rendezvous point. An example of a proximity computing environment is the IrDA point-to-point communication environment. In a proximity computing environment, the proximity mechanism can find the "physical" location of the service with respect to the client. For example, in an IrDA environment, a client device physically refers to the device that contains the services that the client wants to use. [0267]

The proximity service discovery mechanism allows clients to request service notifications directly instead of sending search requests to the lookup space to request service notifications. Since the client device has established a proximity connection to the service device, the client can directly request the desired service. For example, a PDA client device may have a close connection with a printer device, and the client "knows" that the printer on the printer device requests a service connection. [0268]

In one embodiment, the client can send a proximity service discovery message to the service device. The message contains information that specifies the desired service of the service device with which the client device makes a proximity connection. In one embodiment, the service on the service device responds to a proximity service discovery message and sends the client a service notification that the client uses to connect to the desired service. The proximity service discovery message further contains information used to authenticate the client and establish the client's capabilities in the service. When using the received service notification, the client can establish a gate to establish communication with the desired service. However, it is desirable to publish notifications for services that do not want or cannot maintain notifications in a widely accessible space. In one embodiment of a distributed computing environment, a device that establishes a connection with a device that does not publish service notifications, such as a proximity-based device, can publish service notifications received from non-publishing devices. For example, a device that establishes a connection with a proximity-based device and sets up an alternative transport connection publishes (or republishes) service notifications received from the proximity-based device in the alternative transport environment, and the proximity-based device. Make the service available to other devices outside the device's normal proximity (through (re) published service notifications). [0269]

The publishing device identifies the locally published service on the proximity-based device through discovery and / or lookup services, or separately, the local service device does not publish the service notification, Instead, the local device sends the service notification to the publish device after the connection is established, as described above. In one embodiment, republished service notifications can be enabled as long as the device that maintains the notification is connected to or is able to connect to the local device. For example, if the publish device is disconnected from the local device (for example, moving out of the device's proximity), the service notification will be stale or deleted. A leasing mechanism can be implemented that allows the space containing the notification to send a lease renewal message to the publishing device. The publish device verifies the connection with the local device, which allows the space to detect when the local device becomes unavailable. A local device or management policy provides rules for republishing service notifications to a local neighborhood (for example, a neighborhood area) or a local network. FIG. 24 shows a device that bridges a neighborhood-based device to another transport mechanism that, in one embodiment, allows services provided by the neighborhood-based device to be accessed by a device that is outside the neighborhood of the device. It is a figure which shows an example. Publish device 1404 is Ethernet Connect to a network 1412, such as a LAN or the Internet, and establish and maintain a proximity connection 1414 with proximity devices 1400 and 1404. The proximity connection can be, for example, a wireless connection or a wired LAN connection. Proximity devices 1400 and 1402 send post-connect service notifications to publish device 1404, respectively, or separately, the publish device discovers and / or uses the lookup service to send service notifications to the proximity connection. Identify. Publish device 1404 makes the service provided by the proximity device available to other devices 1408 and 1410 on the network 1412 by republishing service notifications 1416 and 1418 in space 1406. Space 1406 can be stored on a publish device or other device connected to the LAN, including devices 1408 and 1410. [0270]

Other devices on the LAN, including devices 1408 and 1410, discover space 1406, look up republished service notifications 1416 and 1418 for proximity-based devices, and use the XML message passing method described above. Establishes dating communication with these services (device 1404 acts as a proxy or bridge) on proximity-based devices 1400 and 1402, sending requests to and receiving proximity devices. Publish device 1404 acts as a bridge between network 1412 and proximity connection 1414 to proximity-based devices. [0271]

lease Leasing is used in a distributed computing environment to handle partial failures, resource synchronization (scheduling), and to carry out an orderly resource cleanup process. Leasing allows you to manage independent clients and services that travel across your distributed system. Various resources that clients get from services (including space services) can be leased from these services. In general, not all resources can or need to be leased. In one embodiment, the decision of which resource needs to be leased is left to the implementation of each particular service. In particular, resources used by large numbers of clients may not require leasing at the same time, or instead may require a custom leasing protocol. The class of such leases is left to the service provider. Custom protocols, such as those that implement transactions, can be built on the basis of a basic leasing method. In one embodiment, the basic lease model is a relative time-based model. [0272]

The service issues a lease to the client and performs operations on the lease. In one embodiment, all such leasing features of a service are part of the service's XML Schema. Therefore, the client can use that gate (corresponding to the service and built against the service's XML schema) to perform the lease operation. In one embodiment, all services that issue a lease are (i) renewal of the lease (specified parameters of the lease (eg, lease ID, lease certificate), new lease time requested), and (ii) lease. You can perform two lease operations (only available by the owner of the lease): the specified parameters of the lease (for example, the lease ID, the lease certificate). In one embodiment, all leases are negotiable specifics. Approved for relative time (duration of lease). A requester may specify a time (for example, in seconds) and a grantor may approve the lease until that time elapses. So, if you set the value to -1, you can specify an indefinite lease. [0273]

In one embodiment, the service notification may include one or more lease addresses. In one embodiment, the lease address can be a URI. A standard lease message to renew or cancel a service resource lease can be sent to the lease URI. Lease URI example: &lt;leaser&gt; service1: // resource1 &lt;/ leaser&gt; [0274]

The notice further includes various lease messages, as described above. The lease message can include a message to renew the lease for a resource of the service and a message to cancel the lease. In one embodiment, the notification can also include the message in XML Schema. [0275]

The leasing mechanism provides a mechanism for detecting service and client failures. Leasing also provides a mechanism for achieving shared and exclusive resource access. In one embodiment, all service resources are unleased (resources are not leased and therefore unavailable), shared resources (resources are accessed by multiple clients), or exclusive leases. Either (the resource is accessed by only one client at a time). In one embodiment, all resources start with no lease. The absence of a lease means that the underlying resource is currently inaccessible, indicating that the resource interest exists and is available for lease. The lease level can be increased from "none" to "shared", from "none" to "exclusive", or from "shared" to "exclusive". The lease independence level can also be lowered from "exclusive" to "shared", from "exclusive" to "none", or from "shared" to "none". In one embodiment, the client may voluntarily raise or lower the lease independence level or require the service to do so. The response message from the service indicates whether the independent level change was accepted. [0276]

Request-response message pairs can be used to claim, release, and renew leases. Tag each message with a reserved XML tag to indicate that the message is a leased message. In a distributed computing environment, it does not necessarily define the complete composition of messages. In such an embodiment, the service developer can add custom message content as long as the message is tagged as a leased message. [0277]

In one embodiment, a client using a leased resource (i) bills the resource as shared or exclusive, (ii) releases the resource bill (when requested or terminated with the resource), and. (iii) It is expected to either respond to the update message (by other claims of the same or different independent level). Update messages are sent by the service (for example, at regular intervals) to detect client failures. This interval (update messages are sent) is service specific. If no response to the update message is issued after a certain amount of time (for example, based on the time notified in the service notification), the resource reuse process begins within the service and completely relinquishes its lease. In such an embodiment, the update message sent to the client should be handled in a timely manner. Figure 25 shows how to use the update message between the client and the instantiated service, and the update message between the service provider and the space service. Both can be thought of as the use of update messages between the client and the service, but note that the service provider is the client to the space notification service. [0278]

Update messages arrive in an "out-of-band" fashion, which is inconvenient for clients. This means that the client cannot predict when the update message will be sent by the service. Out-of-band message processing complicates client logic and increases its complexity. To solve this problem, implement an automatic lease renewal mechanism to reduce the effort of clients who need to handle out-of-band messages and reduce client complexity. The automatic lease renewal mechanism allows each gate (message, method, and / or event gate) to receive a renewal message and automatically respond to it without the help of a client. The default response to a renewal request is to claim a lease at the current level. Each message gate can contain a single reserved update response message that is automatically sent to the notification space service when the gate receives an update message. This "out-of-band" message is processed on behalf of the client, creating a clean client programming model. In one embodiment, the gate allows the client to register a lease event handler and specify a different level of independence in the response message. [0279]

The leasing mechanism also includes a mechanism for detecting stale (invalid) notifications. When a service publishes a notification in space, the service gets a lease based on it publishing the notification. Each notification describes the time the service promises to update the notification. In one embodiment, all timeout values are specified in seconds. If the service continues to renew its lease, make sure that the space does some confirmation that the notified service is still available. The update time is counted down to zero by the space service. If the service does not renew the lease, the service may be failing, or is no longer available or is no longer available. If the lease is not renewed, the space service will be stalled in the service notification and will not be available to clients. The service updates the notification by sending an update message to the space. The space service receives these messages and resets the notification update time to the default value. [0280]

In one embodiment, the stale status notification is not automatically deleted. Depending on your space policy, you can choose to remove stale service notifications that have expired for a long enough period. The deletion policy can be set in the space service. The space service searches for stale status notifications and, for example, removes them or informs the administrator. [0281]

Space services can use leases to manage the resources provided by their capabilities to clients of the space, including other services. For example, if the client wants to use the service, the space service requires the client to lease it as part of the instantiation of the service. When performing a service instantiation, the client can run the service. To instantiate a service, the client first selects one of the service notifications published in the space. Clients can use the various features provided by the space to look up notifications in the space. The client then requests the space to instantiate the service. The lease obtained when the service was instantiated is the one when the service notification was used (not the same as the lease when the service notification was published). It should be noted that space services allow multiple clients to lease for the use of service notifications in the case of shared notifications. Otherwise, Space Services only leases one client at a time for service notifications (exclusive). [0282]

Another example of a space service using leases to manage the resources that its functionality provides to clients is when an XML document (for example, a service notification) is added to or removed from the space. The space client may register to notify you of this. Space registration clients can get a lease on this subscription to notifications. This lease allows Space Services to know if it will continue to send notifications. Such a lease would not be needed if the client had an active session with the space. Also note that when a space client (which may be a service) establishes a session with the space, the client can take a lease in that session. Therefore, the space can manage the resources associated with the session. [0283]

In other embodiments, the distributed computing environment employs a non-time-based leasing mechanism. This lease is generated when the object is billed for use. Instead of a time-based mechanism, the billing method accepts a callback that informs the current leaseholder that some other party wants to access the same object (for example, a service). Therefore, as another embodiment for time-based leasing, the client can instead make a claim for a space object (eg, a service). If another client wants a lease that is incompatible with the current leaseholder's lease, the service sends a "callback message" to the client. Upon receiving the callback message, the client (that is, the client gate) calls the callback method to decide whether to respond to the callback message (suspend lease, cancel lease, access level). Change to shared, etc.). Once the response is determined, the client gate sends a response message to the service. Such a distribution mechanism for managing leases can be implemented using the XML message communication layer. [0284]

In non-time-based leasing embodiments, the distributed computing environment provides leasing that supports multiple levels (or types) of access, which allows distributed algorithms to determine lease compatibility. Levels include (i) keepInSpace, (ii) read objects in space (readShared), and (iii) read exclusive objects in space (readExclusive). is there. [0285]

Authentication and security The distributed computing environment supports naturally occurring distributed systems and heterogeneous distributed systems based on asynchronous message communication models, and data and / or objects can be represented in a representation language such as XML. In a distributed computing environment, for example, clients can connect to services throughout the Internet. In a distributed computing environment, a large number of network devices work together in a secure, reliable and dynamic way. The distributed computing environment defines protocols that effectively enable interoperability between compliant software components (clients and services). [0286]

In the context of a distributed computing environment, a device is an addressable unit in a networking transport. Clients and services can be implemented as Universal Resource Identifier (URI) addressable instances of software or firmware running on the device. [0287]

Many content points are located in the Internet space. A URI is the method used to identify a content point and is a page of text, a video or sound clip, an image, software, firmware, or other Internet content. The most common form of URI is a web page address, which is a particular form or subset of a URI called a Uniform Resource Locator (URL). A URI usually describes a resource, the particular computer on which the resource is located, and the mechanism used to access the particular name (usually the filename) of the resource on the computer. [0288]

Clients and services (both can be implemented as software and / or firmware on the device) can be connected over the Internet, corporate intranets, dynamic proximity networks, within a single computer, or through other network connectivity models. For example, the size and complexity of devices that support clients and services can range from simple lighting switches to complex high availability servers. Examples of devices include, but are not limited to, PDAs, mobile phones, notebook computers, laptop computers, more powerful PCs, even more powerful computer systems, and even supercomputers. There is. In some embodiments, client and service distances, latency, and implementations are abstracted and common discovery and communication methods are used to create a "black box" effect. With this definition method, software implementation problems can be handled by the core platform, and a coarsely coupled system that can be scaled up and down according to the scale of the Internet can be realized. [0289]

Distributed computing environments provide Internet-centric programming models such as web and XML content representation, dynamic device discovery, and secure device communication accessible from a variety of network devices. The distributed computing environment includes a network programming model that is abstracted above the CPU level. This programming model has the following characteristics. URI address Strongly typed data called content (addressed by URI) Virtually unlimited persistent content storage (for example, store) (including XML and non-XML content, such as those identified by MIME type) Virtually unlimited temporary content memory (including XML content) called spaces Descriptive XML metadata (data about data) content notifications that can be stored in spaces to notify the clients involved. Virtually unlimited number of instructions (embedded as messages) A secure message endpoint (gate) addressed by a URI Data flow support for coordinating workflows between distributed software programs (event messages) [0290]

Services and clients can run as programs within a distributed computing environment. The service can notify the client who wants to use the service of the function. The client may or may not reside within the same network device, and the device's code execution environment may or may not support the Java platform. Distributed computing environments are a powerful method of addressing when addressing content and message endpoints using URIs. The address allows you to specify the location of the content or endpoint and also the route (or transport protocol) to use. Items addressed using URIs also have an associated security certificate. Security certificates can be used to control what clients are allowed access to an item and what operations are allowed on the item by authorized clients. [0291]

The advanced access provided by the distributed computing environment can be controlled by appropriate authentication and security systems and methods. Authentication and security in a distributed computing environment includes verifying the typing of XML content in a message, safely identifying the sender to the recipient, sending from client to service, and vice versa. There is a mechanism to check the integrity of the message to be received, and a mechanism to describe the message group of the service received by the client and enforce the message request condition for the message received by the service. The security and authentication features described above can be leveraged in a single atomic unit of code and data. You can dynamically create atomic units of code and data. In one embodiment, code and data atomic units, once created, represent message endpoints (gates) and cannot be modified with respect to the security and authentication policies implemented at the time of creation. [0292]

A gate represents an authority to use some or all of the functions of a service. Each function can be represented with respect to a message that can be sent to the service. Gates can also be used to detect when a client fails when leasing a resource. [0293]

Authentication and security are also authorized that the client attempting to use the service is authorized to use the service and that the space to which the client receives the service notification is authorized to provide the service notification. , And / or a mechanism can be provided to verify that the service notification itself is approved. [0294]

Message communication can be implemented at the messaging layer as a means of communicating a request from a client to a service and as a means of the service responding to the client with results. The messaging layer of a distributed computing environment can provide a mechanism that effectively guarantees that valid XML messages are sent and enables a language-independent security model. At the messaging layer, you can link the sending message endpoint to the receiving message endpoint. Two related message endpoints can provide a secure, two-way atomic message channel suitable for request-response message communication between the client and the service. [0295]

In an embodiment of a distributed computing environment, notifications can be published in space for services. The notification can be an XML document containing the service's XML schema and URI. The service can also include a service ID token or certificate in the notification, and the notification can specify the authentication service used by both the client and the service. The client then identifies the service notification for the space and uses that notification to instantiate the message gate on the client. The client uses the authentication service specified in the notification to obtain an authentication certificate to send to the client in the message. In one embodiment, the client passes a service ID token or certificate from the service notification to the authentication service, which in turn uses the service token and / or certificate to generate an authentication certificate for that client. Can be done. In one embodiment, the client comprises a gate factory that receives the information needed to create the message gate, which builds the message gate, communicates with the authentication service, and the client's authentication certificate. To get. The corresponding service message gate is instantiated on the service side. [0296]

At some point, the client sends a first message to the service. In one embodiment, the client message gate embeds the client's authentication certificate built by the authentication service in the message. When the service receives the message, it uses the same authentication service to validate the authentication certificate received in the message. By sharing the same authentication service, various authentication protocols can be adopted, and the details of authentication certificate generation can be separated from the client and the service. Therefore, clients can use different authentication certificate protocols with different services. [0297]

In one embodiment, the authentication service can determine the client's capabilities after first receiving a client authentication certificate from the service (eg, what the client is allowed to do with the service). The client's ability is bound by the client's identity. The client's message gate then embeds a certificate of authentication in every message sent by the client to the service. The message arrives at the service message gate, where it is checked by the authentication service to ensure that the message is from the client and that the message request is within the client's capabilities. In another embodiment, the service message gate determines the capability and processes the message check on the capability without using the authentication service. [0298]

Clients and service message gates work together to provide a secure and reliable message channel. The gate is used as a secure message endpoint, allowing clients to perform services by sending and receiving secure and authorized XML messages to and from the service. [0299]

Operations within a distributed computing environment are implemented as XML messages sent between clients and services. The protocol used to connect the client to the service and address the space and content in the store is defined by the messages that can be sent between the client and the service. Defining a protocol using messages allows different types of devices to participate in the protocol. Each device is free to implement the protocol in a way that best suits its capabilities and roles. [0300]

The functionality of a service can be represented in the messages it accepts. The service message set can be defined using XML Schema. The XML message schema uses XML-typed tags to define each message format. Tag usage rules can also be defined in the schema. The message schema may be a component of XML notification along with the message endpoint (gate) of the service used to receive the message. Extensions (and more capabilities) can be added to services by adding messages to the XML message schema. [0301]

In a distributed computing environment, authorized clients can use all of the service's capabilities or are limited to using a subset of the service's capabilities. In one embodiment, after giving a set of features to a client, the client cannot modify the set without proper approval. This feature definition model allows for service levels from basic feature sets to extended feature sets. [0302]

When performing a service instantiation, the client can run the service. To instantiate a service, the client first selects one of the service notifications published in the space. Clients can use the various features provided by the space to search for notifications in the space. The client then requests the space to instantiate the service. Service instantiation includes, but is not limited to: 1. The client requests the space service to instantiate the service. 2. The space service verifies that the client is allowed to instantiate the service. 3. The space service acquires a lease in the client's service notification at the lease request time specified by the client. Separately, service notifications can be sent to clients and do not use a leasing mechanism. 4. The space service sends a message to the client containing the lease and service notifications assigned in step 3. 5. The client executes the authentication service specified in the service notification and obtains the authentication certificate. 6. The client builds a client message gate to communicate with the service. Use a set of dynamically generated numbers (keys or tokens) as client security or authentication certificates to build trust between clients and services in a distributed computing environment. You can use one or more certificates to verify the client's authority to use the service and the messages exchanged between the client and the service. Each client and service has its own certificate. [0303]

The type of authentication certificate required to use the service is returned to the client performing the service search. In one embodiment, the authentication certificate is a hidden object that the client must present each time it uses the service. In one embodiment, the certificate of authentication is presented by the message gate for the client in every message sent to the service. No matter what kind of authentication certificate the service requires, by using an authentication service external to the client and service, the client and service need not be aware of the authentication certificate structure or authentication process. [0304]

The certificate of authentication can also include a transport-specific ticket in addition to the service ticket. When running a service, the transport can provide a secure connection, depending on the networking transport specified in the service notification. In some cases, if the data link layer is already secure, then it may not be necessary to use a secure transport on the already secure data link layer. [0305]

The concept of authentication certificates is abstract enough to allow different levels of security based on the certificate implementation. The levels of security are not limited to them, but include: 1. None (empty message has no security certificate or no certificate) When security is enforced by the physical connectivity characteristics of the transport, a message with an empty certificate or no certificate is sufficient. For example, a smart light switch connected to only one light switch controller is safe because the switch is wired in a safe way. 2. Signature message (electronic signature) Signature messages include electronic signatures that allow the service to verify the origin (client) of the message. 3. Encrypted message (handle this in transport) Encrypted messages add another level of security by scrambling the content of the message so that it must be descrambled with another certificate. 4. Capability message (service function and user recognition) This level of security provides per-user security features (eg, those that the user is allowed to perform) and allows precise access control for services and individual service features. [0306]

Use multiple levels of security zones due to the heavy implementation required to achieve a high level of security (capacity and encryption). If Message Transport supports (or assists in boating) these levels of security, a security level bridging service that leverages this support to bridge from one level of security to the other. I will provide a. [0307]

As mentioned above, services without a security model can accept empty authentication certificates. For services with unrestricted access, gates can be built without a certificate or with an "empty" certificate. Gates for such services either do not send a certificate of authentication with each message, or send an empty certificate. The authentication service is an example of a service that does not restrict access. Other services require a user ID / password pair. [0308]

Authentication of service access using certificates In some embodiments, the client attempting to perform the service is verified to be an authorized client, the service notification received by the client is verified to be an approved service notification, and / or the client. The mechanism by which the sender's space that received the service notification is approved is based on the public / private key asymmetric cryptosystem. In this mechanism, the authorized shipping entity embeds the public key in the message and encrypts the message containing the public key with the private key. The entity that receives the encrypted message decrypts the message using the public key, finds the same public key embedded in the decrypted message, and verifies that the message is from an authorized entity. But that's because only that entity has the private key needed to encrypt the message. The entity then issues a certificate that is virtually unforgettable and can be decrypted (with the proper public key) by another entity to validate the message sent by the entity. [0309]

Various key generation algorithms can be used in a distributed computing environment. The key configuration is hidden from both the client and the service, regardless of what key generation algorithm the client and service use. [0310]

The Kerberos ticket is an example of a security certificate used in a distributed computing environment. Kerberos is a secure way to authenticate requests for services in a computer network. Kerberos allows users to request an encrypted "ticket" from an authentication process that can be used to request a particular service. The user's password does not have to go through the network. [0311]

In a distributed computing environment, it provides a mechanism that effectively guarantees that the quality of messages sent between clients and services is not compromised. In one embodiment, the sender embeds a token containing information that the recipient can use to verify that the message has not been modified. There are several ways to generate information to embed in a message. In one embodiment, the hash of the message is calculated and sent with the message. The hash method involves converting a string into a normally short fixed-length value or key that represents the original string. Upon receiving the message, the recipient recalculates the hash and checks against the hash sent. If the message has been modified, it is unlikely that the same hash will be generated. The sender encrypts the hash and sends the corresponding public key in an encrypted message, effectively guaranteeing that the hash is not compromised. [0312]

In other embodiments, an error detection method such as cyclic redundancy check is used. Cyclic redundancy check is a method of checking whether there is an error in the data sent by the communication link. In an embodiment that uses a cyclic redundancy check, the sender applies an n-bit polynomial to the message and appends the resulting cyclic redundancy check (CRC) to the message. The recipient applies the same polynomial (which is also passed in the message) to the message and compares the result to the result added by the sender. If there is a match, the message was successfully received. If there is no match, the sender will be notified to resend the message. [0313]

Since the gate factory is "trustworthy" code, the gate factory also plays a role in security. By generating a gate using a trusted gate factory, you can ensure that the gate is a trusted code and that the code is correct for service notifications. The client must present the client ID token or certificate to the gate factory as a means of authentication. The service presents the service ID token or certificate to the client when the client creates the gate (for example, through notification). As described here, the client and service token pair is used to create a third certificate that is used to allow the client to send messages to the service. This third certificate is called an authentication certificate. The authentication certificate is created by the authentication service when the authentication process runs. In one embodiment, the service is free to use the authentication policy. In one embodiment, the authentication service manages the authentication policy on behalf of the service, so the service does not need to be aware of the specific authentication policy being used. [0314]

The client builds the gate using the authentication certificate received by executing the authentication service specified in the service notification. This allows the constructed gate to send an authentication certificate to the service along with its respective message. When the service receives the first authentication certificate from the client in the first message, the service authenticates the client using the authentication service specified in the service notification and binds the authentication certificate to the client's ID. Establish. [0315]

As already mentioned, some results output by the service are communicated in space and eventually accessed using the result gate. The result gate may or may not contain the same security certificate as the input gate used to generate the result. Since the input to the service is asynchronous with the output (result), the result is associated with a different set of permissions. For example, in the payroll service, different groups of clients can activate the payroll service to read the results (payroll) of the payroll service. Therefore, the client must apply another authentication process to gain access to the result, including receiving an authentication certificate for the result from the authentication service specified in the notification about the result. .. [0316]

Message Gate removes most security check burdens from the service. Services allow you to focus on demonstrating your capabilities and authenticating your clients. The principle of minimizing privileges is adhered to when allowing clients to access only the requested (or assigned) capabilities. [0317]

Security checks are performed when the gate is created and / or when the gate is used (when sending and / or receiving messages). The gate creation process begins when the client requests access to the notified item (service). In this process, the client gate factory works with the service to authenticate each other. The checks performed when creating a gate are widespread, minimizing the number of checks performed when using a gate. After authenticating a client with a service, the service determines a particular ability of the client (for example, what the service allows the client to do) and associates that ability with the client's certificate of authentication. be able to. These particular capabilities allow you to specify what operations a client is allowed to perform on a service. The gate verifies that every message contains a certificate of authentication, so the service can check each request upon receipt against the capabilities of the authenticated client. [0318]

The gate creation check ensures that the client has permission to use some or all of the service capabilities specified by the XML message schema. In one embodiment, these checks are performed using an access control list (ACL) with an authentication service such as Kerberos. Challenge-Response sequences (such as passwords) can also be used to authenticate clients. In some embodiments, a hardware-based physical identification method can be used to authenticate the client. For example, the user can provide a physical identification function such as a smart card for identification and approval. Other mechanisms for authentication can also be used in other embodiments. [0319]

In one embodiment, no matter what means is used to authenticate the client, the authentication is invisible to both the client and the service, recognizes the authentication service used by the gate factory, and authenticates the authentication service. Handles authentication mechanisms and policies. Gate factories are product and environment dependent or can even be controlled by a configuration management system. In one embodiment, the degree and method of client independence is platform dependent, but is recognized by the gate factory. In some embodiments, a hardware-based physical identification method can be used to authenticate the client. For example, the user can provide a physical identification function such as a smart card for identification and approval. Other mechanisms for authentication can also be used in other embodiments. [0320]

Message gates in distributed computing environments are typically associated with a single client. The gate factory determines the means of association. A check performed when sending a message confirms that the appropriate client is using the gate. In one embodiment, the gate is passed in a message and cloned if a new client wants to use the gate. The cloning process runs a new set of creation checks. [0321]

When a space client finds a space service notification (the client may be another service), the space client runs the space service as it does for any other service. To run the space service, you need to use an authentication mechanism. Running a space service, but is not limited to, does the following: 1. The Space client first executes the authentication service specified in the Space Service service notification to obtain an authentication certificate. 2. The space client uses the space's authentication certificate, the space's XML schema (from the space's service notification), and the space's URI (from the space's service notification) to build the space's gate. In one embodiment, the client passes information for building the gate to the gate factory. 3. The space client executes the space service by sending a message to the service using its gate. 4. When the Space Service receives the first message from the client with the embedded certificate, it gets the certificate to authenticate the client using the same authentication service that the client used. , Confirm the identity of the client. 5. The space service then determines the client's capabilities (for example, those the client is allowed to run on the space service) and binds those capabilities to the certificate of authentication. [0322]

As described in the "Spaces" section, the space feature can include an interface that creates an empty space that has substantially the same functionality (same XML schema) as the source space. [0323]

FIG. 42 is a flow diagram illustrating the protected creation of a new space in a distributed computing environment according to one embodiment. As shown in 1950, the client can access (eg, connect to) the first space service (the service can act as a client with respect to access or other forms of use of space). .. As shown in 1952, a client can request the creation of a second space, such as by sending an appropriate request to the interface of the first space. A client that requests the creation of a space (including a service that acts as a client of the space service) may be referred to as the requesting client. In response, a second space service associated with the second space can be created at the second internet address, as shown in 1954. As above, the second space service can include a second schema that specifies one or more messages that can be used to call the functions of the second space service. The second schema can contain at least the first schema, and the second schema can also include additional functionality. [0324]

The second space can initially be configured to allow access only to the requesting client. In one embodiment, a root authentication token is created for the second space, as shown in 1956. The authentication service associated with the second space can be initialized, also as shown in 1956, so that the second space is only allowed access to clients holding the root authentication token. Configure to. A root authentication token can be sent to the requesting client or service, as shown in 1958. As shown in 1960, the requesting client sends at least one of the messages specified in the second schema to the second space, by using the root authentication token, in the second space. Can be accessed. [0325]

Therefore, in one embodiment, when the requesting party creates a space, only the requesting party is allowed access to the created space. For example, save the created space can be used to store the result of that is protection from the service that the client needs. In one embodiment, this security can be guaranteed by: · As shown in 1956, when creating an initial root authentication token and initializing the authentication service for the generated space, the authentication service only authenticates the root authentication token and does not return any other authentication certificate. (No other client has the first allowed generated space). -Initialize the security policy of the generated space so that the root ID associated with the root authentication token can access all functions of the space, including security management functions. Return the root authentication token and the service notification for the generated space to the requested space for the generated space, as shown in 1958. [0326]

The requester builds a gate to access the generated space because it returns a certificate of authentication and a service notification for the generated space. In one embodiment, only the client or service that the requester and requester pass the certificate of authentication and the service notification of the generated space can access the generated space. This restriction of access to the generated space is, for example, when the client and service use the generated space to store the result when the client and service keep the result private. Useful for. [0327]

After running the service, the client modifies the authentication policy for the generated space using the Security Managed Spaces feature, after which other clients or services can access the generated space. In addition, use discovery protocols or other means to make service notifications for the generated space available to other clients of the generated space (other clients may be services). [0328]

The message transport layer in a distributed computing environment provides a mechanism to protect the security and security of communication between clients and services during transport. Such security is called "wire security" or "transport security", which distinguishes it from the authentication security implemented by messaging systems, including gates. Message encryption is done at the message transport layer in a distributed computing environment. Services that require encrypted transport do so by tagging XML notifications. The gate factory then creates a gate (or multiple gates) that uses a secure message transport, such as that provided by Bluetooth or HTTPS. [0329]

HTTPS (Secure Hypertext Transfer Protocol) is a web protocol that encrypts and decrypts user page requests and pages returned by web servers. HTTPS uses a multi-bit key size (40-128 bits or more) for its stream cipher algorithm (eg RC4) to provide sufficient encryption for commercial data exchange. HTTPS can be used as a transport in a distributed computing environment. [0330]

Bluetooth is a new peer-to-peer wireless communication standard. Bluetooth key generation algorithms can be used in a distributed computing environment. Bluetooth supports encryption keys. Cryptographic keys are transport-dependent, while client, service, and combination keys can be transport-independent. [0331]

Figure 26a-Authentication service that provides authentication certificates to clients FIG. 26a is a flow chart showing an authentication service that provides an authentication certificate to a client according to one embodiment. Clients in a distributed computing environment may require services that perform one or more functions on behalf of the client. One embodiment provides an authentication service used by clients and services when setting up a secure messaging channel. The authentication service performs functions on behalf of the client and / or service, such as authenticating the client and / or service, providing the desired level of security, and negotiating the set of messages passed between the client and service. The authentication service may be a process running within a distributed computing environment. The authentication service runs on the same device as the service and / or client, or separately, the authentication service runs on another device, such as an authentication server. In one embodiment, the authentication service is an internet-based service. The authentication service has its own address, for example, Universal Resource. It has an Identifier (URI) that allows clients and / or services to communicate with the authentication service. In one embodiment, the address of the authentication service is provided to the client in the service notification of the service. Clients and services that share authentication services allow you to establish a secure messaging channel between the client and service and use any of several security and authentication protocols in the messaging channel. [0332]

In one embodiment, the client presents the client ID token or certificate to the authentication service. The client token or certificate is sufficiently memorable and can be used as proof of client identity. The authentication service then checks the client ID token or certificate and issues the client an authentication certificate that only the authentication service can create. The certificate returned to the client is then sent by the client to the service in all messages. In one embodiment, the client message gate is created by the gate factory, and when the authentication certificate is stored in the message gate, the message gate sends the authentication certificate to the service on behalf of the client in all messages. .. Upon receiving the message, the service checks the authorization certificate. Since only the authentication service can create the authentication certificate, the service recognizes that the client has not tampered with the authentication certificate. In one embodiment, the service passes the authentication certificate to the same authentication service used by the client, verifies that the authentication certificate is valid, verifies that the client is an authorized client, and identifies the client. To find out. [0333]

All services, including space services and authentication services, can authenticate their clients. Once the service authenticates the client, the client can access the service. For example, in the case of a space service, the client gets an XML notification from the space. [0334]

In one embodiment, the service provides a pre-prepared certificate for use by all clients of the service. In this embodiment, authentication provides the requesting client with its pre-prepared certificate. The client presents the pre-prepared certificate to the service and the service approves it. [0335]

At step 1000, the client requests an authentication certificate from the authentication service. In one embodiment, the client searches for and identifies service notifications for the service of interest. In one embodiment, the service notification includes a notification of the authentication service used to obtain an authentication certificate used to access the service. In one embodiment, the service notification includes an address such as a URI of an authentication service. In one embodiment, the client sends information to an authentication service that requires an authentication certificate. In one embodiment, the client sends information to a gate creation process, such as a gate factory, which accesses an authentication service to obtain an authentication certificate. [0336]

At step 1002, the authentication service generates an authentication certificate for the client. The certificate of authentication can be embedded in the message of the messaging system, which allows the recipient of the message to authenticate the sender of the message, verify that the message is from the authorized sender, and send the message. A data element or structure that allows a party to verify that it is a message that is allowed to be sent to the recipient. In one embodiment of a distributed computing environment, the authentication certificate is unique to the messaging channel set up between a particular client and a particular service. Step 1002 is illustrated and described in detail in Figure 26b. In step 1004 of Figure 26a, the authentication service returns the authentication certificate to the client. In one embodiment, the certificate of authentication can be returned directly to the client. In one embodiment, the certificate is returned to a gate creation process, eg, a gate factory, which process then uses the certificate to generate the gate. [0337]

Figure 26b-Authentication service that generates authentication certificates FIG. 26b is a flow chart showing an authentication service developed in step 1002 of FIG. 26a to generate an authentication certificate according to one embodiment. In step 1002a of one embodiment, the authentication service obtains a client token and a service token. In other embodiments, the authentication service obtains only the client token. In one embodiment, the client token is a unique identifier for the client in a distributed computing environment. In one embodiment, the service token is a unique identifier for the service in a distributed computing environment. For example, the public key of a public / private key cryptosystem can be used as a unique identifier for clients and services. In one embodiment, the client receives the service token in the service notification and the client sends the client token and the service token to the authentication service. In another embodiment, the client sends the client token and the service notification URI to the authentication service, which can retrieve the service token from the service notification. [0338]

At step 1002b, the authentication service validates the client and / or service. In one embodiment, the authentication service uses the client token and service token obtained in step 1002a to validate the client and / or service. In another embodiment, step 1002a gets only the client token and 1002b uses only the client token to validate the client. In one embodiment, the client has already registered its client token with the authentication service, and the authentication service compares the received client token with the registered client token to see if the client is a valid client. Can be verified. In one embodiment, the client can access the authentication service using a challenge / response mechanism such as a password-protected logon account to validate the client as a valid client. In one embodiment, the service is already registered with the authentication service and its service token is provided to the authentication service. The authentication service then compares the received service token with the service token already registered to verify that the client is trying to access a valid service. Other types of client and service authentication can also be used. For example, the client provides an electronic signature or electronic certificate that the authentication service can use to authenticate the client and / or to authenticate the service that the client is trying to access. [0339]

At step 1002c, the authentication service generates an authentication certificate. In one embodiment, the authentication certificate includes an authentication token that can only be created by the authentication service. In one embodiment, the authentication service uses a client token and a service token to generate an authentication certificate. In other embodiments, the authentication service uses only the client token to generate the authentication certificate. In yet another embodiment, the authentication service does not use the acquired talk to generate the certificate, but instead uses a certificate generation algorithm to provide a certificate that is virtually unforgettable. Can be generated. In one embodiment, the authentication service combines a service token with a client token to generate a unique authentication certificate. For example, a service token and a client token can be 64-bit values, and the two tokens can be combined to generate a 128-bit authentication certificate. In other embodiments, other methods can be used to generate the certificate of authentication. [0340]

How to bridge devices to a distributed network environment Devices that do not support the message communication model implemented in a distributed computing environment are outside the distributed computing environment. These devices may have services that may be useful to clients in a distributed computing environment. The distributed computing environment provides a mechanism for bridging such external devices into the distributed computing environment. Clients in a distributed computing environment can access the services provided by such devices. Distributed computing environments can also leverage existing device discovery protocols to discover such external devices for use in distributed computing environments. [0341]

Many technologies define discovery protocols for publishing and monitoring device configurations in networks. These technologies include, but are not limited to, Jini, SLP, Bluetooth, and UPnP. In addition, many I / O buses such as LonWorks, USB, and 1394 also support dynamic discovery protocols. In a distributed computing environment, device discovery technology is utilized by wrapping the implementation with APIs. By leveraging other device discovery protocols and using methods of bridging to other discovery protocols, devices or services on various networks and I / O buses can be discovered in a distributed computing environment. Device discovery in a distributed computing environment can therefore be applied to a variety of devices, including small devices such as PDAs, without having to participate directly in the distributed computing environment. Discovery protocols can be defined at the message level. [0342]

The bridging mechanism is provided as a messaging API for distributed computing environments that "wraps" one or more specific device discovery protocols, such as Bluetooth. Wrap creates a framework for device discovery protocols in code and / or data (APIs) that allows the protocol to be executed by clients and / or services within a distributed computing environment, otherwise this cannot be done. The bridging mechanism allows discovery agents that discover devices with specific device discovery protocols to publish services to devices in the space of a distributed computing environment. The service can present an XML message schema interface to clients in a distributed network environment to run a variety of devices discovered by a particular device discovery protocol. Therefore, service notifications are published to services running various devices discovered by the underlying wrapped device discovery protocol. The notified service then bridges devices (or services) outside the distributed network environment to clients on the distributed network environment. [0343]

FIG. 27 shows an embodiment of a distributed computing environment with a space of 1200. One or more discovery agents 1204 participate in the external discovery protocol and bridge to the distributed computing environment through the bridge mechanism 1202. When running the wrapped device discovery protocol, discovery agent 1204 via the bridge mechanism 1202 publishes service notifications 1206a-1206c in space 1200, where each of the notifications 1206a-1206c goes out of the distributed computing environment. Corresponds to a device or service discovered by one of the discovery protocols 1204. The client then uses the service notifications 1206a-1206c in space 1200 to access the external device and instantiate the service with one of the corresponding external devices or agents 1204 running the service. [0344]

Clients in a distributed computing environment then use a discovery agent that wraps the device discovery protocol to find the device. Publish and notify services in the space that act as bridges to these devices so that clients in a distributed computing environment can access the services provided by external devices. The notified service is a service within a distributed computing environment that can call devices outside the distributed computing environment by other protocols or environments, bridging the external devices / services to the distributed computing environment. Clients in a distributed computing environment only "see" the notified services in a distributed computing environment and do not even notice external devices / services. [0345]

In one embodiment, the distributed computing environment is mapped to the underlying external device discovery protocol, including the wrapped device discovery protocol described above, for a particular version of the space discovery message, such as the discovery protocol described in the "Space" section. -Provide a protocol. The mapped discovery protocol self-registers or registers with a space, the default space, in which it will be notified. For each discovery protocol notified, a subsequent result space is provided to hold the results of the discovery protocol. [0346]

FIG. 28 is a diagram of an example of a space discovery protocol mapped to the Bluetooth discovery service 1220 according to one embodiment. The Bluetooth discovery service 1220 first registers with the distributed computing environment 1230. Bluetooth discovery service 1220 is wrapped in a bridge API and notification 1225 of discovery service 1220 is added to space 1224 1232. The client or service identifies Discovery Service Notification 1225 on space 1224. When the discovery service 1220 runs (using the API wrapper as a bridge between the discovery protocol 1220 and the distributed computing environment 1222), a new space 1226 is created to store the results of the discovery process 1234. Discovery service 1220 stores those results in discovery result space 1226 as one or more notifications 1227 (again, using the API wrapper). Separately, the results of running Discovery Service 1220 are stored in space 1224 or other existing space in a distributed computing environment. Discover devices using methods such as those shown in Figure 28, and discover other services using other underlying discovery protocols. [0347]

As mentioned above, there are devices outside the distributed network environment that do not support the message communication model implemented in the distributed network environment. These devices may also include clients that need to use the services provided in a distributed computing environment. A distributed computing environment provides a mechanism for bridging external clients or client devices to a distributed computing environment, allowing clients of external devices to access services within the distributed computing environment. [0348]

Have an agent that will be used as a client in a distributed computing environment, bridging external clients to the distributed computing environment, and allowing external clients to access published services within the distributed computing environment. In one embodiment, the agent is a distributed computing environment in which the front end uses a message communication model and a dedicated protocol (eg, a protocol supported by an external device) to interface to an external device and then to an external client. It has an XML-enabled backend that can communicate with the services in. Therefore, a client outside the distributed computing environment can identify and access a service in the distributed computing environment through a bridge agent, send a request to the service, and receive a response containing the result data from the service. For example, an external client uses a bridge agent in a distributed computing environment to perform space discovery, look up notified services, and call services in a distributed computing environment. [0349]

In one embodiment, the distributed computing environment comprises a bridging mechanism for accessing Jini services from the distributed computing environment client. The distributed computing environment client has access to the Jini service because the Jini service requires remote method invocation (RMI) and clients in the distributed computing environment use messages such as XML messages to communicate with the service. It can provide a protocol bridging mechanism that enables it. In one embodiment, a connector mechanism is defined that can enable dynamic notification of the Jini service within the space of a distributed computing environment and also enable access of the Jini service proxy from clients in the distributed computing environment. To do. In one embodiment, some Jini services cannot be bridged to a distributed computing environment. [0350]

In one embodiment, the Jini used by the Jini service An agent that bridges the RMI protocol to XML messaging used by clients in a distributed computing environment can be provided as a service within the distributed computing environment. When you start the agent, the agent performs a lookup of the Jini service with a set of attributes in the Jini space. For all registered Jini services, the agent generates an XML notification for the service and registers the notification in a space within the distributed computing environment. In one embodiment, the agent can register for event notifications for the Jini lookup service and will be executed when a new Jini service is registered. When notified of a new Jini service, the agent performs a search in the Jini space, identifies the newly notified Jini service, and updates the space in the distributed computing environment with a new XML notification for the new service. In one embodiment, when the Jini service is deleted, the agent receives an event notifying the deletion of the Jini service. The agent removes the service's XML notification from the space. [0351]

In one embodiment, to call the Jini service via an XML notification for a space in a distributed computing environment, the client looks up the service notification in the space and sends a valid message to the agent to access the service. The agent calls the corresponding method via an RMI call to the service proxy to call the proxy service corresponding to the Jini service. If the proxy is not instantiated, the agent downloads the proxy code and instantiates a new instance of the proxy object. In one embodiment, all client connections have different proxy instances. Messages arriving from the client are translated by the agent into proxy method calls. The result from the method call is returned to the client as an outgoing message. [0352]

In one embodiment, only simple Java types can be used as arguments to RMI methods. If a Java complex type is required, pass one or more data notifications as arguments to the call, and the data notifications indicate the location and access method of the Java complex type data. In one embodiment, the agent dynamically performs the initial conversion of the XML message into an RMI method call call. The agent recognizes the service interface and generates the corresponding set of messages to be notified to the client. [0353]

FIG. 29 illustrates how clients 1250 outside the distributed computing environment can be bridged to space 1254 within the distributed computing environment. Bridge agent 1252 is used as an intermediary between client 1250 and space 1254. Bridge agent 1252 communicates with client 1250 using a communication protocol that client 1250 understands. Bridge Agent 1252 maps the client's communication protocol to the XML messaging protocol required to communicate with Space 1254 to perform the functions provided by Space 1254. Bridge agent 1252 identifies and executes services on space 1254 when requested by client 1250. For example, client 1250 can request space 1254 for a list of all services of a particular type. Bridge agent 1252 identifies service notifications 1256a ~ c and returns the result to client 1250. Separately, it posts the result to the result space and returns the position of the result to the client 1250. Client 1250 then chooses to run service notification 1256a and sends a message (in client 1250's communication protocol) to bridge agent 1252. The bridge agent 1252 then sends the XML request message needed to execute the service represented by service notification 1256a and returns the result of the service to client 1250. Any method of handling the results of the service other than returning the results directly to the client 1250 can be used as described in the "Spaces" section above. Bridge Agent 1252 acts as a service on the external client 1250 (via the external client's protocol) and also as a client in the distributed computing environment, bridging services in the distributed computing environment to the external client. .. [0354]

Sometimes, even within a distributed computing environment, clients and services cannot communicate directly with each other and only with a common space. In this case, the space service automatically creates a service proxy that bridges to the client service. The main role of the proxy is to exchange messages between the client and the service over the space. Service proxies are created dynamically. The creation mechanism depends on the implementation of the space. See Figure 30 for a description of the proxy mechanism. Client 554 and service 556 may not be able to communicate directly within a distributed computing environment, for example because they support different transport or network protocols. However, both can communicate with Space 552, which supports both protocols. Space Service creates a proxy 550 that bridges client 554 to service 556. A common form of proxy is a browser proxy. Plaza proxies (most commonly implemented as Servlets) translate traditional web page requests into messages. See also the description of the space lookup service (and proxy) in the "Space" section. [0355]

A distributed computing environment provides a mechanism for bridging clients within a distributed computing environment to enterprise services. In one embodiment of a distributed computing environment, the method of bridging a client to an enterprise service is a client in a distributed computing environment, a bridge service in a distributed computing environment, and an enterprise service in an enterprise environment. including. The bridge service in a distributed computing environment is used as the bridge service between the client and the enterprise service. Enterprises are businesses, small businesses, nonprofits, government agencies, or other types of organizations. Enterprise uses an enterprise computing environment to carry out part of its business. The enterprise computing environment includes a variety of enterprise services. Clients in a distributed computing environment may want to use the services of an enterprise computing environment. Enterprise services are based on a variety of architectures, including a three-tier client / server architecture. Enterprise JavaBeans is an example of an architecture that can be used to implement enterprise services. Enterprise JavaBeans (EJB) is an architecture that uses a client / server model to configure program components written in the Java programming language that run on the server portion of an enterprise environment. In object-oriented programming and distributed object technology, components are the basic elements of a program that can be reused in a distributed network in combination with other components on the same computer or other computers to form an application. EJBs are built on JavaBeans technology that distributes program components (Beans) to clients in the network. To deploy an EJB bean or component, it must be part of a particular application called a container. There are two types of Enterprise JavaBeans, session beans and entity beans. Unlike session beans, entity beans are persistent and can retain their initial behavior or state. With EJB, it can be deployed on virtually any major operating system. The program components of EJB are commonly referred to as Servlets (small server programs). The application or container that runs the Servlet is sometimes referred to as the application server. Unlike beans, it is persistent and can retain its initial behavior or state. With EJB, it can be deployed on virtually any major operating system. The program components of EJB are commonly referred to as Servlets (small server programs). The application or container that runs the Servlet is sometimes referred to as the application server. Unlike beans, it is persistent and can retain its initial behavior or state. With EJB, it can be deployed on virtually any major operating system. The program components of EJB are commonly referred to as Servlets (small server programs). The application or container that runs the Servlet is sometimes referred to as the application server. [0356]

The bridge service interacts with the client via XML message communication and collects the input parameters needed to make a request to the enterprise service outside the distributed network environment. For example, a client can look up and instantiate a bridge service just like any other service in a distributed computing environment. The bridge service interacts with the enterprise service to perform the enterprise service. This dialogue uses an interprocess communication architecture that Enterprise Services understands. For example, the enterprise service is Enterprise When implemented in JavaBeans (EJB), the bridge service uses EJB to communicate with the enterprise service. The bridge service can receive the results from the enterprise service and return the results directly to the client (in an XML message) or put the results in a space in a distributed network environment (for example, the result space). To the client, the bridge service appears to be the only service (the enterprise service is hidden from the client), so the client does not need to support the architecture of the enterprise service. Clients in multiple distributed network environments use the same bridge service (each with a unique gate pair) to interact with the enterprise service. [0357]

The Bridge Service or other agent publishes a Bridge Service (and Enterprise Service) notification in a space within a distributed computing environment. For example, a bridge service or other bridge agent can use Java reflection to look up beans for services in an enterprise system implemented in an EJB and create service notifications for the bridge service to beans. Publish those notifications to a space in your distributed computing environment. Reflection finds information about the fields, methods, and constructors of a class and works on the corresponding parts of the foundation for the object within the security limits of Java code that uses the reflected fields, methods, and constructors. It is a method. The Reflective API is for applications that need to access either the public members of the target object or the members declared in a given class. When the bridge service is notified, the client does not know the details of the architecture of the enterprise service that provides the service, and the client services the bridge service (and therefore responds) like any other notified service in a distributed network environment. You can access the enterprise service). [0358]

Client display There are several ways to view the results from services run by clients within a distributed computing environment. Devices that display results can display service results in printers, speakers, and visual, auditory, or other perceptible formats, such as computer CRTs, laptop LCDs, and notebook computer displays. There are other devices. The method of displaying the result is not limited to the following. The service returns the results to the client either directly or by reference, and the client handles the display of those results. The service returns the results directly to the client or by reference, the client passes those results directly to the display service or by reference, and the display service displays those results. The service handles the display of results directly. The service passes the results to the display service, either directly or by reference, and the display device displays those results. [0359]

The final way to display the results is for the client to specify a display service. For example, there is a display service or related display service for the device on which the client resides that the client wants to use to display the results of the service. When the client runs the service, the client sends a message to the service, specifying the service notification for the client's display service. The service then builds a gate to allow messages to be sent to the client's display service. Therefore, when displaying the result, the service called by the client becomes a client of the client's display service and sends the result to that display service for display (either directly or by reference). See the other sections of this document for more information on client-service relationships, gates, and messaging. [0360]

Traditional application models are typically based on a given, largely static user interface and / or data characteristics. To make changes to a traditional application, you need to modify and recompile your code. Applications (clients, services, etc.) automatically describe display objects using the described mechanism for notifying services and specifying an XML message schema for communicating with services in a distributed computing environment. Provides a mechanism for doing so. Dynamic display objects allow you to change the behavior of your application without having to download new code, recompile your application, or relink your application. Provides a display schema that displays the same results in different formats, extracts parts of the results for display, and displays the results on different display devices. [0361]

FIG. 31 is a diagram of an embodiment of a client 1300 with a related display 1302 and display service 1304 according to an embodiment. Register notification 1306 for display service 1304 in space 1308. Notification 1312 of service 1310 is registered in space 1314 by service 1310. Separately, register service notification 1312 and display service notification 1306 on the same space. Client 1300 sets up a gate to search for and discover service notification 1312 on space 1314 and send a request to service 1310 (receive a result or response from service 1310). In one embodiment, the message is in the form of an XML message specified in the XML Schema received as part of Notification 1312. Client 1300 sends one or more messages (1322) to service 1310. This one or more messages include a message to run service 1310 and a message instructing service 1310 to send the results to display service 1304 for display, and specifies the location of display service notification 1306. The position of the notification is specified as a Uniform Resource Identifier (URI). [0362]

When a message is sent from client 1300 to service 1310 as an instruction, service 1310 performs one or more operations that output visible results. Service 1310 retrieves display service notification 1306 from space 1308 based on location information received from client 1300. The service notification contains the XML message schema and other information needed to interface with Display Service 1304. Service 1310 then sets up a gate for sending requests to display service 1304 (and receiving results from display service 1304). In other embodiments, the message from client 1300 to service 1310 contains an XML schema and other information that service 1310 needs to build a gate to display service 1304, or pre-to display service 1304. Equipped with a gate built in. [0363]

After performing or completing the operation requested by client 1300, service 1310 sends the result of the operation to display service 1304 by the method specified by the schema of display service 1304 (for example, in the XML message schema or). Encapsulated within the XML message specified by the reference as a display service parameter). In this regard, service 1310 is a client of display service 1304. The display service 1304 then formats and displays the results received or instructed by service 1310 on the client's display 1302. [0364]

In some embodiments, service 1310 posts the result of the operation in a space such as the result space (not shown). Service 1310 then sends a message to display service 1304 containing a reference to the result, which also contains the operation. In one embodiment, the reference is in the form of a URI. The display service 1304 then retrieves the result from the space and displays the result on display 1302. [0365]

Traditional application models are typically based on a given, largely static user interface and / or data characteristics. To make changes to a traditional application, you need to modify and recompile your code. Applications (clients, services, etc.) automatically describe display objects using the described mechanism for notifying services and specifying an XML message schema for communicating with services in a distributed computing environment. Provides a mechanism for doing so. Dynamic display objects allow you to change the behavior of your application without having to download new code, recompile your application, or relink your application. [0366]

Dynamic display objects can be described in XML Schema. These schemas are advertised in spaces. These schemas are called display schemas or representation schemas. The application (or any other service that acts on behalf of the application) then accesses the schema from the service notification and displays the data based on the format, data type, and other information stored in the schema. [0367]

An example of a schema containing dynamic display objects is shown below. &lt;element name = "delivery" type = "Space: shipto" minOccurs = "0" /&gt; &lt;type name = "TextField"&gt; &lt;element name = "Address" type = "String" /&gt; &lt;element name = "City" type = "string" /&gt; &lt;element name = "State" type = "string" /&gt; ... ... ... &lt;/ type&gt; [0368]

The above schema can be modified as follows without recompiling the application: &lt;element name = "delivery" type = "Space: shipto" minOccurs = "0" /&gt; &lt;type name = "TextField"&gt; &lt;element name = "Name" type = "string" /&gt; &lt;element name = "Address" type = "string" /&gt; &lt;element name = "City" type = "string" /&gt; &lt;element name = "State" type = "string" /&gt; ... ... ... &lt;/ type&gt; [0369]

32A and 32B are diagrams showing an example of using the schema of the dynamic display object according to one embodiment. In Figure 32A, application 1320 (client, service, or other application) is implemented in representation schema notification 1324 stored in space 1326. The representation schema notification contains elements that describe the data type, formatting, font, position, color, and other information used to display the application's data on the display 1322. There are multiple representation schema notifications for application 1320. For example, there is one schema for each display page in a series of display pages (for example, a website's web page). [0370]

In one embodiment, application 1320 calls the discovery and / or lookup service to identify the representation schema notification. The discovery and / or lookup service returns one or more notifications, and an XML document containing a list of URIs, to each of the schemas that describe a particular display format, etc. Application 1320 then selects one or more representation schemas from the XML document. Application 1320 then parses the schema and decomposes the schema elements into user interface components. These components are used to identify, format, and display the resulting data on the appropriate display. Result data can be obtained, for example, from service execution or result space. So, as opposed to providing a static display or a given display, the application 1320 is configured to display the results according to a representation scheme that can be dynamically modified without rebuilding the application. [0371]

Provides a representation schema that displays the same results in different formats, extracts parts of the results for display, and displays the results on different display devices. [0372]

In one embodiment, one or more representation schema notifications can be stored in one or more spaces in a distributed computing environment. When you call a copy of an application on one or more devices, each copy of the application performs a search for the service and discovers notifications of the representation schema used by the application. There, a central persistent store of display information can be maintained for multiple instances of an application or for other applications. The displayed information can be modified in a central location without having to recompile or reinstall the application. [0373]

In Figure 32B, client 1328 identifies a service notification for service 1330 in space. When calling service 1330, client 1328 passes the location of representation schema notification 1324 in space 1326 to service 1330. If service 1330 is ready to send the results to client 1328, it is bound to display 1322 (the device on which client 1328 is running) using the display information from the representation schema provided by representation schema notification 1324. ) Can display the result. To change the way the results are displayed, you can modify the XML message in Representation Schema Notification 1324 or choose a different representation schema, not on Client 1328 or Service 1330. Service 1330 may be a display service. [0374]

A client, application, or service has multiple display schemas for displaying the results of various operations provided by one or more services. Apart from that, the display schema contains information for displaying different results for one or more clients. Therefore, client 1328 can use one display schema or multiple display schemas. There are two or more display schemas that format and display the same result in different formats or on different displays. For example, prepare one display schema for displaying the results on the display screen for the result set, and another display schema for printing the results. Also, run copies of the same application, client, or service on devices with different display capabilities to provide two or more display schemas that meet the display requirements of different devices. [0375]

String management String processing in traditional systems is generally less efficient, especially for variable-sized strings, for example, when copying or moving strings in memory. It wastes memory space. This inefficiency of string processing is especially problematic in memory-saving systems such as embedded systems. Space-saving / system limits the size of memory, especially stack space, and space for dynamic allocation. Therefore, a method for efficiently performing character string processing in a program executed in a space-saving system such as an embedded system is desired. [0376]

FIG. 33A is a diagram of a typical character string representation in a C programming language. In C, the character string is represented by a character pointer 1450 (string1) that stores the memory location (address) of the first character of the character string 1452. Other characters follow the first character in the string 1452 and are usually stored in contiguous addressable byte positions in memory. Characters in C strings are usually 8 bits. The characters in the C string are ASCII characters. The C string must be null-terminated. NULL is one of the 256 available 8-bit values defined on the platform, typically the binary value 0b00000000. The string 1452 occupies 13 bytes (12 characters and 13 terminating characters combined). [0377]

An example of string manipulation in C is the strlen () function, which usually comes with the standard C library implementation. The strlen () function takes a string pointer as input and returns the length (bytes) of the string, not including the terminator. For example, passing the character pointer 1450 to the strlen () function returns a length of 12. The strlen () function can be implemented by scanning the string from end to end, counting the number of characters until the terminating character is found. [0378]

A string copy of C is usually processed by the C library functions strcpy () or strncpy (), which is implemented as follows. char * strcpy (char * dest, constant char * src); char * strncpy (char * dest, constant char * src, size_t n); The strcpy () function copies the string pointed to by the character pointer src (including the terminating character) to the string pointed to by the character pointer dest. The strings do not overlap and the destination string dest must be large enough to accept the copy. The strncpy () function is similar, except that n bytes or less of the src are copied. Therefore, if there is no terminating character in the first n bytes of src, the result will not include the terminating character. If desired, the code after strncpy () can contain an instruction to add a terminating character to the end of the dest string. If the length of src is less than n, the rest of dest is padded with NULL. The strcpy () and strncpy () functions return a pointer to the destination string dest. Figure 33B shows an example of the result of the strncpy () function on the string 1452, which is the case when strncpy () is called with the following parameters. strncpy (string2, string + 3,5); However, string2 is the character pointer 1454 pointing to the first byte after the terminating character of string 1452, string1 + 3 is the character pointer 1450 incremented by 3 bytes, and 5 is the source location string1 +. The number of characters (bytes) to copy from 3 to string2. After copying, the next character after the five characters copied from string1 is set to the terminating character (the character may have been initialized to the terminating character before copying). Therefore, the two strings occupy (13 + 6) = 19 bytes in memory. When the strcpy () function is applied with the character pointer 1450 as the copy source string, the original string 1452 and the resulting new string occupy (13 * 2) = 26 bytes. [0379]

FIG. 33C is a diagram showing an efficient method of expressing and managing a character string in a general system, specifically, a space-saving system such as an embedded system. The string 1452 is stored in memory as 12 bytes (no terminating character is required). String structure 1460 includes pointers to the first and last characters of string 1452 (addresses (A) and addresses (L)). Using this string structure, the length of the string can be calculated efficiently by pulling the pointer to the first character from the pointer to the last character. [0380]

Character string copy operations Operations such as strcpy () and strncpy () can also be processed more efficiently. Create a new string structure 1462 using a string structure such as that shown in Figure 33c, and initially point the first and last character pointers to each character in the string 1452. To become. Therefore, it is not necessary to copy part or all of string 1452 to the new storage for that string. Strings can reach hundreds or even thousands of characters in length, so save memory by using a string structure and string methods implemented to take advantage of that string structure. Is noteworthy. Such a method of processing a copy of a part or all of a character string is called "substring management", and a part (substring) of the character string can be processed efficiently. [0381]

Other string functions in the standard C string library can be replaced with string functions that utilize the string structure as shown in Figure 33C. Examples of other C string functions are, but are not limited to, strstr (), strcat (), and sprintf (). String processing structures and methods, such as those described in Figure 33C, efficiently process XML text (such as XML messages) in memory-saving systems such as embedded systems when used with the hierarchical structure of XML documents. be able to. The following is a simple example of an XML schema that defines a purchase order. &lt;! DOCTYPE purchase.order SYSTEM "po.dtd"&gt; &lt;purchase.order&gt; &lt;date&gt; 22 May 2000 &lt;/ date&gt; &lt;billing.address&gt; &lt;name&gt; John Smith &lt;/ name&gt; &lt;street&gt; 123 Main &lt;/ street&gt; &lt;city&gt; Anywhere &lt;/ city&gt; &lt;state&gt; MA &lt;/ state&gt; &lt;zip&gt; 12345-6789 &lt;/ zip&gt; &lt;/ billing.address&gt; &lt;items&gt; &lt;item&gt; &lt;quantity&gt; 3 &lt;/ quantity&gt; &lt;product.number&gt; 248 &lt;/product.number&gt; &lt;description&gt; Decorative Widget, Red, Large &lt;/ description&gt; &lt;unitcost&gt; 19.95 &lt;/ unitcost&gt; &lt;/ item&gt; &lt;item&gt; &lt;quantity&gt; 1 &lt;/ quantity&gt; &lt;product.number&gt; 1632 &lt;/ product.number&gt; &lt;description&gt; Battery, AA, 4-pack &lt;/ description&gt; &lt;unitcost&gt; 4.95 &lt;/ unitcost&gt; &lt;/ item&gt; &lt;/ items&gt; &lt;/ purchase.order&gt; [0382]

The hierarchical structure of the XML document allows them to be processed recursively, processing smaller parts of the document one after another at each recursive level. References to various parts are recursively recorded and processed. Various parts can be recorded using the string structure as described for Figure 33C. In this way, the content of a specific XML tag (one line in the above example) can be efficiently determined in one embodiment in which the smallest unit of the XML document is processed recursively. Since tags within a predetermined scope can be efficiently enumerated and processed, documents in which tags are repeated within the same scope can also be efficiently processed. [0383]

A recursive method of processing an XML document using a string structure, as described in Figure 33C, is a string that represents the entire XML document string and points to the first and last bytes in the document string. Can accept structures. In this method, the next subsection of the document is identified and the string structure representing the substring of the entire document string containing that subsection is passed to the processing function corresponding to the type of that subsection. The subsection itself can be decomposed into other levels of the subsection represented by the string structure passed to the processing function corresponding to the subsection type. This method allows you to recursively process subsections of an XML document until the entire document has been processed. [0384]

The string structure used in recursive processing allows the processing to be performed without making a copy of the subsection for the processing. Subsection copying is especially costly in recursive processing, as more copies of the same data increase as the recursion gets deeper. With a string structure, you only need to create a string structure that contains pointers to the first and last bytes in the subsection and pass it to the next level. Other operations, such as determining the length of a subsection, can be performed efficiently by using the address information stored in the string structure. In addition, the string structure eliminates the need for terminating characters, such as the characters used to terminate C strings, and saves memory on space-saving devices such as embedded devices. [0385]

XML representation of the object As mentioned earlier, Jini RMI seems impractical for some clients, such as thin clients, which have minimal memory footprint and minimum bandwidth. The serialization associated with Jini RMI is a Java-specific object representation with long execution times, large code size, and the need for a JVM reflection API. Java deserialization is also slow to execute, has a large code size, and requires a serialization object parser. Even Java-based thin clients may not be able to accept the huge Java objects (along the required classes) that are (always) returned over the network when requested within Jini. [0386]

A more scalable distributed computing mechanism can be achieved by using embodiments of a distributed computing environment. The distributed computing environment includes an API layer that facilitates distributed computing. The API layer provides message sending and receiving functions between the client and the service. This messaging API provides an interface for simple messages in representational or metadata formats, such as Extended Markup Language (XML). Although embodiments are described here for adopting XML, it should be noted that other embodiments may use other metadata type languages or formats. In some embodiments, the API layer can also include a message interface for communication between objects and passing objects, such as Java objects. Objects accessible through API Layer 102 are represented in a representational data format such as XML. Therefore, as opposed to the object itself, the XML representation of the object can be manipulated. [0387]

The API layer sits on top of the messaging layer. The messaging layer is based on representational data formats such as XML. In one embodiment, the XML message is generated by the messaging layer as the API layer is called. The messaging layer can include predefined static messages that can be sent between the client and the service. The messaging layer can also accommodate dynamically generated messages. In one embodiment, objects such as Java objects can be dynamically converted (compiled) into XML representations. The object contains code and / or data parts. The code and / or data portion of an object can be compiled into code and data segments identified by XML tags in an XML representation. The messaging layer allows XML object representations to be sent as messages. Conversely, the messaging layer can receive an XML representation of the object. You can then reconstruct (decompile) the object from that message. Reconstruction examines the XML representation of a tag that identifies the code and / or data segment of the XML representation, uses the information stored in the tag to identify the code and / or data portion of that object, and decompiles it. Compile. [0388]

Creating and shipping an XML representation of an object FIG. 34 is a diagram illustrating the process of moving Java objects between client 1500 and service 1502, according to one embodiment. Service 1502 can be any service supported in a distributed computing environment, including space services. Client 1500 uses gate 1504 created using the XML schema received from service notification for service 1502 to communicate with the corresponding gate 1506 for service 1502. At some point, the client 1500 needs to send the Java object 1510 to service 1502. Java object 1510 references other objects, then this object references other objects, and so on. The continuation of the Java object 1510, its referenced object, the next referenced object, and so on is called an object graph. [0389]

The Java object 1510 is passed to the Java object compilation process 1512 to be compiled and output an XML representation of the object graph. The XML representation of the object graph is passed to gate 1504 as an XML data stream 1514. The XML data stream 1514 contains an XML representation of all the objects in the object graph. In one embodiment, the objects in the object graph are recursively stored in the XML data stream 1514. [0390]

Gate 1504 then packages the XML data stream 1514 into message 1516 and sends message 1516 to gate 1506 of service 1502. Gate 1506 extracts the XML data stream 1514 from the XML message 1516 and sends the XML data stream 1514 to the XML data stream decompile process 1518 for decompilation and an object graph containing the Java object 1510. Output the provided object. In one embodiment, the objects in the object graph are recursively stored in the XML data stream 1514, and therefore a recursive decompilation process is used. [0391]

If service 1502 needs to send Java objects to client 1500, you can use a substantially similar process. The Java object 1520 is passed to the Java object compilation process 1512 for compilation and outputs an XML representation of the object graph. The XML representation of the object graph is passed to gate 1506 as an XML data stream 1522. Gate 1506 then packages the XML data stream 1522 into message 1524 and sends message 1524 to gate 1504 on client 1500. Gate 1504 extracts the XML data stream 1522 from the XML message 1524 and sends the XML data stream 1522 to the XML data stream decompile process 1518 for decompilation, resulting in an object graph containing the Java object 1520. Output the provided object. [0392]

In other embodiments, the gate is responsible for compiling and decompiling Java objects. In this embodiment, Java object 1510 is passed to gate 1504. Gate 1504 passes the object 1510 to the Java object compilation process 1512 for compilation and outputs the XML representation of the object graph to the XML data stream 1514. Gate 1504 then packages the XML data stream 1514 into message 1516 and sends message 1516 to gate 1506 of service 1502. Gate 1506 extracts the XML data stream 1514 from the XML message 1516 and sends the XML data stream 1514 to the XML data stream decompile process 1518 for decompilation, resulting in an object graph containing the Java object 1510. Output the provided object. The process of sending a Java object from service 1502 to client 1500 is substantially similar to the process of sending an object from client to service. [0393]

In one embodiment, the object compilation process 1512 and the object decompilation process 1518 are both present on the client 1500 and service 1502, and when programming, the compilation and decompilation are substantially the same on the two devices. The output of one object is substantially the same as the input of the other object. In one embodiment, an XML schema containing a description of Java objects can be used by both clients and / or services in the compilation and decompilation processes. In one embodiment, the service can pass the XML Schema used for compiling and decompiling Java objects to the client in a service notification. [0394]

XML has language-independent and platform-independent object representation formats. Therefore, when compiling an object into an XML representation of the object and decompiling it to reproduce the object, the process shown in Figure 34 is not limited to moving Java objects, and in some embodiments within the network. It also applies to moving objects of other types between entities in Java. [0395]

JVM compilation / decompilation API Figures 35a and 35b show an extension in which a virtual machine (eg, JVM) compiles an object (eg, a Java object) into an XML representation of the object and an extension that decompiles an XML representation of a (Java) object into a (Java) object. It is a data flow chart which shows embodiment including a function. The JVM can have an application programming interface (API) for compilation / decompilation extensions. Client 1500 and service 1502 may be running inside the JVM. The JVM can be on the same device or on different devices. [0396]

In both Figure 35a and Figure 35b, the JVM XML compiler / decompiler API 1530 accepts Java object 1510 as input and takes an XML representation of object 1510 and its referenced object (object graph of object 1510) as XML data. Output to stream 1514. In addition, the JVM XML compiler / inverse compiler API 1530 can accept an XML data stream 1522, which includes the XML representation of object 1520 and all its referenced objects (object graphs of object 1520). , Outputs Java object 1520 (and all objects in that object graph). [0397]

Figure 35a shows an embodiment where the client calls the JVM XML compiler / decompiler API 1530 when sending a Java object 1510. The client 1510 passes the Java object 1510 to the API 1530, compiles the object, outputs an XML representation, stores the XML representation in the XML data stream 1514, and outputs the XML data stream 1514. The client can then pass the XML data stream 1514 to gate 1504. Gate 1504 then packages the XML data stream 1514 into XML message 1516 and sends the message 1516 to service 1502. [0398]

After receiving the XML message 1524 from service 1502, gate 1522 extracts the XML data stream 1522 from message 1524 and passes the data stream 1522 to client 1500. Client 1500 calls the JVM XML compiler / decompiler API 1530 to pass the XML data stream 1522 to API 1530. API 1530 then decompiles the XML data stream 1522, prints the Java object 1520 and other objects to its object graph, and returns the object to client 1500. [0399]

Figure 35b shows another embodiment where the JVM XML compiler / decompiler API 1530 is called by the gate when sending Java object 1510. Client 1510 passes the Java object 1510 to gate 1504. Gate 1504 passes the object 1510 to the API 1530, compiles the object and outputs an XML representation, stores the XML representation in the XML data stream 1514, and outputs the XML data stream 1514. Gate 1504 then packages the XML data stream 1514 into XML message 1516 and sends the message 1516 to service 1502. [0400]

After receiving XML message 1524 from service 1502, gate 1522 extracts the XML data stream 1522 from message 1524 and passes the data stream 1522 to the JVM XML compiler / decompiler API 1530. API 1530 then decompiles the XML data stream 1522 and outputs the Java object 1520 and other objects to its object graph. The gate then sends the Java object 1520 and other objects to the client 1500. [0401]

In one embodiment, the JVM XML compiler and decompiler can be implemented as an integrated feature of the JVM. In other embodiments, the XML compiler and decompiler can be embodied in API method calls in the JVM's standard extensions, so there is no need to modify the core JVM. The JVM supplies the JVM XML compiler / decompiler API 1530 to the processes (clients and / or services) that run within the JVM, so the processes must access the Java object compilation / decompilation functionality provided by the JVM. Can be done. In one embodiment, in order for a process to take advantage of object compilation / decompilation, the JVM running in that process must have the JVM XML compiler / decompiler functionality and API 1530. Methods that use reflection and serialization to transform and send objects are typically implemented in a separate application that is separate from the JVM. Object transitive closure When parsing closure) dynamically, the application must repeatedly access the JVM and retrieve objects one field at a time. This can be a slow and cumbersome process and requires a lot of application and JVM code. [0402]

It is convenient to implement Java object compilation / decompilation functionality within the JVM because the JVM already understands the concept and content of object graphs. Therefore, the compile / decompile function utilizes the knowledge of the JVM (and reuses the code) for the analysis of the object graph for outputting the XML representation and the analysis of the XML representation for outputting the object graph. be able to. Therefore, the compile / decompile feature must not duplicate the functionality provided by the JVM, as is the case with object-sending methods that use reflection and serialization. This makes it possible to reduce the code occupied area of the compile / decompile function compared to the object sending method that uses reflection and serialization. Objects can also be compiled or decompiled with a single call to the JVM XML compiler / decompiler API. [0403]

In addition, by integrating object compilation and decompilation into the JVM, object compilation and decompilation can sometimes be performed faster than methods that use reflection and serialization, which is the case with reflection and serialization. In the implemented object traversal model, code outside the JVM does not recognize the structure or graph of the Java object, traverses the object graph, pulls it apart, and finally repeatedly calls and compiles (and) the JVM. This is because it is necessary to execute the inversion process for decompilation). This process can be slow because it requires repeated JVM calls outside the code. By integrating the compilation and decompilation functions into the JVM, as described here, it is possible to avoid repeated calls from code outside the JVM to the JVM. In one embodiment, the object can be compiled or decompiled with a single call to the JVM XML compiler / decompiler API. [0404]

In one embodiment, the compiler / decompiler functionality can be implemented as a service in a distributed computing environment. The service publishes service notifications within the space. Processes within a distributed computing environment can use search or discovery services to identify compile / decompile services. This process (the client of the service) can then use the service by passing it to a Java object that compiles into an XML representation and / or an XML representation service that decompiles into a Java object. Java objects can contain code (object methods) and data. The code of the object is not non-temporary and this code does not change after the object is created. However, the object data may be temporary. Two objects created from the same Java class may contain different data in the two objects, even if they contain the same code. In one embodiment, the compile function compiles the data of a Java object into an XML representation of the object, but the XML representation may not contain the actual code of the object. In one embodiment, information about an object can be inserted into a compiled XML representation to inform the recipient of how to recreate the code for that object. You can store the XML representation in an XML data stream and send it to the receiving process (client or service) (for example, in a message). The receiving process can pass the XML data stream to the decompiler. The decompile feature can decompile an XML data stream and output a Java object containing that data. In one embodiment, the code of an object can be reproduced by decompilation using the information about the object contained in the XML representation, but it is because the code of the object is statically defined. [0405]

In one embodiment, the Java object data and information about the Java object can be stored in the XML representation of the object output by the compilation function. That information can include class information for Java objects. The object signature can be included in the information, and the signature can be used to identify the class of the object and so on. The decompile feature allows you to rewrite the code for a Java object using information about the Java object and decompile the data from the XML data stream into a Java object. Therefore, the decompiled data and the information describing the object can be used to reproduce the complete object containing the code and data on the receiving client or JVM running the service. In one embodiment, the information describing the object can be stored in one or more XML tags. In one embodiment, the client or service that receives the XML data stream can include an XML schema that describes the object, and the XML schema is used to re-create the Java object from the back-compiled data and information about that object. Can be configured. The decompile process recursively traverses the object graph and reconstructs the object referenced by the object, but this task reverse-compiles the data of the object referenced from the XML data stream and its This is done by recreating the code for the referenced object from the information about the referenced object in the XML data stream. [0406]

In one embodiment, the XML representation of the object output by the compilation function can store the data of the object and the information that identifies the code of the object. In one embodiment, information describing the code of an object can be stored in one or more XML tags in an XML data stream. Upon receipt, the decompiler can recreate the Java object's code using the information about the code from the XML data stream and decompile the object's data from the XML data stream. Therefore, from the decompiled data and the information describing the code of the object, it is possible to reproduce the complete object containing the code and data in the receiving client or the JVM running the service. [0407]

The scenario of transferring an object between entities (typically clients and services) in a distributed computing environment using an XML representation of the object is discussed for illustration. These scenarios are examples and are not intended to be limiting. [0408]

In the first scenario, the service uses an XML compiler / decompiler to compile a Java object into an XML representation of that object and send that XML representation to the client. The client uses the XML compiler / decompiler to decompile the XML representation, performs operations on the data in the object, and later uses the XML compiler / decompiler to compile the object into the object's XML representation. And return the XML representation of that object to the service. [0409]

In the second scenario, the service uses an XML compiler / decompiler to compile a Java object into an XML representation of that object and send that XML representation to the client. The client then sends the XML representation to another service, which uses the XML compiler / decompiler to decompile the XML representation to regenerate the object and request it from the client (possibly modifying the data). Performs an operation on the object when it encounters it, uses an XML compiler / decompiler to recompile the modified object into its XML representation, and sends the XML representation of that object to the client. [0410]

In the third scenario, the service uses an XML compiler / decompiler to compile a Java object into an XML representation of that object and send that XML representation to an object repository or store space. The service then sends a message to the client, informing the client of the location of the XML representation. The message contains a Universal Resource Identifier (URI) in XML representation. The client then retrieves the XML representation of the object from the store space and decompiles that representation using an XML compiler / decompiler to reproduce the object. Separately, the client sends the location of the object's XML representation to other services along with requests for operations to be performed on the object. Other services then take the XML representation from the store space and use the XML compiler / decompiler to decompile the XML representation to reproduce the object and perform the requested operations on the object. [0411]

In the fourth scenario, a process (which may be a client or service) can identify an object repository or store space in a distributed computing environment by searching and finding service notifications in the store space. it can. The process creates and retrieves multiple Java objects at runtime. The process uses an XML compiler / decompiler to compile one or more objects into an XML representation of the object, send the XML representation of the object to the store space as a client of the store space service, and later. Store it so that it can be accessed and accessed by other processes. [0412]

Security issues in decompiling an XML representation of an object Space can be used as a file system in a distributed computing environment, as described here. It provides security for files in the system in the form of permissions. Access rights are checked for each file access (open, read, write operation). Therefore, a method for achieving file access security in a distributed computing environment is desired. This method can also be applied to the XML representation of Java objects that are stored in spaces and sent between clients and services in a distributed computing environment. [0413]

In one embodiment, a user of a client on a device in a distributed computing environment is identified and authenticated the first time the client is accessed. In one embodiment, the user can provide a physical identification function such as a smart card for identification and approval. In other embodiments, challenge response mechanisms (such as user IDs and passwords) can be used for identification and authorization. In yet another embodiment, electronic identification, such as an electronic signature, is used for identification and approval. Other methods can be used for identification and approval. Once identified and approved, users can perform a variety of operations on the client, including accessing one or more services in a distributed computing environment. During these operations, as mentioned above, one or more objects can be created (locally) or retrieved from somewhere else (eg, a service or space). The object can be modified, compiled into an XML representation of the object, stored locally by the client, or sent to the Space Service for a (transitional or persistent) store. Some of the objects are received from the service in the form of an XML representation of the object (stored in the service or other service), which can be decompiled by the XML compiler / decompiler and recreate the object on the client. .. [0414]

In one embodiment, when decompiling an XML representation of an object, each XML message is checked to verify that the user has access to the object. If the user does not have the proper permissions, the XML compiler / decompiler will not decompile the object for that user. In one embodiment, the XML compiler / decompiler throws a security exception. In one embodiment, the user is notified of the access violation. [0415]

Access authority information such as author and access level allowed for an object (author only access, read-only, read / write, delete, copy, etc.) can be embedded within an XML message containing the object's XML representation. .. Access authorization is determined when identifying and approving the user. For example, an object grants "read-only" access to most users and "read-write" access to the creator of the object. If the user attempts to access an object with read / write permissions and the user has not created the object, the decompilation process detects this as an access violation, denies access, and the user notifies. receive. [0416]

In one embodiment, when the user completes using the client, the user logs off or otherwise notifies that the user has terminated the client (eg, deleted the smart card). Objects created on the client by decompilation are automatically detected when the client detects that the user has terminated. This prevents later users from deliberately or inadvertently attempting to access their objects. In one embodiment, all objects created by decompilation are deleted when it is detected that the user has terminated. In other embodiments, there is a way to store at least some of the objects that are permanently created on the client (for example, using permission information), which allows the client to access the object later. , Provide objects for access to other users. In one embodiment, the user uses a "smart card" or other physical device to gain access to the client. The user can insert the smart card into the client device and start a session. When the client exits, it removes the smart card. The client detects that the smart card has been ejected, detects that the client has terminated, and then proceeds to delete the object created by decompiling the XML representation. [0417]

XML-based object repository In a distributed computing environment, processes (services and / or clients) are temporary, such as XML Schema, service notifications, XML representations of Java objects as a result of being generated by the service, and / or objects implemented in other languages. Target and / or permanent storage may be desirable. Existing object storage techniques tend to be language and / or operating system specific. These storage systems also tend to be too complex for use in space-saving systems such as embedded systems. [0418]

Jini's JavaSpaces are an existing object repository mechanism. JavaSpaces can only store Java objects and are too large to implement for small devices with limited memory capacity. Each JavaSpace object is serialized as described above, and therefore has the same limitations as described above for reflection and serialization techniques. [0419]

Presents a store mechanism for distributed computing environments that can provide temporary or persistent storage for objects that are heterogeneous (non-language or operating system dependent) and scalable from small to large devices. To do. In one embodiment, the store mechanism in a distributed computing environment can be implemented as an Internet web page or page set defined in the XML markup language. XML provides language-independent and platform-independent object representation formats that allow Java and non-Java software to store and retrieve language-independent objects. Because the store mechanism is on the web, devices of all types and sizes (small to large) can access the store mechanism. You can use a web browser to view the store mechanism implemented as a web page. A web search engine can be used to content content within a store mechanism implemented as a web page. You can use Internet management mechanisms (existing and future) and XML tools to manage XML-based store mechanisms. [0420]

In one embodiment, a store mechanism can be used to store objects created, represented, or encapsulated in XML. Examples of objects that can be stored in the store mechanism are, but not limited to, XML Schema, XML representations of objects (for example, Java objects compiled into XML representations as described above), service notifications, and XML encapsulation. There are service results (data). In one embodiment, an authorization certificate, such as an electronic signature or certificate, is attached to the XML object to prevent unauthorized access to the XML object, and a client wishing to access the XML object accesses the XML object. Mandatory to have an appropriate certificate of approval to do so. In one embodiment, the store mechanism may be a space as described in the "Space" section. [0421]

In a distributed computing environment, the store mechanism is a service. The store mechanism implemented as a service is called a "store service". The store service publishes notifications in the space. The space itself is an example of a store service. Some store services are temporary. For example, the space service that stores service notifications is a temporary store. Other store services are persistent. For example, a store service that stores results from a service is a persistent store. [0422]

FIG. 36 is a diagram of client 1604 and service A 1606 accessing store mechanisms 1600 and 1602 in a distributed computing environment in one embodiment. This figure is for illustration purposes only and is not required to be limited to the scope of the present invention. In one embodiment, the store mechanisms 1600 and 1602 are Internet web pages or a collection of web pages defined in XML that are accessible by a web browser and other internet tools, respectively. The store mechanism 1600 is a temporary store that can store objects implemented using XML. The store mechanism 1602 is a persistent store that can also store objects implemented using XML. Service A 1606 publishes XML Service Notification 1608 on the temporary store 1600. The persistent store can also publish XML service notifications to the temporary store 1600 (or to other temporary stores in a distributed computing environment). At some point, client 1604 is in service A Requires the functionality provided by 1606. Client 1604 uses the discovery and / or lookup service to identify service notification 1608. Client 1604 builds a message gate and initiates communication with service A 1606, as described here. Client 1604 sends one or more XML request messages to service A 1606. Service A 1606 performs one or more functions in response to its one or more request messages. Outputs the results sent to client 1604 by one or more of the functions performed by service A 1606. [0423]

For transient results 1610, service A 1606 encapsulates the results in XML notification 1612 and publishes the notification 1612 to the temporary store 1600 (or to another temporary store in a distributed computing environment). Service A 1606 can then notify client 1604 that the result 1610 will be stored in notification 1612 of the temporary store 1600, or it may notify client 1604 by other mechanisms as described herein. Client 1604 then retrieves the temporary result 1610 from notification 1612. Notification 1612 contains an XML schema that describes the format, content, types, etc. of the temporary result 1610. The result is encapsulated in XML. For example, you can use XML tags to describe some of your data as follows: &lt;XML tag1&gt; &lt;data1&gt; &lt;XML tag2&gt; &lt;data2&gt; .... [0424]

For persistent results 1618, service A 1606 uses the service or other mechanism as described here to identify the XML service notification 1616 in persistent store 1602 and to store the persistent results. Identify the target store 1602. Separately, client 1604 has already identified the persistent store 1602 by identifying the service notification 1616 and sends the Universal Resource Identifier (URI) of the storage location of the persistent result 1618 to service A in an XML message. .. In one embodiment, the persistent result 1618 is defined in XML and stored in an internet web page or web page set accessible by a web browser. Service A 1606 then stores the persistent result 1618 in the persistent store 1602. Then service A The 1606 publishes the XML notification 1616 with persistent results 1618 to the temporary store 1600 (or to another temporary store in the distributed computing environment) and returns the location of the notification 1616 to the client 1604. Notification 1616 contains an XML schema that describes the format, content, types, etc. of the persistent result 1618. The result is encapsulated in XML as described above. The notification also contains a URI with a persistent result of 1618. Client 1604 then retrieves notification 1616 and uses it to identify and retrieve persistent result 1618. Separately, service A 1606 does not publish the notification of persistent result 1618 and instead gives the URI of persistent result 1618 to client 1604 so that client 1604 can access the result without looking up the notification. Return to. Note that in some embodiments, the various notifications shown in the temporary store 1600 can each be stored in a different temporary store or space. [0425]

Therefore, the store mechanism can be implemented as an XML-based Internet Web page within a distributed computing environment. These store mechanisms are implemented on various devices in a distributed computing environment to provide service notifications that enable clients (or other services) to identify and use the store mechanism. The web and XML tools that can be used to manage the store mechanism can be existing or future. The store mechanism can store objects of various types implemented or encapsulated in XML. Clients of virtually any size device, from space-saving devices to supercomputers, can access the store mechanism to store and retrieve various objects on the Internet. The client may be a Java application or a non-Java application as long as it is a language-independent storage format defined by XML. Temporary or persistent object repositories support file systems in distributed computing environments and have access checking and other security mechanism features as described here. [0426]

Dynamically convert Java objects to XML documents In one embodiment, the distributed computing environment comprises a mechanism for transforming an object class instance into an XML document and representing it. Objects are transformed and represented as XML documents in order to send a representation of the class instance to other services. In one embodiment, upon receiving an XML document, the program instantiates a class instance that corresponds to the object represented by the document. In one embodiment, the object is a Java object and the program is a Java program. [0427]

In one embodiment, an intermediate format can be used to represent an XML document and the intermediate format can be dynamically processed to generate a class instance that represents the XML document. The class defines a set of instance variables and a "set and get" method to access the instance variables. You can define the corresponding XML document as a set of tags and assign one tag to each instance variable. When parsing a document, build a hashable representation, include the instance variable name in the hash key, and put the instance variable value in the value. If multiple composite instance variables occur, the enumerated value can be stored in the hash table. In one embodiment, the process can be limited to only one level of the complex type for instance variables and the elements can be homogeneous. [0428]

In one embodiment, a protected instance variable can be added to a class definition that can contain the name of the corresponding class. Class names can be used as document types in XML document representations. Embedding the class name in the document allows you to dynamically instantiate the correct class instance when you rebuild the object. [0429]

In one embodiment, after receiving the document, the class instance generator method can be used to extract the class type and parse the document to generate an intermediate hash table representation. The generator method can instantiate a new class instance and use the set method to initialize the instance object from the hash table values. In one embodiment, the class type is defined and the hash table is generic, so this process is performed on the class that matches the class definition above. In one embodiment, an inversion process can also be performed, class instances can be processed into an intermediate hash table representation, and generator methods can be used to output the XML document from the hash table representation. This process can also be generic so that it can be run for XML documents that match the above specifications. [0430]

This method is not intended to be restricted to Java class objects and applies to other computer-based objects, including class object instances in other programming languages. In addition, this method is not intended to limit the XML representation of the object instance, and other representation formats such as other data representation languages (such as HTML) can be used instead of XML. [0431]

XML-based process migration In a distributed computing environment, you can distribute and manage distributed applications. For example, a distributed computing environment includes stations and dockable mobile clients with monitors, printers, keyboards, and various other I / O devices not normally found on mobile devices such as PDAs and mobile phones. .. These mobile clients can run one or more applications and migrate from one station to the other in a distributed computing environment. Therefore, in one embodiment of a distributed computing environment, a mobile client on one node in the distributed computing environment is running on the same mobile client or the other mobile client on the other node while preserving the entire current state. Presents a method for migrating applications (processes). [0432]

One embodiment creates an XML representation of the state of a process running on a client or service. In one embodiment, the XML representation of the state of a process includes the computational state of the device and / or virtual machine on which the process is running, and the computational state of the device and / or virtual machine is the process on the device and / or virtual machine. Contains information about the execution state of. Process states include, but are not limited to, threads, all objects referenced by threads, temporary variables created during the execution of a process, objects, and their data. In one embodiment, the data that is obtained from the space by the process and describes one or more leases that represent the granting of access to external services outside the device and / or virtual machine on which the process is running. Represented in XML and stored with the process state. Leasing is described in detail in the "Leases" section of this document. [0433]

XML and messaging systems, as described here, allow you to move an XML representation of the state of a process from node to node in a distributed computing environment, for example from node to node on the Internet. The XML representation of the process state can also be stored as an XML object by the XML-based store mechanism as described above, which can later be retrieved from the store mechanism and on the same node or in a distributed computing environment. Process execution can be resumed on a different node. In one embodiment, an XML object compile / decompile process is used to create (compile) an XML representation of the process state and decompile the process state XML representation as described here. This makes it possible to regenerate the state of the process. [0434]

This mechanism allows an XML representation of a process's state to be stored from an initial node in an XML-based store mechanism such as a space. You can then identify the stored state of the process on other nodes, download the state of the process, and restart the process from the downloaded stored state when it was running when the state was stored. Process states are stored in XML format, allowing process migration with tools and search capabilities for storing, identifying, and retrieving XML objects with the XML-based store mechanism described here. Can be. When publishing a notification of an XML representation that contains the state of a process, identify and access the state in which the restarting client of a process running on the same node or another node is stored. .. [0435]

You can store an XML representation of a process's state in an XML-based persistent store mechanism and create a persistent snapshot of the process. This can be used, for example, as a way to resume process execution on a node after the process on the node has been interrupted due to a deliberate or unintentional shutdown of the node. Publish notifications of stored state of processes so that clients can identify the stored state in a distributed computing environment. In one embodiment, in order to prevent unauthorized access to the XML representation of the stored state of the process, an authorization certificate such as an electronic signature or certificate is attached to the stored state and stored. Mandatory that clients wishing to restart the process from have an appropriate authorization certificate to access the stored state. [0436]

FIG. 37 is a diagram showing a process migration using an XML representation of the process state in one embodiment. Process A 1636a is running on node 1630. Process A 1636a is a client or service. At some point during the execution of process A 1636a, the state of execution of process A 1636a is captured and stored in the XML-encapsulated state of process A 1638. Execution of process A 1636a on node 1630 is stopped. Later, node 1632 identifies the XML-encapsulated state of process A 1638 and uses it to restart process A 1636b on node 1632. To resume process A, use stored state 1638 to resume thread execution, recalculate temporary variables, reestablish leased resources, and store process 1638 in the stored XML state. Performs other functions required to resume execution as recorded in. [0437]

An example of using XML-based process migration in a distributed computing environment is shown below, but is not intended to be limited. The mobile client device is connected to node 1630 and is running process A 1636a. A user on a mobile client device wants to stop execution of process A 1636a on node 1630 and later resume execution from another (or the same) node. In one embodiment, the user may be asked to store the state of process A 1636a and determine if he wants to resume execution at a later time. If the user answers affirmatively, it captures the process's XML-encapsulated state and stores it in the persistent store 1634. Later, the user connects to the mobile computing device at node 1632. In one embodiment, the user runs process 1636b and selects the Resume from Stored State option. Node 1632 then searches, identifies, downloads, and uses the XML-encapsulated state of process A 1638 to process A. Resume 1636b. Apart from that, the process itself recognizes that it was "suspended" on another node and resumes from its stored state without user input. [0438]

application There are technologies that allow a user to access network data from a remote location and make the remote data appear to the user as if it were local data when the user accesses a browser. However, such technology does not provide an automatic infrastructure for querying the network near the location of the client device. It is desirable to have a mechanism for discovering information about networks and services near the client device. For example, when using such a mechanism, identify information about restaurants, weather, maps, traffic, movie information, etc. within a certain distance range (radius) of the client device, and send the desired information to the client device. Can be displayed. As an example of using this mechanism, automatically identify services to display titles and performance times of works currently being shown in a local environment, such as a movie theater, or to display menu selections and prices in a restaurant. A mobile phone that can be considered. In a distributed computing environment as described here, such a mechanism can be used to discover spaces containing local information and / or services in close proximity to client devices. This mechanism can also be applied in other distributed computing environments, such as Sun Microsystems, Inc.'s Jini system. [0439]

In one embodiment, the mobile client device comprises a Global Positioning System (GPS) function and wireless connectivity technology. A local distributed computing network can be realized. For example, a city can build a distributed computing environment throughout the city. Another example is a shopping mall with a locally distributed computing environment. A local distributed computing network provides a discovery mechanism that allows client devices to connect to a distributed computing environment and discover services and data within the local environment. For example, one or more devices in the environment may be equipped with wireless connectivity technology that allows mobile client devices to connect to the network and access the discovery mechanism via the XML messaging system described above. Local distributed computing environments include one or more spaces that use notifications to make services and / or data available to mobile clients. For example, a city-wide distributed computing environment includes spaces that represent entities such as malls, cinemas, local news, local weather, and traffic. A space includes the services of the entity represented by the space and the individual services and / or data notifications for accessing information about it. The discovery mechanism is represented by a locally distributed computing environment, a space service within the environment. including entities Ru, and / or one of a variety of service notified by a space in the environment or the GPS position measurement function. [0440]

In one embodiment, a wired connection to a locally distributed computing network is provided. In this environment, users of mobile client devices can "plug in" directly into the network using a wired "docking station." Examples of wired connections include, but are not limited to, Universal Serial Bus (USB), FireWire, and Twisted Pair Internet. In one embodiment, the talking station further comprises input / output features such as a keyboard, mouse, and display for mobile client devices. In this embodiment, the location of the mobile client device is sent by the docking station to the lookup mechanism or discovery mechanism. [0441]

In one embodiment, the mobile client device connects to a distributed computing network. When a user of a mobile client device navigates within the wireless communication reach of a distributed computing network, the mobile client device always or at various intervals a local lookup mechanism or discovery mechanism. Provides a position vector as an input to. The mobile client device obtains the position vector from the GPS system built into or associated with the mobile client. In one embodiment, the client sends location information (eg, via XML messaging) to a local service discovery mechanism, such as the space identification mechanism described here. For example, the client may run a space discovery protocol that specifies the discovery of a space to serve within a certain range of the client's location, or the client may provide a space to notify the client's neighborhood of the service to be provided. Instantiate a space search service to search. [0442]

When a mobile client device moves within a specified range of space in a distributed computing environment, the services and / or data stored in that space are made available to the mobile client device. .. In an embodiment in which the client device periodically informs the discovery mechanism of its location, local services and / or data are automatically made available to the client user. In one embodiment, the user of the mobile client device examines a specified range of spaces. For example, a user can optionally view all restaurants within a mile of their current location. Alternatively, you can specify the range in the configuration of your local distributed computing network. For example, a city-wide distributed computing network can be configured to serve all users within three miles of the city border. In one embodiment, a visual indicator representing the various services and / or data provided by the space, such as an icon, can be displayed on the mobile client device. There, the client can access one or more of the displayed services and / or data. In one embodiment, information obtained from two or more spaces can be displayed simultaneously on a mobile client device. In one embodiment, the user can select the services and / or data to detect. For example, in a shopping mall, a user carrying a mobile client device can optionally view all shoe stores in the mall. [0443]

In one embodiment, the executable code and / or data used to execute the code can be downloaded to a mobile client device to allow the user to execute an application provided by a service in the space. For example, a movie enthusiast can download interactive movie reviews from a service in the theater space and send back real-time feedback on the movie they're watching, if they have a mobile client device. it can. In one embodiment, the XML object compilation / decompilation mechanism is used to compile code and / or data to output an XML representation of the code and / or data, as described elsewhere. The XML representation can be decompiled to reproduce the code and / or data on a mobile client device. In one embodiment, an executable version of the process already exists on the mobile client device, and the stored state of the process is downloaded to the mobile client device to use the stored state of the user. The process can be executed. In one embodiment, an executable version of the process already exists on the mobile client device and the process data can be downloaded to the mobile client device. For example, you can download the data and view it in a viewer program on your mobile client device. In one embodiment, an executable version of the process, including code and data for running the process, can be downloaded and run on a mobile client device. In one embodiment, the service runs the application remotely on behalf of the mobile client device, allowing the service and the client to exchange XML messages containing data and optionally an XML schema that describes the data. In one embodiment, on the service You can run some code on the client and some code on the client. For example, a service can execute code that performs operations on a data set, such as numerical calculations. The mobile client device displays some of the data passed from the service to the client in an XML message, allowing the user of the mobile client device to enter and select data, and send the data to the service for data. Execute code that allows you to perform one or more operations on a client. [0444]

In one embodiment, the mobile client device can connect to two or more services simultaneously within a distributed computing network. These services can be used independently or in conjunction with performing a series of tasks. For example, one service is used by a remote client device to identify and / or perform operations on a data set, and a second service is used to print the data set. [0445]

FIG. 38 is a diagram of a mobile client device accessing a space on a local distributed computing network in one embodiment. Users of the GPS-enabled mobile computing device 1700 move within the vicinity of a locally distributed computing environment. The mobile client device 1700 sends the location provided by GPS1702 to one or more discovery mechanisms 1706 within the local distributed computing network. The discovery mechanism 1706 uses the GPS location provided by the mobile client device and the given location of the space in the environment to allow the user to use one or more spaces within a specified range or within the environment at any time. Determine if one or more spaces move within the corresponding neighborhood. For example, discovery mechanism 1706 can determine that mobile client device 1700 has moved within space 1704. The discovery mechanism 1706 then sends one or more notifications 1710 from space 1704 to mobile client device 1700. Separately, the discovery mechanism 1706 is a Universal Resource for one or more notifications in space 1704 or space 1704. Send the Identifier (URI) to the mobile client device 1700. Icons representing the data represented by the various services and / or content notifications 1710 notified by the service notification 1708 can be displayed on the mobile client device 1700. There, the user can select one or more of the services and / or data notified to run and / or view on the mobile client device. The mobile computing device 1700 establishes a wireless connection with the device providing the service, communicates with the device, and uses the XML-based messaging system to perform the service as described above. Separately, users of the Mobile Computing Device 1700 connect to the device at the docking station. The location of the docking station is whether the user can discover and use the location of the stocking station within the user's range using the lookup mechanism or discovery mechanism 1706 and the space containing the docking station notification. Is discovered by discriminating. The discovery mechanism 1706 can also detect when the mobile client device 1700 moves within a selected range of space 1714. Make various service notifications 1718 and content notifications 1720 available to users of mobile client device 1700. When a mobile client device goes out of one specified range of a space, the notification provided by that space is removed from the display of the mobile client device 1700. In one embodiment, the notification on the space includes location information of the service or data provided. Therefore, the discovery mechanism 1706 determines when the mobile client device 1700 has moved within a specified range of a particular service notified on space 1718 and is mobile. [0446]

Computing devices are downsizing while gaining power and functionality at the same time. Storage devices, CPUs, RAM, I / O ASICS, power supplies, etc. are smaller in size, allowing smaller mobile client devices to incorporate many of the features of a full-size computer. However, some of the components of a computer system cannot be easily scaled down due to human and other factors. These components include, but are not limited to, keyboards, monitors, scanners, and printers. Mobile client devices cannot truly take over the role of a personal computer due to the limitations of reducing the size of some components. [0447]

In one embodiment, a docking station is presented that allows a user to use a mobile client device and connect to and use components that are not available on the mobile client device due to human or other factors. For example, docking stations can be prepared in public places such as airports and libraries. The docking station comprises a monitor, keyboard, printer, or other device for users using mobile client devices. In one embodiment, the docking station will not function fully without the help of the actual computing device, such as the mobile client device to which the user is connected. The docking station provides services such as various I / O functions to clients that use the computing power of mobile client devices. [0448]

The docking station provides mobile client devices with one or more connectivity options. Connection options include wireless and wired connections. Examples of wireless connections include, but are not limited to, infrared rays such as IrDA, such as those provided by notebook computer network interface cards (NICs), and wireless network connections. Examples of wired connections include, but are not limited to, USB, FireWire, and twisted pair Ethernet. [0449]

The mobile client device discovers the location of the docking station using a method substantially similar to that described above for mobile client devices. To discover the location of one or more docking stations in a locally distributed computing network, use the discovery mechanism to discover the space where the docking station notifications are located. The mobile client device sends the location to the discovery mechanism. In one embodiment, the discovery or lookup mechanism returns the location of one or more docking stations closest to the location of the mobile client device. Separately, the discovery or lookup mechanism returns the URI of the space containing the docking station notification, after which the mobile client device connects to the space and one or more near the device. Send the location of the docking station. In one embodiment, the mobile client device informs the lookup or discovery mechanism and specifies requirements such as monitor resolution, screen size, graphics capabilities, and available devices such as printers and scanners. can do. In one embodiment, information about one or more docking stations, such as the availability of different docking stations (from other users of the docking station), components, and capabilities, is provided on the mobile client device. Provide to the user. [0450]

The billing protocol begins when the user approaches the docking station. When the docking station accepts the request, a secure I / O connection is established between the mobile client device and the docking station. Separately, the user selects a docking station from among one or more docking stations discovered using the lookup or discovery mechanism displayed on the mobile client device. When the user selects a docking station, the billing protocol starts and the user is given a secure and exclusive connection to the docking station for the duration of the billing. It also defines how to release the docking station so that the user ends the session on the docking station and opens the docking station for use by other users. In one embodiment, the billing protocol can be a lease on the docking station service as described above. [0451]

FIG. 39a is a diagram showing that, in one embodiment, a user of a mobile device discovers the location of a docking station. The mobile client device 1750 connects with the discovery mechanism 1756. Mobile client device 1750 GPS The position obtained using 1752 is sent to the discovery mechanism 1756. The mobile client device 1750 also sends the docking station requirements to the discovery mechanism 1756. Discovery mechanism 1756 searches for one or more spaces 1754 for notifications from docking station 1758 that meet the requirements of mobile client device 1750. In one embodiment, the lookup or discovery mechanism compares the location information stored in Notification 1758 to the given location on the mobile device 1750 and is within the specified range of the mobile device 1750 or. Identify multiple docking stations. The discovery mechanism 1756 then gives the location of one or more docking stations within the specified range of mobile client device 1750. Separately, the discovery mechanism 1756 identifies the docking station closest to the mobile client device 1750 and sends its location to the mobile client device 1750. [0452]

FIG. 39b is a diagram of a mobile client device 1750 connected to the docking station 1760 according to one embodiment. In one embodiment, the user wirelessly connects the mobile client device 1750 to the docking station 1760. In another embodiment, the user connects the docking station 1760 with the mobile client device 1750 with one or more cables to establish a wired connection with the cooking station 1760. In one embodiment, the user of the mobile client device 1750 establishes a bill to the docking station 1760. This claim establishes a secure and exclusive authority to the docking station during the connection time. In one embodiment, the billing mechanism is a resource (docking station) leasing mechanism, as described above. In one embodiment, the user is charged for the use of the docking station. For example, a user specifies a credit card number as part of the process of billing a docking station. See the description of the invoice gate in the "Message Gate" section. Once connected, users can use various features provided by the docking station 1760, such as keyboards, monitors, and printers. Docking Station 1760 also includes connections to locally distributed computing networks to notify users of mobile client device 1750 connected to Docking Station 1760 of the services and content of other devices in the network. By providing identifying discovery services, users can identify and use various services and content within a distributed computing environment, as described above. [0453]

The user disconnects the mobile client device 1750 from the docking station 1760 when finished. In one embodiment, the docking station release mechanism automatically initiates when the mobile client device 1750 disconnects from the docking station 1750. This release mechanism clears the billing for docking station 1760 established by the user of mobile client device 1750. In one embodiment, this release mechanism notifies the discovery mechanism that a docking station is available to 1756 and / or docking station notification 1758. [0454]

In one embodiment, the user can connect the mobile client device to the docking station without using the discovery mechanism. For example, a user at an airport can visually find and connect a mobile client device at a docking station. Another example would be a library with a docking station room with multiple docking stations, where users could access the available docking stations. [0455]

Space-saving and / or embedded device Simple embedded or space-saving devices may have limited memory capacity to store and execute program instructions. Simple embedded devices need to be aware that there is a limit to the control inputs to initiate the function of the device and the outputs to report the status of the device. An example of a simple embedded device is a "smart" switch (such as a lighting switch) that incorporates a switch and a circuit to control the device controlled by the switch. The smart switch only needs to recognize two control requests (change device state, request device state) and send one status message (device state). A smart switch can manage connected devices by receiving control requests from one or more control systems and reporting status messages to that one or more control systems. [0456]

In one embodiment, the distributed computing environment provides a framework (protocol) for including small devices that lack the resources (such as memory) needed to implement the full protocol of the distributed computing environment. In one embodiment, an agent is provided as a bridge between the small device-aware protocol and the full protocol. This agent performs a complete protocol discovery for small devices, so the device does not need to perform a complete discovery protocol and service activation. In one embodiment, the small device only needs to send a service-specific message. In one embodiment, these messages are pre-processed on a small device, which simply sends a message to the agent that is part of the service activation. The agent can perform service activation on the service via the full protocol, forwarding incoming messages from the service to the service, and servicing forwarding replies to the client. Therefore, the agent acts as a service connector for small clients. In one embodiment of a distributed computing environment, an embedded device can be configured to receive a specific set of control requests in the form of XML messages and send a specific set of XML messages to create requests, reporting status, and so on. .. In one embodiment, the control system can be configured to send XML request messages specific to each controlled device or category of devices and manage different devices by receiving XML messages from the devices. In one embodiment, one or more XML schemas can be used to define a unique set of XML messages for the embedded device, which is the embedded device and / when sending and receiving XML messages. Or used by the control system. [0457]

Embedded devices include a "lightweight (thin)" implementation of an XML messaging system as described above that supports a specific set of messages for controlling and monitoring simple embedded devices. The implementation of the XML messaging system has been tweaked for use on simple, space-saving embedded devices to accommodate the limited memory of space-saving devices. In one embodiment, the XML messaging system can be implemented in a space-saving device that includes a virtual machine (eg, KVM) that targets the space-saving embedded device. The networking stack (which supports transport protocols for communicating with one or more control systems) is associated with virtual machines, and the XML messaging layer is "topped" on the networking stack. Note that such implementations of messaging systems can be used on devices other than space-saving and embedded devices. [0458]

In one embodiment, a static message or a pre-generated message is used to make a request from the control system to the embedded device. Static messages are precompiled and stored inside the embedded device. It compares the incoming message to the stored static message, checks for a match in the message, and performs the function requested by the message, reducing the need for code to parse the incoming message, or You don't have to. Outgoing messages are read directly from the stored static messages, so there is little or no need to dynamically compile outgoing messages. Therefore, static messages are used to reduce the amount of code in the messaging layer of embedded systems. For example, you can use static Java objects (Java op code) for request and status messages. [0459]

FIG. 40a shows an embodiment of the embedded devices 1804a and 1804b controlled by the control system 1800 according to one embodiment. Control system 1800 is networked in various ways with the devices 1804a and 1804b that the system controls. The network 1810 can be wired (Ethernet, coaxial, twisted pair, power grid, etc.) and / or wireless (IrDA, microwave, etc.). In one embodiment, embedded devices 1804a and 1804b include a thin implementation of an XML messaging system to communicate with control system 1800 over network 1810. Control system 1800 provides an implementation of an XML messaging system for sending requests to embedded devices 1804a and 1804b and receiving responses from them. In one embodiment, the control system 1800 includes software and hardware configured to provide an interface for the user to view the status of the embedded devices 1804a and 1804b and to control them remotely. In one embodiment, the control system 1800 comprises software and / or hardware for automatic control of the embedded devices 1804a and 1804b. [0460]

In one embodiment, the embedded devices 1804a and 1804b are part of the other environment. Those devices do not support the message communication model implemented in a distributed network environment. For example, these devices are nodes in a networked automation and control system, such as the LonWorks network. Control system 1800 includes control system hardware and / or software for controlling devices in other environments. Control system 1800 is used as a bridge between a distributed computing environment and other environments. The distributed computing environment also provides one or more ways to wrap existing device discovery protocols to discover devices accessed from the distributed computing environment. The bridging and wrapping protocols are described in detail in the "Bridge" section. [0461]

Control system 1800 connects to one or more other systems in a distributed computing environment, either remotely or locally. Figure 40a shows control system 1800 connected to client 1806 via internet 1802. Client 1806 indirectly requests the status of embedded devices 1804a and 1804b through control system 1800 and sends the control request. Therefore, control system 1800 is used as a proxy or bridge for embedded devices 1804a and 1804b. See the "Bridge" section. To enable advanced communication between client 1806 and control system 1800, the client and control system is equipped with an implementation of an XML messaging system that differs from the thin implementation on embedded devices 1804a and 1804b. In one embodiment, the client 1806 includes software and hardware configured to provide an interface for the user to view and remotely control the status of the embedded devices 1804a and 1804b. In one embodiment, the client 1806 needs to present the correct authorization certificate to the control system 1800 so that the client 1806 can access the embedded devices 1804a and 1804b. In one embodiment, client 1806 is granted different levels of access. For example, client 1806 can only view the status of embedded devices 1804a and 1804b and cannot remotely control the device. In one embodiment, the control system 1800 is a service and service notifications are published in a distributed computing environment so that the client 1806 can be accessed using the client-service technique as described above. In one embodiment, client 1806 can display the status of control system 1800 and control it remotely. [0462]

FIG. 40b shows a client control system 1808 connected to embedded devices 1804c and 1804d via the Internet 1802, according to one embodiment. In one embodiment, the embedded devices 1804c and 1804d include a thin implementation of an XML messaging system to communicate with the client control system 1808 over network 1802. Client control system 1808 provides an implementation of an XML messaging system for sending requests to and receiving responses from embedded devices 1804c and 1804d. In one embodiment, the client control system 1808 includes software and hardware configured to provide an interface for the user to view and remotely control the status of the embedded devices 1804c and 1804d. In one embodiment, the client control system 1800 comprises software and / or hardware for automatic control of the embedded devices 1804c and 1804d. [0463]

The difference between Figures 40a and 40b is that in the embodiment shown in Figure 40b, the embedded devices 1804c and 1804d are one or more clients in a distributed computing environment without a proxy (eg, a control system). The point is that it is accessed by. Embedded devices 1804c and 1804d provide services to access the functionality of the device, publish service notifications within a distributed computing environment, and are accessed via the client-service approach as described above. [0464]

A distributed computing environment provides a mechanism for resource-constrained clients to retrieve Universal Resource Identifier (URI) addressing resources. For example, a client that can only send and receive messages via an IrDA connection cannot establish a URI connection and retrieve results from the result space. In one embodiment, the service is provided as a bridge between the client and the URI resource. The bridge service interacts with the client via XML messages and collects input parameters. The following is an example of XML input message syntax, but it is not intended to be restricted in any way. &lt;type name = "HttpGet"&gt; &lt;element name = "urlstring" type = "string" /&gt; &lt;/ type&gt; [0465]

Next, outside the distributed computing environment, the bridge service establishes a URI connection and retrieves resources. The resource is encapsulated as a payload in one or more XML messages and sent to the client by the bridge service. [0466]

An example of possible uses of an embedded device with a thin implementation of an XML messaging system is provided for illustration purposes, but is not intended to be limited. Buildings have multiple energy-consuming electronic devices (eg, lighting, air conditioning, office equipment) that require systems to maintain optimal energy consumption levels. Each such device comprises an embedded device for controlling an electronic device. These embedded devices include a thin implementation of an XML messaging system. Combine one or more control systems into a network, such as a building LAN or even a device in the Internet. The control system stores and runs the building management software package and the implementation of the XML messaging system that is configured to be used by the software package to monitor and control the device. The control system accepts input from the user, displays the status information of the energy consuming system in the building, including the status information of each of the plurality of devices, and outputs it by some other method. Energy consumption is monitored by receiving XML status messages from each of multiple devices. If you need to adjust your energy consumption level, send an XML control message to one or more devices to change your energy consumption. [0467]

Service implementation In one embodiment, the distributed computing environment comprises a mechanism for implementing a service as a Servlet. This mechanism provides the ability to develop services for distributed computing environments. [0468]

In one embodiment, an application programming interface (API) is provided that has the ability to initialize and register services within a space. In one embodiment, this API can be used to call the service initialization function to generate an initialization status page that defines the status of the service, such as an HTML page. The user can access the status of the service by accessing the status page from a browser. In one embodiment, an API is used to process an incoming message and generate a document in response to that message. Embodiments of the Servlet mechanism provide a plurality of functions, but not limited to, as follows. Manage client connections to services (unique session ID) Manage the activation space used to store result notifications Managing leases for connection sessions and results in the activation space Garbage collection of sessions and results Client authentication Generating client functionality for each session [0469]

In one embodiment, the distributed computing environment comprises a service cascade connectivity mechanism for building new complex services from other existing services. For example, from the JPEG-PostScript conversion and print services, combine the conversion and print services to create a third cascaded service. In one embodiment, access methods for two or more services are defined as access methods for cascaded services to combine two or more services into one complex service. The following service notices for Cascade Connection Services are provided for illustration purposes only and are not intended to be restricted in any way. &lt;servrice&gt; &lt;name&gt; Complex Service &lt;/ name&gt; &lt;ID&gt; ... &lt;/ ID&gt; &lt;description&gt; ... &lt;/ description&gt; &lt;AccessMethod&gt; &lt;AccessMethod&gt; &lt;name&gt; com.transcode.jpg 2ps &lt;/ name&gt; &lt;implementation&gt; http://www.transcode.com/software/jpg2ps.jar &lt;/ implementation&gt; &lt;/ AccessMethod&gt; &lt;AccessMethod&gt; &lt;name&gt; com.printer.ftpPrint &lt;/ name&gt; &lt;implementation&gt; http://www.printer.com/software/ftpprint.jar &lt;/ implementation&gt; &lt;/ AccessMethod&gt; &lt;/ AccessMethod&gt; &lt;/ Service&gt; [0470]

Conclusion Various embodiments further include receiving, sending, or storing instructions and / or data implemented as described above with respect to the carrier medium. Generally, carrier media include storage media such as magnetic or optical media and memory media, such as disks, CD-ROMs, RAM (SDRAM, RDRAM, SRAM, etc.), volatile or non-volatile media such as ROM, and networks. And / or includes transmission media or signals such as electrical, electromagnetic, or digital signals transmitted over a communication medium such as a wireless link. [0471]

Various modifications and changes are possible, as will be apparent to those skilled in the art who intend to take advantage of this disclosure. The present invention is intended to comprehensively incorporate all such modifications and modifications, and therefore the specification, appendices, and drawings should be considered for illustration, not limitation. ..

[Simple explanation of drawings]

[Figure 1]

It is a figure of the accumulation of the conventional distributed computing technology. [Figure 2]

It is a figure of the distributed computing environment programming model by one Embodiment. [Fig. 3]

FIG. 5 is a diagram of a messaging layer and a networking layer of a distributed computing environment according to an embodiment. [Fig. 4]

FIG. 5 is a diagram of a discovery service for finding a space to notify an object or service in a distributed computing environment according to one embodiment. [Fig. 5]

FIG. 5 is a diagram of a client profile that supports static and formatted messages in a distributed computing environment according to an embodiment. [Fig. 6]

It is a figure of the distributed computing model which adopts XML messaging by one Embodiment. [Fig. 7]

It is a figure of the platform-independent distributed computing environment by one Embodiment. [Fig. 8]

FIG. 5 is a diagram of a distributed computing model in which services are notified in a space according to an embodiment. [Fig. 9]

FIG. 5 is a diagram of a distributed computing model in which results are stored in space according to one embodiment. [Fig. 10]

a: Diagram of a client and service gate as a messaging endpoint within a distributed computing model according to one embodiment. b: It is a diagram showing that a message endpoint is generated according to a schema to access a service according to one embodiment. [Fig. 11]

a: It is a figure of the gate making in the distributed computing environment by one embodiment. b: Diagram of gate creation and gate pair in a distributed computing environment according to one embodiment. [Fig. 12]

FIG. 5 is a diagram of possible gate components in a distributed computing environment according to an embodiment. [Fig. 13]

FIG. 5 is a diagram of a proxy client for a conventional browser participating in a distributed computing environment according to an embodiment. [Fig. 14]

It is a figure which shows the method of providing a remote method call interface to a service by using a method gate in a distributed computing environment by one Embodiment. [Fig. 15]

It is a figure which shows the method of using a space in a distributed computing environment by one Embodiment. [Fig. 16]

It is a figure which shows the notification structure by one Embodiment. [Fig. 17]

It is a figure which shows an example of a notification state transition in which a notification is placed during its lifetime according to one embodiment. [Fig. 18]

It is a diagram of various space identification mechanisms in a distributed computing environment according to one embodiment. [Fig. 19]

It is a figure of the space association in the distributed computing environment by one embodiment. [Fig. 20]

It is a flow diagram which shows the method in which a client forms a session by a space service in a distributed computing environment by one Embodiment. [Fig. 21]

It is a figure of the space event type hierarchy of one embodiment. [Fig. 22]

It is a flow chart which shows the service instantiation in the distributed computing environment by one Embodiment. [Fig. 23]

It is the figure of the default space in the distributed computing environment by one Embodiment. [Fig. 24]

A diagram illustrating an example of a device that bridges a neighborhood-based device to another transport mechanism that allows a service provided by the neighborhood-based device to be accessed by a device outside the vicinity of the device, according to one embodiment. Is. [Fig. 25]

It is a figure which shows the method of using the lease renewal message in the distributed computing environment by one Embodiment. [Fig. 26]

a: It is a flow chart which shows the authentication service which provides the authentication certificate to a client by one Embodiment. b: According to one embodiment, it is a flow chart showing an authentication service developed on step 1002 of FIG. 26a to generate an authentication certificate. [Fig. 27]

It is a figure of one Embodiment of a bridge mechanism. [Fig. 28]

It is a figure of an example of the space discovery protocol which is mapped to the external discovery service by one Embodiment. [Fig. 29]

It is a figure which shows the method of bridging the client which is outside the distributed computing environment to the space in the distributed computing environment by one Embodiment. [Fig. 30]

It is a figure of the proxy mechanism by one Embodiment. [Fig. 31]

FIG. 5 is a diagram of an embodiment of a client comprising a related display and display service according to the embodiment. [Fig. 32]

It is a figure which shows the example which uses the schema of the dynamic display object by one Embodiment. [Fig. 33]

A: It is a diagram of a typical string representation in a C programming language. B: It is a figure which shows the example of the conventional string function. C: A diagram showing an efficient way to represent and manage strings in general, specifically space-saving systems such as embedded systems, according to one embodiment. [Fig. 34]

It is a figure which shows the process of moving an object between a client and a service by one Embodiment. [Fig. 35]

Demonstrates an embodiment that includes an extension in which a virtual machine (eg, JVM) compiles an object (eg, a Java object) into an XML representation of an object and an extension that backcompiles an XML representation of a (Java) object into a (Java) object. It is a data flow chart. [Fig. 36]

FIG. 5 is a diagram of clients and services accessing a store mechanism in a distributed computing environment according to one embodiment. [Fig. 37]

It is a figure which shows the process migration which uses the XML representation of the process state by one Embodiment. [Fig. 38]

FIG. 5 is a diagram of a mobile client device accessing a space on a local distributed computing network according to an embodiment. [Fig. 39]

a: In one embodiment, it is a diagram showing that a user of a mobile device discovers the location of a docking station. b: FIG. 6 is a diagram of a mobile client device connected to a docking station according to one embodiment. [Fig. 40]

a: It is a figure which shows one Embodiment of the embedded device which is controlled by a control system and is accessible in a distributed computing environment by one Embodiment. b: In one embodiment, it is a diagram of a device control system that connects to an embedded device accessible within a distributed computing environment via a network (eg, the Internet). [Fig. 41]

It is a flow chart which shows the creation of a new space in a distributed computing environment by one Embodiment. [Fig. 42]

It is a flow diagram which shows the protected creation of a new space in a distributed computing environment by one Embodiment. [Fig. 43]

It is a flow chart which shows the search of the space which uses the search service in the distributed computing environment by one Embodiment. [Fig. 44a]

It is a flow chart which shows the method of storing the result of a service in a space in a distributed computing environment by one Embodiment. [Fig. 44b]

It is a flow chart which shows the method of storing the result of a service in a space, and notifying a client by using an event in the distributed computing environment by one Embodiment. [Fig. 44c]

It is a flow chart which shows the method of sending the result of a service in a message in the distributed computing environment by one Embodiment. [Fig. 44d]

It is a flow chart which shows the method of returning the result of a service using a notification in a distributed computing environment according to one embodiment. [Fig. 44e]

It is a flow chart which shows the method of returning the result of a service by using the notification sent to a client in the distributed computing environment by one Embodiment. [Fig. 44f]

It is a flow diagram which shows the method of returning the result of a service using the notification stored in a space in the distributed computing environment by one Embodiment. [Fig. 44g]

It is a flow chart which shows the method of returning the result of a service by using the notification stored in a space and the notification to a client by using an event in a distributed computing environment according to one embodiment. [Fig. 45]

It is a flow chart which shows the method of sending the result of one service to another service in the distributed computing environment by one Embodiment. [Fig. 46a]

It is a figure which shows the search service and the dialogue between the search service and a client in the distributed computing environment by one Embodiment. [Fig. 46b]

It is a figure which shows the search service and the dialogue between the search service and a client in the distributed computing environment by one Embodiment. [Fig. 47]

It is a flow chart which shows the search of the document in the space in the distributed computing environment by one Embodiment. [Fig. 48]

It is a flow diagram which shows the addressing of the service using the notification stored in the space in the distributed computing environment by one Embodiment.