Reuse of shared metadata across applications via URL protocol

Abstract

Techniques for facilitating the sharing of metadata. In one set of embodiments, a metadata document is referenced by a plurality of software applications as a URL, the URL comprising a protocol component identifying a specialized protocol name and a path component identifying a name and namespace of the metadata document. The specialized protocol name indicates that the metadata document is a shared document stored in a shared metadata repository. When an application in the plurality of software applications needs to access the metadata document, the URL is passed to a URL resolver configured to identify the shared metadata repository based on configuration information associated with the application. The metadata document is then retrieved from the shared metadata repository. Since many existing application framework components and standards are adapted to reference metadata documents as URLs, embodiments of the present invention facilitate metadata reuse with minimal or no code changes to the applications or their underlying framework.

Description

BACKGROUND OF THE INVENTION

Embodiments of the present invention relate to computer software, and more particularly relate to techniques for facilitating the sharing of metadata by a plurality of software applications.

In recent years, an increasing number of software applications are being built using a metadata-driven approach. These applications (referred to herein as metadata-driven applications) are structured such that aspects of their content, behavior, and/or appearance are specified via metadata rather than program code. For example, Service-Oriented Architecture (SOA) applications typically rely on data and services that are defined using Extensible Markup Language (XML) based metadata (e.g., Web Services Description Language (WSDL) documents, XML Schema Definition (XSD) documents, etc.).

Large-scale software applications or application suites (such as the Oracle E-Business Suite developed by Oracle Corporation) may include a number of metadata-driven applications or application components that make use of the same metadata. For instance, the applications may use one or more common metadata documents that describe a standard user interface layout, standard data types, or the like. In these situations, the common metadata should be made available to all of the applications in some manner.

According to one approach, such common metadata can be made available to applications by simply duplicating the metadata in each application. Unfortunately, this approach is problematic for several reasons. For example, since each application must include its own, separate copy of the common metadata, problems may occur where applications are accidentally deployed with mismatched metadata versions, resulting in incorrect runtime behavior. Further, maintaining duplicate versions of metadata is inefficient and cumbersome. For example, the size of each application will be larger than necessary because of the duplicated metadata, and any modifications to the metadata will require updates to each duplicated copy.

According to another approach, the common metadata can be stored in a centralized location, and the various applications can retrieve the single, shared copy using proprietary means (i.e., means that do not leverage any standard access mechanisms such as Uniform Resource Locators (URLs)). While this method overcomes some of the difficulties related to duplicating common metadata, this method still has several shortcomings. For instance, each application will have to implement proprietary code for accessing the shared copy of the metadata, rendering the application incompatible with a large number of existing application framework components and standards (e.g., development tools, XML processors, WSDL, etc.) that are adapted to reference metadata documents as URLs.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the present invention address the foregoing and other such problems by providing techniques for facilitating the sharing of a metadata document by a plurality of software applications via URL protocol. In one set of embodiments, the metadata document is referenced by the plurality of software applications as a URL, the URL comprising a protocol component identifying a specialized protocol name and a path component identifying a name and namespace of the metadata document. The specialized protocol name indicates that the metadata document is a shared document stored in a shared metadata repository. When an application in the plurality of software applications needs to access the metadata document, the URL is passed to a URL resolver configured to identify the shared metadata repository based on configuration information associated with the application. The metadata document is then retrieved from the shared metadata repository. Since many existing application framework components and standards are adapted to reference metadata documents as URLs, embodiments of the present invention facilitate metadata reuse with minimal or no code changes to the applications or their underlying framework.

According to one embodiment of the present invention, a method for facilitating the sharing of a metadata document by a plurality of software applications comprises receiving, from a software application in the plurality of software applications, a URL for the metadata document, the URL including a protocol component identifying a specialized protocol name and a path component identifying a name and namespace of the metadata document. The specialized protocol name indicates that the metadata document is a shared document stored in a shared metadata repository. The shared metadata repository is then identified based on configuration information associated with the software application and (optionally) the namespace of metadata document.

