Jump to: navigation, search

Difference between revisions of "Open Metadata Search"

(The Architectural Overview)
Line 15: Line 15:
 
The system uses a unit wise architecture. There are different units that are used to achieve desired functions. Refer to the Appendix A for the Architectural Overview. The functions that are implemented by each unit are independent of the other units but the communication is done between units.  
 
The system uses a unit wise architecture. There are different units that are used to achieve desired functions. Refer to the Appendix A for the Architectural Overview. The functions that are implemented by each unit are independent of the other units but the communication is done between units.  
 
The functions that are expected from each unit are as summarized below.
 
The functions that are expected from each unit are as summarized below.
 +
 
'''3.1 Presentation Unit (GUI Unit)'''
 
'''3.1 Presentation Unit (GUI Unit)'''
 
This unit implements the presentation layer functions. This creates the basic GUI of the system and helps to obtain data from the user and show the relevant response.
 
This unit implements the presentation layer functions. This creates the basic GUI of the system and helps to obtain data from the user and show the relevant response.
 +
 
'''3.2 Presentation Controller Unit'''
 
'''3.2 Presentation Controller Unit'''
 
This Unit links the GUI with the internal units. This passes parameters from the GUI appropriately and displays the results accordingly.
 
This Unit links the GUI with the internal units. This passes parameters from the GUI appropriately and displays the results accordingly.
 +
 
'''3.3 EMF Access Unit'''
 
'''3.3 EMF Access Unit'''
 
This unit is responsible for dealing with EMF. It has the ability of accessing the EMF models metadata and the EMF Index. This has two sub units. These units are the EMF Models Operator and the EMF Index Operator. As the name implies the EMF Index Operator will be taking care of tasks related to accessing the EMF Index and the EMF Index Operator will be taking care of tasks related to accessing the EMF models metadata. These units are designed in such a way that they are highly extensible and inter-related.
 
This unit is responsible for dealing with EMF. It has the ability of accessing the EMF models metadata and the EMF Index. This has two sub units. These units are the EMF Models Operator and the EMF Index Operator. As the name implies the EMF Index Operator will be taking care of tasks related to accessing the EMF Index and the EMF Index Operator will be taking care of tasks related to accessing the EMF models metadata. These units are designed in such a way that they are highly extensible and inter-related.
 +
 
'''3.4 Scheduler Unit'''
 
'''3.4 Scheduler Unit'''
 
The basic functions of this unit is to trigger the system in order to get the latest EMF index. This will make sure that the index available for searching is the latest at all the time. This unit optimizes the performance by performing the index process as a background process.
 
The basic functions of this unit is to trigger the system in order to get the latest EMF index. This will make sure that the index available for searching is the latest at all the time. This unit optimizes the performance by performing the index process as a background process.
 +
 
'''3.5 Plug-in Connector'''
 
'''3.5 Plug-in Connector'''
 
This unit will connect the system to the central eclipse IDE. This will make the reset of the units run independently. The other units do not have to worry about the process of being integrated to the eclipse IDE.
 
This unit will connect the system to the central eclipse IDE. This will make the reset of the units run independently. The other units do not have to worry about the process of being integrated to the eclipse IDE.

Revision as of 02:44, 2 April 2009

(Index search for Java EE metadata)

Introduction

In working with huge projects there are many instances the developers fall into situations where they need to find Java EE metadata of certain projects. It is indeed a tedious task to remember the exact locations of all project artifacts. Generally a particular artifact is remembered by a part of the content or some other special attribute such as the file name. At such instances developers usually tend to locate the file by performing a file search available in the operating system or going for a full text search. This indeed is a tedious task and wastes a lot of time of the developer. At the same time the results obtained might be of a low degree of effectiveness. It is indeed bliss if the Developing IDE itself can provide a Java EE metadata search. Obviously this can save a lot of time of the developer and it also can deliver the most optimal results that the developers are looking for.


The Solution Overview

Open Type and Open Resource index searches in the workbench are one of the most widely benefited tools for many developers. Especially its enormous ability of locating the exact class and the file in a huge project is very helpful. If we can perform the same kind of a search for Java metadata also it will be so beneficial to general developers. It will be guaranteed that the developers get the hassle free most effective results on facts that they want to search for. This feature should be capable of being invoked by a dialog box (as it is in the case of the Open Type and Open Resource) A hotkey combination is also important so that the developers can access this feature easily. The developers should be capable of searching for the particular artifact by just typing a portion of the content or some other important aspect such as the name of it. This tool will perform the index search over the EMF models and it is expected to use the EMF index as well. Indeed this tool is more specific than that of a generic indexing system. It is expected that this will work in close relation and with higher compatibility with the other tooling as it is expected to perform the search over the Java metadata stored in EMF models rather than over raw files.

The Architectural Overview

The system uses a unit wise architecture. There are different units that are used to achieve desired functions. Refer to the Appendix A for the Architectural Overview. The functions that are implemented by each unit are independent of the other units but the communication is done between units. The functions that are expected from each unit are as summarized below.

3.1 Presentation Unit (GUI Unit) This unit implements the presentation layer functions. This creates the basic GUI of the system and helps to obtain data from the user and show the relevant response.

3.2 Presentation Controller Unit This Unit links the GUI with the internal units. This passes parameters from the GUI appropriately and displays the results accordingly.

3.3 EMF Access Unit This unit is responsible for dealing with EMF. It has the ability of accessing the EMF models metadata and the EMF Index. This has two sub units. These units are the EMF Models Operator and the EMF Index Operator. As the name implies the EMF Index Operator will be taking care of tasks related to accessing the EMF Index and the EMF Index Operator will be taking care of tasks related to accessing the EMF models metadata. These units are designed in such a way that they are highly extensible and inter-related.

3.4 Scheduler Unit The basic functions of this unit is to trigger the system in order to get the latest EMF index. This will make sure that the index available for searching is the latest at all the time. This unit optimizes the performance by performing the index process as a background process.

3.5 Plug-in Connector This unit will connect the system to the central eclipse IDE. This will make the reset of the units run independently. The other units do not have to worry about the process of being integrated to the eclipse IDE.

Technologies Used and the Implementation

This system will be dealing with the EMF models very closely. It is expected to use some available open source frameworks at the different units of the system. The system is designed and implemented in such a way that there would be a higher degree of extensibility. The system design will be produces and accepted before developing and the system will be developed unit after unit so that it will be easier for mentors and other interested parties to receive intermediate releases. This system will also be developed in such a way that it will be flexible. The users will get the total ability to configure it according to their desire.

Conclusion

The Open Metadata Search is considered to be a very useful feature all the developers who use the eclipse IDE. This is designed with a high degree of extensibility so that in the long run this can be modified and created new advanced systems. It is guaranteed that this will be an easy to use, flexible system which will deliver a toil free experience for developers.

Appendix - A

OpenMetadaSearchArchitectureOverview.jpg