In one set of embodiments, the metadata document is subsequently retrieved from the shared metadata repository. In another set of embodiments, a domain name for the shared metadata repository is determined, and the URL is transformed into a HyperText Transfer Protocol (HTTP) URL based on the domain name. The HTTP URL enables applications to retrieve the metadata document using standard HTTP protocol.

In various embodiments, the steps of receiving the URL and identifying the shared metadata repository are performed by a URL resolver configured to interoperate with a URL technology component. The URL technology component is a standard application framework component adapted to process URLs on behalf of the plurality of software applications. In one embodiment, the software applications are J2EE applications, the URL technology component is a standard Java URL class, and the URL resolver is a custom Java class that extends the standard Java URL class.

In one set of embodiments, the steps of receiving the URL and identifying the shared metadata repository are performed while the software application is running in a deployed environment. In these embodiments, the shared metadata repository may be a database repository. In another set of embodiments, the steps of receiving the URL and identifying the shared metadata repository may be performed while the software application is running in a development environment. In these embodiments, the configuration information may be associated with the development environment rather than the software application. Further, the shared metadata repository may be a file-based repository.

In some embodiments, the configuration information may include version information indicating a specific version of the metadata document used by the software application. For example, each application in the plurality of software applications may use a different version of the metadata document. In these embodiments, retrieving the metadata document comprises retrieving the specific version. In further embodiments, the configuration information may include customization information indicating a specific customized variant of the metadata document used by the software application. For example, each application in the plurality of software applications may use a different customization for the metadata document. In these embodiments, retrieving the metadata document comprises retrieving the specific customized variant. The concept of metadata customizations is discussed in greater detail in U.S. patent application Ser. Nos. 12/029,600, 12/029,605, 12/029,609, 12/029,615, and 12/029,724, assigned to Oracle Corporation, which are hereby incorporated by reference in their entireties for all purposes.

According to another embodiment of the present invention, a system for facilitating the sharing of a metadata document by a plurality of software applications is provided. The system comprises a standard URL technology component adapted to process URLs on behalf of the plurality of software applications, and a custom URL resolver in communication with the URL technology component. In various embodiments, the custom URL resolver is configured to receive, from a software application in the plurality of software applications via the URL technology component, a URL for the metadata document, the URL including a protocol component identifying a specialized protocol name and a path component identifying a name and namespace of the metadata document. The specialized protocol name indicates that the metadata document is a shared metadata document stored in a shared metadata repository. The custom URL resolver is further configured to identify the shared metadata repository based on configuration information associated with the software application and (optionally) the namespace of the metadata document. In various embodiments, the metadata document may then be retrieved from the shared metadata repository. Alternatively, a domain name for the shared metadata repository may be determined, and the URL may be transformed into a HyperText Transfer Protocol (HTTP) URL based on the domain name.

According to yet another embodiment of the present invention, a machine-readable medium for a computer system is disclosed. The machine-readable medium has stored thereon a series of instructions which, when executed by a processing component, cause the processing component to receive, from a software application in a plurality of software applications, a URL for a metadata document, the URL including a protocol component identifying a specialized protocol name and a path component identifying a name and namespace of the metadata document. The specialized protocol name indicates that the metadata document is a shared metadata document stored in a shared metadata repository. The series of instructions further cause the processing component to identify the shared metadata repository based on configuration information associated with the software application and (optionally) the namespace of the metadata document. In various embodiments, the metadata document may then be retrieved from the shared metadata repository. Alternatively, a domain name for the shared metadata repository may be determined, and the URL may be transformed into a HyperText Transfer Protocol (HTTP) URL based on the domain name.

A further understanding of the nature and advantages of the embodiments disclosed herein may be realized by reference to the remaining portions of the specification and the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present invention will be described with reference to the drawings, in which:

FIG. 1 is a flowchart illustrating steps performed in facilitating the sharing of metadata in accordance with an embodiment of the present invention.

FIG. 2 is sample code illustrating configuration information that may be associated with a software application in accordance with an embodiment of the present invention.

FIG. 3 is a simplified block diagram illustrating a system for facilitating the sharing of metadata in the context of a deployed environment in accordance with an embodiment of the present invention.

FIG. 4 is a simplified block diagram illustrating a system of facilitating the sharing of metadata in the context of a development environment in accordance with an embodiment of the present invention.

FIG. 5 is a flowchart illustrating additional steps that may be performed in facilitating the sharing of metadata in accordance with an embodiment of the present invention.

FIG. 6 is a simplified block diagram illustrating a system for facilitating the sharing of metadata by internal and external applications in accordance with an embodiment of the present invention.

FIG. 7 is a simplified block diagram of a system environment that may be used in accordance with an embodiment of the present invention.

FIG. 8 is a simplified block diagram of a computer system that may be used in accordance with an embodiment of the present invention.

In the drawings, the use of like reference numbers in different drawings indicates similar components.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide an understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details.

Embodiments of the present invention provide techniques for facilitating the sharing of a metadata document by a plurality of software applications. As described in further detail below, this sharing is achieved by having each application reference the metadata document using a specific type of URL. This URL includes a protocol component identifying a specialized protocol name (e.g., “oraclemds”) and a path component identifying a name and namespace of the metadata document. The specialized protocol name indicates that the metadata document is a shared document stored in a shared metadata repository. When an application needs to resolve the URL (i.e., determine the location of the metadata document), the URL is passed to a URL resolver integrated into the underlying application framework of the plurality of software applications. The URL resolver identifies the shared metadata repository based on configuration information associated with the application, as well as (optionally) the namespace of the metadata document. The metadata document is then retrieved from the metadata repository. In situations where the URL needs to be published for external consumption, the URL may be transformed into a standard HTTP URL.

Since embodiments of the present invention allow common metadata to be centralized at a single, shared location, the problems associated with duplicating metadata in different applications are minimized or avoided. Further, since the present techniques use URLs as metadata references, these techniques may be used in conjunction with existing application framework components and standards (e.g., development tools, XML processors, WSDL, etc.) that are adapted to reference metadata documents as URLs.

In some embodiments, the configuration information associated with each application may include additional information that is used by the URL resolver to retrieve the shared metadata document. For example, the configuration information may include version information indicating a specific version of the metadata document used by an application. Additionally, the configuration information may include customization information indicating a specific customization for the metadata document used by an application.

Embodiments of the present invention may be used in a variety of different domains and contexts. Certain embodiments are particularly applicable to enterprise software applications, which are often configured to make use of common metadata. However, embodiments of the present invention may be used to facilitate the sharing of metadata by any type of software application. Further, the sharing techniques described herein may be used throughout the lifecycle of a software application. For example, the sharing techniques may be used to facilitate metadata reuse during application development, testing, and deployment.

FIG. 1 is a flowchart 100 illustrating steps performed in facilitating the sharing of a metadata document by a plurality of software applications in accordance with an embodiment of the present invention. In various embodiments, the processing of flowchart 100 may be implemented in software, hardware, or combinations thereof. For example, as software, flowchart 100 may be implemented as part of a URL resolver configured to resolve URLs on behalf of the plurality of applications. Further, such software may be stored on a machine-readable medium. An example a URL resolver is discussed in greater detail below with respect to FIG. 3.

At step 102, a URL for a metadata document is received from a software application in the plurality of software applications. The URL includes a protocol component identifying a specialized protocol name, such as “oraclemds.” The specialized protocol name indicates that the metadata document referenced by the URL is a shared document that is stored in a shared metadata repository. In various embodiments, the specialized protocol name is a unique name that is different from any standard or well-known URL protocol, such as HTTP, FTP, or the like. The URL also includes a path component identifying a name and namespace for the metadata document. An example of such a URL is “oraclemds://soa/shared/workflow/taskservice.wsdl,” where the protocol component is “oraclemds://” and the path component is “soa/shared/workflow/taskservice.wsdl.”

At step 104, the URL is recognized as referencing a shared metadata document, and the shared metadata repository in which the document is stored is identified. In one set of embodiments, the identification is based on configuration information that is associated with the software application. For example, the configuration information may indicate a name and/or location of the shared metadata repository. In additional embodiments, the identification is further based on the namespace of the metadata document. The structure and content of the configuration information is discussed in greater detail below with respect to FIG. 2.

Once the shared metadata repository has been identified, the metadata document is retrieved from the repository on behalf of the software application (step 106). In this manner, the software application (as well as any other application in the plurality of software applications) may access and reuse a single, shared copy of the metadata document. In some embodiments, the shared metadata document (or a metadata document referencing the shared metadata document) may need to be published for external consumption (i. e., for use by one or more external software applications that do not have access to a URL resolver performing the steps of flowchart 100). In these cases, the URL received in step 102 may be transformed into a standard HTTP URL that can be used by external software applications to retrieve the shared metadata document. This process of transforming URLs is discussed in greater detail below with respect to FIGS. 5 and 6.

It should be appreciated that the specific steps illustrated in FIG. 1 provide a particular method for facilitating the sharing of a metadata document according to an embodiment of the present invention. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Moreover, the individual steps illustrated in FIG. 1 may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular application. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.

FIG. 2 is sample code illustrating configuration information 200 that may be associated with a software application as described in flowchart 100 of FIG. 1. In an embodiment, each software application configured to make use of shared metadata is associated with its own configuration information/file. As shown, configuration information 200 may be formatted in a structured language such as Extensible Markup Language (XML). However, one of ordinary skill in the art will appreciate that configuration information 200 may be formatted in any standardized or proprietary manner.

Configuration information 200 is adapted to reference one or more shared metadata repositories that may be used to store a shared metadata document. For example, configuration information 200 identifies two metadata stores (i.e., repositories) “mstore-usage_—2” and “mstore-usage_—3,” along with their physical addresses. The physical addresses may correspond to local or remote locations. Configuration information 200 may also include one or more namespace-to-repository mappings, such as the “metadata-namespaces” illustrated in FIG. 2. In some embodiments, these mappings may be used to determine a shared metadata repository for a metadata document based on its namespace. For example, configuration information 200 indicates that metadata documents having the namespace “/loan/flow” should be retrieved from “mstore-usage_—2,” and metadata documents having the namespace “/soa/shared” should be retrieved from “mstore-usage_—3.”

Although not shown, configuration information 200 may also include other information that is used to retrieve a shared metadata document on behalf of an associated software application. For example, configuration information 200 may include version information that identifies a particular version of the metadata document used by the application. Further, configuration information 200 may include customization information that identifies a particular customization (i.e., customized variant) of the metadata document used by the application. In this manner, various reusing applications may refer to a different version/customization of shared metadata. In a case wherein no versioning information for a metadata document is specified in the configuration information, the latest version of the metadata document may be automatically retrieved.

In some embodiments, configuration information 200 may be automatically generated by a development tool at design time of the associated software application. Further, the appropriate URLs for referencing shared metadata documents may be automatically created.

FIG. 3 is a simplified block diagram illustrating a system 300 for facilitating the sharing of a metadata document in the context of a deployed application environment according to an embodiment of the present invention. As shown, system 300 includes one or more deployed software applications 302, 304, a plurality of application framework components (e.g., metadata processor 306, URL technology component 308, URL resolver 310), and one or more shared metadata repositories 312. In one set of embodiments, applications 302, 304 are Java 2 Enterprise Edition (J2EE) applications, and application framework components 306, 308, 310 are Java-based components. Shared metadata repository 312 may correspond to either a database or file-based repository, but in a deployed environment it will commonly be a database. Although only one repository 312 and two applications 302, 304 are depicted, any number of repositories and applications may be supported.

In various embodiments, Applications 302, 304 are structured to include one or more metadata documents, such as WSDL or XML Schema Definition (XSD) documents. These metadata documents are, in turn, structured to include references to one or more shared metadata documents via URLs having the format described in flowchart 100 of FIG. 1.

At application runtime, the metadata documents included in an application 302, 304 are passed to metadata processor 306. Metadata processor 306 may be any conventional application framework component capable of parsing/processing structured metadata. In one embodiment, processor 306 is an XML parser/processor. As the metadata documents are being processed, the URLs included therein are passed to URL technology component 308. Like metadata processor 306, URL technology component 308 may be any conventional application framework component capable of processing standard URLs. In one embodiment, URL technology component 308 corresponds to an instance of the standard Java URLScheme class.

In various embodiments, the URLs from application 302, 304 are then passed from URL technology component 308 to URL resolver 310. Unlike metadata processor 306 and URL technology component 308, URL resolver 310 is a custom application framework component unique to embodiments of the present invention. Specifically, URL resolver 310 is a custom component adapted to resolve URLs for shared metadata documents in accordance with the steps of flowchart 100. For example, URL resolver 310 is configured to receive a metadata document URL having the specialized protocol name described with respect to flowchart 100 (e.g., “oraclemds”), and identify a shared metadata repository (e.g., 312) storing the metadata document based on configuration information associated with respective application 302, 304. The metadata document is then retrieved from the shared metadata repository on behalf of the application. In one embodiment, URL resolver 310 corresponds to a custom Java class that extends the standard URLScheme class.

Since URL resolver 310 interoperates with existing application framework components such as metadata processor 306 and URL technology component 308, embodiments of the present invention facilitate the sharing of metadata by a plurality of applications with minimal code changes to the applications and their underlying framework. Further, since URLs are dynamically resolved using configuration information (rather than being statically defined), the shared metadata repository can be moved from one physical location to another without requiring changes to the URLs.

In some embodiments, URL resolver 310 may be configured to automatically resolve relative URLs (i.e., URLs that do not include any protocol name) in shared metadata documents. Thus, for example, if a first shared metadata document “foo/mydoc1.xsd” references a second shared metadata document via a relative URL (such as “shared/mydoc2.xsd”), the second shared metadata document will be automatically retrieved as “oraclemds://foo/shared/mydoc2.xsd.”

As discussed previously, the sharing techniques of the present invention may be used throughout the lifecycle of an application. For example, these techniques may be used while an application is still in development. FIG. 4 is a simplified block diagram illustrating a system 400 for facilitating the sharing of a metadata document in the context of an application development environment according to an embodiment of the present invention. Specifically, FIG. 4 illustrates an application being developed in a development environment 402, wherein development environment 402 is configured to run the application with the help of application framework components 306, 308, 310 and a shared metadata repository 404. In this example, components 306, 308, 310 are identical to the similarly numbered components of FIG. 3. Shared metadata repository 404 may correspond to either a database or file-based repository, but in a development context it will commonly be file-based.

As with applications 302, 304 of FIG. 3, the application being developed in development environment 402 is structured to include one or more metadata documents which are, in turn, structured to include references to one or more shared metadata documents via URLs having the format described in flowchart 100 of FIG. 1.

When the application is executed in development environment 402, the URLs included therein are passed through standard components 306, 308 as described above for FIG. 3. The URLs are then received at custom URL resolver 310, which is configured to identify a shared metadata repository (e.g., 404) for the referenced metadata documents based on configuration information. In one embodiment, the configuration information is associated with development environment 402, such that the configuration information is common to all applications executed in the development environment. In other embodiments, the configuration information is specific to the application presently running in the development environment. Once the shared metadata repository is identified, the shared metadata documents are retrieved on behalf of the application.

In one set of embodiments, development environment 402 may be configured to automatically generate configuration information (such as configuration information 200 of FIG. 2) for an application, as well as verifying that URLs for shared metadata documents include the specialized protocol name described in step 102 of flowchart 100. Once the application is deployed, no further changes need to be made to the URLs; only the configuration information needs to be modified to point to the deployed location of the shared metadata repository.

FIG. 5 is a flowchart 500 illustrating further steps that may be performed in facilitating the sharing of metadata in accordance with an embodiment of the present invention. Specifically, flowchart 500 illustrates the steps performed in converting a URL for a shared metadata document into a standard HTTP URL. This enables external applications (i.e., applications that do not have access to URL resolver 310 of FIG. 3) to retrieve the shared metadata document. The processing of flowchart 500 may be performed, for example, when a metadata document referencing a shared metadata document is accessed by an external application. Alternatively, the processing of flowchart 500 may be performed when the shared metadata document itself is directly accessed by the external application.

Assuming that steps 102 and 104 of flowchart 100 have been executed, a domain name for the shared metadata repository identified in step 104 is determined (step 502). In one embodiment, the domain name corresponds to a network address of a web server configured to serve data stored in the repository. The URL received at step 102 is then transformed into a standard HTTP URL based on the domain name (step 504). For example, the URL “oraclemds://soa/shared/mydoc.xml” may be transformed into “http://mds1/soa/shared/mydoc.xml,” where “mds1” is the domain name determined at step 502. This HTTP URL may then be used to retrieve “mydoc.xml” using standard HTTP protocol.

FIG. 6 is a simplified block diagram illustrating a system 600 configured to implement the processing of flowcharts 100 and 500 to facilitate the sharing of metadata with external applications. As shown, system 600 includes one or more external applications 602 in communication with a servlet 604. Servlet 604 is communicatively coupled with internal applications 302, 304, application framework components 306, 308, 310, and a shared metadata repository 312. Servlet 604 is configured to publish metadata stored in shared metadata repository 312 to external applications 602. For example, servlet 604 may publish a WSDL file for a web service used by the external applications. However, since external applications 602 do not have direct access to URL resolver 310, the metadata published by servlet 604 may include shared metadata URLs (e.g., “oraclemds” URLs) that cannot be resolved by the external applications.

To address the above problem, servlet 604 is configured to pass the shared metadata URLs to URL resolver 310 via an appropriate internal application 302, 304 and application framework components 306, 308. In response, URL resolver 310 is configured to perform the processing of flowcharts 100 and 500 to transform the URLs into standard HTTP URLs. The standard HTTP URLs are then passed back to servlet 604, which publishes the standard HTTP URLs to external applications 602. In this manner, embodiments of the present invention allow internal applications to make use of the specialized URL protocol described herein to share metadata documents, while maintaining interoperability with external applications.

FIG. 7 is a simplified block diagram illustrating components of a system environment 700 that may be used in accordance with an embodiment of the present invention. As shown, system environment 700 includes one or more client computing devices 702, 704, 706, 708, which are configured to operate a client application such as a web browser, proprietary client (e.g., Oracle Forms), or the like. In various embodiments, client computing devices 702, 704, 706, 708 may be used to interact with one or more software applications, such as applications 302, 304 of FIG. 3.

Client computing devices 702, 704, 706, 708 may be general purpose personal computers (including, by way of example, personal computers and/or laptop computers running various versions of Microsoft Windows and/or Apple Macintosh operating systems), cell phones or PDAs (running software such as Microsoft Windows Mobile and being Internet, e-mail, SMS, Blackberry, or other communication protocol enabled), and/or workstation computers running any of a variety of commercially-available UNIX or UNIX-like operating systems (including without limitation the variety of GNU/Linux operating systems). Alternatively, client computing devices 702, 704, 706, 708 may be any other electronic device, such as a thin-client computer, Internet-enabled gaming system, and/or personal messaging device, capable of communicating over a network (e.g., network 710 described below). Although system environment 700 is shown with four client computing devices, any number of client computing devices may be supported.

In most embodiments, system environment 700 includes a network 710. Network 710 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including without limitation TCP/IP, SNA, IPX, AppleTalk, and the like. Merely by way of example, network 710 can be a local area network (LAN), such as an Ethernet network, a Token-Ring network and/or the like; a wide-area network; a virtual network, including without limitation a virtual private network (VPN); the Internet; an intranet; an extranet; a public switched telephone network (PSTN); an infra-red network; a wireless network (e.g., a network operating under any of the IEEE 802.11 suite of protocols, the Bluetooth protocol known in the art, and/or any other wireless protocol); and/or any combination of these and/or other networks.

System environment 700 also includes one or more server computers 712 which may be general purpose computers, specialized server computers (including, by way of example, PC servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. In various embodiments, server 712 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server 712 may correspond to an application server configured to execute one or more applications such as applications 302, 304 of FIG. 3. Further, server 712 may be configured to execute one or more application framework components, such as URL resolver 310 of FIG. 3. In alternative embodiments, URL resolver 310 and applications 302, 304 may be run on separate machines.

Server 712 may run an operating system including any of those discussed above, as well as any commercially available server operating system. Server 712 may also run any of a variety of additional server applications and/or mid-tier applications, including HTTP servers, FTP servers, CGI servers, Java servers, database servers, and the like. Exemplary database servers include without limitation those commercially available from Oracle, Microsoft, Sybase, IBM and the like.

System environment 700 may also include one or more data repositories 714, 716. For instance, data repositories 714, 716 may include one or more application repositories 714 configured to store transactional data for applications hosted on server 712, and one or more shared metadata repositories 716 such as repository 312 of FIG. 3. Data repositories 714, 716 may reside in a variety of locations. By way of example, one or more of data repositories 714, 716 may reside on a storage medium local to (and/or resident in) server 712. Alternatively, data repositories 714, 716 may be remote from server 712, and in communication with server 712 via a network-based or dedicated connection. In one set of embodiments, data repositories 714, 716 may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to server 712 may be stored locally on server 712 and/or remotely, as appropriate. In one set of embodiments, data repositories 714, 716 may include file-based repositories. In another set of embodiments, data repositories 714, 716 may include relational databases, such as Oracle 10g, that are adapted to store, update, and retrieve data in response to SQL-formatted commands.

FIG. 8 illustrates an exemplary computer system 800 that may be used in accordance with embodiments of the present invention. In various embodiments, system 800 may be used to implement any of the computers 702, 704, 706, 708, 712 described above. Computer system 800 is shown comprising hardware elements that may be electrically coupled via a bus 824. The hardware elements may include one or more central processing units (CPUs) 802, one or more input devices 804 (e.g., a mouse, a keyboard, etc.), and one or more output devices 806 (e.g., a display device, a printer, etc.). Computer system 800 may also include one or more storage devices 808. By way of example, storage device(s) 808 may include devices such as disk drives, optical storage devices, and solid-state storage devices such as a random access memory (RAM) and/or a read-only memory (ROM), which can be programmable, flash-updateable and/or the like.

Computer system 800 may additionally include a computer-readable storage media reader 812, a communications subsystem 814 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory 818, which may include RAM and ROM devices as described above. In some embodiments, computer system 800 may also include a processing acceleration unit 816, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.

Computer-readable storage media reader 812 can further be connected to a computer-readable storage medium 810, together (and, optionally, in combination with storage device(s) 808) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. Communications system 814 may permit data to be exchanged with network 710 and/or any other computer described above with respect to system environment 700.

Computer system 800 may also comprise software elements, shown as being currently located within working memory 818, including an operating system 820 and/or other code 822, such as an application program (which may be a client application, Web browser, mid-tier application, RDBMS, etc.). In an exemplary embodiment, working memory 818 may include executable code and associated data structures (such as caches) for executing the processing of flowcharts 100 and 500 of FIGS. 1 and 5. It should be appreciated that alternative embodiments of computer system 800 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software (including portable software, such as applets), or both. Further, connection to other computing devices such as network input/output devices may be employed.

Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules, o r other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium which can be used to store or transmit the desired information and which can be accessed by a computer.

While the present invention has been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented only in hardware, or only in software, or using combinations thereof.

The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

Claims

1. A method for facilitating the sharing of a metadata document by a plurality of software applications, the method comprising: receiving, from a software application of the plurality of software applications, a uniform resource locator (URL) for the metadata document, the URL including a protocol component identifying a specialized protocol name and a path component identifying a name and namespace of the metadata document, the specialized protocol name indicating that the metadata document is stored in a shared metadata repository;wherein the specialized protocol name is a non-standard protocol name that is not one of HTTP, HTTPS, FILE, or FTP; andidentifying the shared metadata repository based on the specialized protocol name;identifying the metadata document further based on configuration information associated with the software application.

2. The method of claim 1 further comprising retrieving the metadata document from the shared metadata repository.

3. The method of claim 2, wherein the configuration information includes version information indicating a specific version of the metadata document used by the software application, and wherein retrieving the metadata document comprises retrieving the specific version.

4. The method of claim 2, wherein the configuration information includes customization information indicating a specific customized variant used by the metadata document for the software application, and wherein retrieving the metadata document comprises retrieving the specific customized variant.

5. The method of claim 1, wherein identifying the shared metadata repository is further based on the namespace of the metadata document.

6. The method of claim 1, wherein the steps of receiving the URL and identifying the shared metadata repository are performed by a URL resolver configured to interoperate with a standard URL technology component, the standard URL technology component processes URLs on behalf of the plurality of software applications.

7. The method of claim 6, wherein the plurality of applications include Java 2 Enterprise Edition (J2EE) applications, and wherein the standard URL technology component is a standard Java URL class.

8. The method of claim 7, wherein the URL resolver is a custom Java class that extends the standard Java URL class.

9. The method of claim 1, wherein the steps of receiving the URL and identifying the shared metadata repository are performed while the application is running in a deployed environment.

10. The method of claim 9, wherein the shared metadata repository is a database repository.

11. The method of claim 1, wherein the steps of receiving the URL and identifying the shared metadata repository are performed while the software application is running in a development environment.

12. The method of claim 11, wherein the shared metadata repository is a file-based repository.

13. The method of claim 1, wherein the metadata document is an Extensible Markup Language (XML) document.

14. The method of claim 1 further comprising: determining a domain name of the shared metadata repository; andtransforming the URL into a HyperText Transfer Protocol (HTTP) URL based on the domain name, wherein the HTTP URL may be used to retrieve the metadata document via HTTP protocol.

15. A system for facilitating the sharing of a metadata document by a plurality of software applications, the system comprising: a memory storing configuration information associated with the plurality of software applications;a processor coupled to the memory configured to: receive, from a software application in the plurality of software applications, a uniform resource locator (URL) for the metadata document, the URL including a protocol component identifying a specialized protocol name and a path component identifying a name and namespace of the metadata document, the specialized protocol name indicating that the metadata document is stored in a shared metadata repository; andwherein the specialized protocol name is a non-standard protocol name that is not one of HTTP, HTTPS, FILE, or FTP; andidentify the shared metadata repository based on the specialized protocol name; andidentify the metadata document based on configuration information associated with the software application.

16. The system of claim 15, wherein the processor is further configured to retrieve the metadata document from the shared metadata repository.

17. The system of claim 15, wherein identifying the shared metadata repository is further based on the namespace of the metadata document.

18. The system of claim 15, wherein the processor is further configured to: determine a domain name of the shared metadata repository; andtransform the URL into a HyperText Transfer Protocol (HTTP) URL based on the domain name, wherein the HTTP URL may be used to retrieve the metadata document via HTTP protocol.

19. A non-transitory machine-readable storage medium storing a series of instructions which, when executed by a processing component, cause the processing component to: receive, from a software application in a plurality of software applications, a uniform resource locator (URL) for a metadata document, the URL including a protocol component identifying a specialized protocol name and a path component identifying a name and namespace of the metadata document, the specialized protocol name indicating that the metadata document is stored in a shared metadata repository; andwherein the specialized protocol name is a non-standard protocol name that is not one of HTTP, HTTPS, FILE, or FTP; andidentify the shared metadata repository based on the specialized protocol name; andidentify the metadata document based on configuration information associated with the software application.

20. The machine-readable medium of claim 19, wherein the series of instructions further cause the processing component to retrieve the metadata document from the shared metadata repository.

21. The machine-readable medium of claim 19, wherein identifying the shared metadata repository is further based on the namespace of the metadata document.

22. The machine-readable medium of claim 19, wherein the series of instructions further cause the processing component to: determine a domain name of the shared metadata repository; andtransform the URL into a HyperText Transfer Protocol (HTTP) URL based on the domain name, wherein the HTTP URL may be used to retrieve the metadata document via HTTP protocol.