It has been long time since I have written blog post regarding REST and SOAP. Anyway this post stems from discussion we had during a session on RESTful Web Services. This post is to put forth my opinion on SOAP vs REST security. Both approaches work, but have their own advantages and disadvantages to interfacing to web services, but it is up to the web developer to make the decision of which approach may be best for each particular case.In nutshell, REST and SOAP have two different approaches on WS security this defines that rest (HTTPS) secures the transmission of the message over the network and provides some assurance to the client about the identity of the server.Their interest in authenticating the client is not in the identity of the computer, but in your identity.

WS-Security offers confidentiality and integrity protection from the creation of the message to its consumption. So instead of ensuring that the content of the communications can only be read by the right server it ensures that it can only be read by the right process on the server. Instead of assuming that all the communications in the securely initiated session are from the authenticated user that each request has to be signed. There you can find nice explanation on this with that popular example necked motorcyclist on MSDN blog ( all know that using SOAP has some additional overhead that is not found in the REST approach, but that overhead also has advantages. First, SOAP relies on XML (Extensible Markup Language) in three ways; the Envelope – that defines what is in the message and how to process it, a set of encoding rules for data types, and finally the layout of the procedure calls and responses gathered. This envelope is sent via a transport (HTTP/HTTPS), and an RPC (Remote Procedure Call) is executed and the envelope is returned with information in a XML formatted document.It is important to note that one of the advantages of SOAP is the use of the “generic” transport. While REST today uses HTTP/HTTPS, SOAP can use almost any transport to send the request, using everything from the SMTP (Simple Mail Transfer Protocol) and even JMS (Java Messaging Service). However, one perceived disadvantage is the use of XML because of its verboseness and the time it takes to parse.When it comes to security, I'm now sort of in to do comparison between REST vs SOAP. Web Services use known protocols, ports, descriptors and methods to access and “expose” back-end or middleware components to the client side. Unfortunately, this means that any Web service is also potentially exposed to underlying vulnerabilities including: 
  • O/S vulnerabilities 
  • Web server (e.g. Apache or IIS) vulnerabilities and attempts at exploit 
  • SQL injections (still, amazingly, a huge problem)
  • Scripting exploits (if applicable)
  • Application server attacks
  • Denial of Service attacks
  • Message monitoring and copying (i.e. for illicit purposes)
  • Message source spoofing (meaning bad guys can pretend to be legit.)
  • Message (payload) manipulation (meaning bad guys can change send data – in transit)
  • Transmission of viruses (in message or as an attachment) 
  • Transactional Attacks
  • Application Program Interface (API) scanning to enable source or recipient address discovery 
  • Code manipulation 
and Lots more. 

This is a big issue. So, what are the differences between SOAP and REST? I have placed some of the known considerations into a table - although this is a brief and cursory examination of the matter.

Most vendors are endorsing or supporting SOAP meaning that security issues will be readily exposed and are likely to be fixed or addressed through countermeasures, patches, etc.
Some SD tool vendors and servers are supporting both REST and SOAP (among other options).

  REST is widely endorsed by developers and has a strong historical foundation; although REST specific security guidance has been limited (there is no “leader” for this, such as the W3C with SOAP).
SOAP messages can be (partially) secured by following/implementing WS-Security (WSS). This allows for integrity and confidentiality controls.
The W3C is also issuing security guidance with respect to SOAP and there is some expectation that WSS will be enhanced both by the W3C and by vendors.
REST, dependent on HTTP, does not support secure messaging directly. HTTPS (SSL or TLS with HTTP) is normally proposed, requiring another port to be opened in the Firewall. Also, this approach can make it difficult to proxy sessions. A number of HTTPS related vulnerabilities are known, across multiple products.
HTTPS is only a point to point solution and (mainly in theory) it can be compromised. Use of longer (e.g. 128 bit or larger) keys limits the likelihood of data interception/decryption.
Both SOAP and REST require many additional security supplements to address all issues (e.g. authentication), beyond simply the protection of message content and integrity.
Perhaps most importantly, most security supplements (including HTTPS) only protect communications and attacks on the server are still a problem.
SOAP formatted XML envelopes and XML in general are prone to manipulation (e.g. “infinite string attacks”). Many XML vulnerabilities and exploits are known.

SOAP, when implementing HTTP transits network firewalls, through port 80 (or 8080) effectively tunnelling through that level of security. This has been touted as a big SOAP benefit for developers who can avoid asking for extra ports to be opened on client/server side firewalls (i.e. for other protocols than HTTP).
However, this is a problem from an infrastructure perspective. The most consistent issue is the difficulty of deciding what to let through and what to block.
Having multiple protocols running over one port makes filtering much harder.
Intrusion Detection/Prevention Solutions (IDS/IPS) are used to examine incoming this traffic in close detail.
But the more complex the traffic, the longer the IDS examination takes (in milliseconds). And, SOAP seems to be quite complex (e.g. multiple headers) and message structure can be contextual.
Decisions would need to be made (in advance) as to a “standard” SOAP header structure, protocols (HTTP is likely to be the only one which systems staff will allow vs. SMTP, for example) etc. to be able to block/pass SOAP messages at the Firewall and at the IDS.
More importantly, when SOAP uses HTTP, there is no built-in way for the Firewall (or an IDS) to know if messages are coming from an authenticated source.
REST is tied to HTTP or HTTPS which means that there is more visibility (e.g. HTTP 1.1) to messages which is an advantage for systems staff who have to configure Firewalls and/or IDS solutions to inspect traffic coming into or leaving the secure perimeter.
This would make it easier to route between multiple Web services.
All of the above are also well understood by IT systems staff, with respect to:
·         Protocol format
·         Port usage
·         Traffic patterns
·         Contextual issues (e.g. when a request seems “normal”) which can be significant if incident intervention is (potentially) needed
An attacker can send a specially crafted SOAP request, which makes use of parameter entities to inflict a denial of service condition on the server. This can drive the server to 100% loading resulting in a DOS condition. This is a known issue with various SOAP compatible servers (patches exist).


Access Control Lists (ACL) can readily be applied to REST traffic (e.g. to restrict POST requests to certain users or IP source addresses). In practice this is considered ineffective.

Local HTTP caching presents security challenges which should be addressable (e.g. through cache clearing) but which will need to be tested.

Logging (for audit trails) is simple with REST as all relevant information is held in the URI.
Potential SOAP exploits are less well understood as usage is still somewhat limited (although growing fast). Solutions are potentially complex. However, the WS-Security standard is an effort to provide a fairly open (hence upgradeable) standard to augment SOAP (e.g. for authentication of senders, protection of message integrity, etc.).
REST operations (e.g. GET, PUT) and associated exploits are quite well understood and documented (e.g. flooding of HTTP GET requests, HTTP GET request with long parameter names triggering overflows, etc.) – as are solutions.

Per item 9, if  GETs are accepted from anyone, some or all POSTs can be blocked. If some POSTs are to be allowed (e.g. by a group of trusted users), Access Control Lists (ACL) can be applied.
There are various ways to do this. However, ACLs require manual maintenance (e.g. IP address changes or user profile changes).
This would also require the creation (and enforcement) of strong developer guidelines to prevent un-managed use of GETs.
SOAP is prone to “array overflow” attacks (similar to a buffer overflow) where a CML request with an overlarge array length is specified to a service provider (resulting in a work space for illicit code execution).

SOAP headers contain information which can be altered in transit (man in the middle) to cause harm (e.g. to point to an invalid file reference).

Security scanners (like an IPS or a Web App Firewall) are needed for comprehensive SOAP/XML message analysis. However, these can be placed in-line with XML accelerators.
"Common" IDS/IPS systems tend to be sufficient for scanning of REST (HTTP) traffic. An XML security scanner may not have any effect on REST traffic (i.e. unless XML is embedded in messages, which is not common for invocation).
SOAP messages include specification of the data type for each of their arguments (e.g. string vs. array-of-string). This makes some types of attack (e.g. SQL injection) more difficult to initiate.

So WS-Security offers more protection than HTTPS would, and SOAP offers a richer API than REST. My opinion is that unless you really need the additional features or protection you should skip the overhead of SOAP and WS-Security. I know it's a bit of a cop-out but the decisions about how much protection is actually justified need to be made by those who know the problem intimately. But the untold story is that both technologies can be mixed and matched.  REST is very easy to understand and is extremely approachable, but does lack standards and is considered an architectural approach. In comparison, SOAP is an industry standard with a well-defined protocol and a set of well-established rules to be implemented, and it has been used in systems both big and small.

Hii guys. from starting today i going to working on presenting new web services post series. since this web services has been taking large part of the developer society it comes with lot of questions and many more complex scenarios. so if any one got any thing to ask just comment below so we can discuss them.

What is Web Service

The term Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall.
Unlike traditional client/server models, such as a Web server/Web page system, Web services do not provide the user with a GUI. Web services instead share business logic, data and processes through a programmatic interface across a network. The applications interface, not the users. Developers can then add the Web service to a GUI (such as a Web page or an executable program) to offer specific functionality to users.
Web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, Web services are not tied to any one operating system or programming language. For example, Java can talk with Perl, Windows applications can talk with UNIX applications.

Types of Web Services

On the conceptual level, a service is a software component provided through a network-accessible endpoint. The service consumer and provider use messages to exchange invocation request and response information in the form of self-containing documents that make very few assumptions about the technological capabilities of the receiver.

On a technical level, web services can be implemented in various ways. The two types of web services discussed in this section can be distinguished as “big” web services and “RESTful” web services.

SOAP Web Services

Big web services use XML messages that follow the Simple Object Access Protocol (SOAP) standard, an XML language defining a message architecture and message formats. Such systems often contain a machine-readable description of the operations offered by the service, written in the Web Services Description Language (WSDL), an XML language for defining interfaces syntactically.

The SOAP message format and the WSDL interface definition language have gained widespread adoption. Many development tools, such as NetBeans IDE, can reduce the complexity of developing web service applications.

A SOAP-based design must include the following elements.

A formal contract must be established to describe the interface that the web service offers. WSDL can be used to describe the details of the contract, which may include messages, operations, bindings, and the location of the web service. You may also process SOAP messages in a JAX-WS service without publishing a WSDL.

The architecture must address complex nonfunctional requirements. Many web service specifications address such requirements and establish a common vocabulary for them. Examples include transactions, security, addressing, trust, coordination, and so on.

The architecture needs to handle asynchronous processing and invocation. In such cases, the infrastructure provided by standards, such as Web Services Reliable Messaging (WSRM), and APIs, such as JAX-WS, with their client-side asynchronous invocation support, can be leveraged out of the box.

RESTful Web Services

REST is well suited for basic, ad hoc integration scenarios. RESTful web services, often better integrated with HTTP than SOAP-based services are, do not require XML messages or WSDL service–API definitions.

Project Jersey is the production-ready reference implementation for the JAX-RS specification. Jersey implements support for the annotations defined in the JAX-RS specification, making it easy for developers to build RESTful web services with Java and the Java Virtual Machine (JVM).

Because RESTful web services use existing well-known W3C and Internet Engineering Task Force (IETF) standards (HTTP, XML, URI, MIME) and have a lightweight infrastructure that allows services to be built with minimal tooling, developing RESTful web services is inexpensive and thus has a very low barrier for adoption. You can use a development tool such as NetBeans IDE to further reduce the complexity of developing RESTful web services.

A RESTful design may be appropriate when the following conditions are met.

The web services are completely stateless. A good test is to consider whether the interaction can survive a restart of the server.

A caching infrastructure can be leveraged for performance. If the data that the web service returns is not dynamically generated and can be cached, the caching infrastructure that web servers and other intermediaries inherently provide can be leveraged to improve performance. However, the developer must take care because such caches are limited to the HTTP GET method for most servers.

The service producer and service consumer have a mutual understanding of the context and content being passed along. Because there is no formal way to describe the web services interface, both parties must agree out of band on the schemas that describe the data being exchanged and on ways to process it meaningfully. In the real world, most commercial applications that expose services as RESTful implementations also distribute so-called value-added toolkits that describe the interfaces to developers in popular programming languages.

Bandwidth is particularly important and needs to be limited. REST is particularly useful for limited-profile devices, such as PDAs and mobile phones, for which the overhead of headers and additional layers of SOAP elements on the XML payload must be restricted.

Web service delivery or aggregation into existing web sites can be enabled easily with a RESTful style. Developers can use such technologies as JAX-RS and Asynchronous JavaScript with XML (AJAX) and such toolkits as Direct Web Remoting (DWR) to consume the services in their web applications. Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly refactoring the existing web site architecture. Existing developers will be more productive because they are adding to something they are already familiar with rather than having to start from scratch with new technology.

Abstract – 

There are main two tasks will be consist with this project the objective of both two tasks will be, provide resources to the people who are interested towards the ecf to get to understand the remote services and make it easy to work with ecf on aspect of creating OSGi Remote as the first task there is my gsoc 2014 project which is provided 4 PDE templates for osgi remote services. So this PDE templates need to be prepared for inclusion in ECF proper. by adding them to ecf it make it easy for any new ecf user to understand how remote services work and what are things that need completed in oder to create OSGI remote service. Next would be creating eclipse wizard for creating OSGI services. The idea here would be for Eclipse users to use wizards to create OSGi services (and remote services) like they create projects, classes, packages. This may lead to start of creating eclipse based eclipse nature for Remote services.

Detailed Information – 

First task is to prepare that already developed PDE templates to include with ecf proper to get benefit to the users. Under bug ( there are few errors that need to be fixed before the inclusion so that errors will be corrected throughout the first time period of this mainly befor the inlution this primary subtask will be done

1. Remove the errors that contain in the projects
2. Remove the errors in templates
3. Make them available on other projects not only pure OSGI projects 

Except for the fixing errors that showed in the bug, it will be added new template. This template would be related to the tutorial in the wiki ( . This tutorial shows how to use OSGi Services to access the Raspberry Pi GPIO. Adding this template into eclipse ecf as PDE template that may allow user to get to know about that how simple implementation of remote service can be done and by using raspberry pi. For adding templates mainly eclipse PDE will be used. 

Second task would be creating complete new wizard for creating osgi remote service wizard

When user create OSGI remote service 

Create a interface and include all the methods
Create an implementation for above interface
Register the service

Would be a basic three steps. Those first two steps can all be done via any existing tooling and/or frameworks...e.g. Eclipse, bndtools, declarative services, blueprint. Also in the PDE there is PDE project examples that shows two new PDE example templates but this depends upon PDE templates, so it's only usable with PDE. so there is no any other simple way to create complete generic OSGI remote service projects. 
This task focus on creating brand new wizard for simplifying the creation and registration of OSGi Remote Services with specific distribution providers and specifications. And the related documentation to the project.
This project will develop a new project category call “ECF OSGI Remote Service” in to eclipse following new project wizard.

Users will be able to select the category and able to create new OSGI remote service project using Wizard like shown below this wizard will allow user to specify the project name, working directory and execution environment settings.

Once we collect those information it will direct to next page that asks user about basic infrastructure of the remote service project.
In that wizard page it will gather information about service interfaces and their implementation classes and their packaging information. for this phase I think Eclipse JFace TableViewer in JFace framework would be suitable. Once user complete this wizard page those information will be added to MANIFEST.MF file in OSGI bundle.
After that wizard it will direct to another wizard page which ask about the dependencies of the OSGI project. in this phase it will add those dependencies to the MENFEST.MF of the OSGI project. Page may look like page shown below.

Once user have completed the page it will invoke another page.In that wizard page it will ask information about service registration 
In this phase it user can specify about their distribution provider and which of the interfaces of the service need to be exported all of the above information may gather into final service activator class which will register the service  as a remote service.The ability to create a OSGI remote service project via simplified automated way it will really appealing. particularly for the novice OSGI developers. Since additional Eclipse-based tooling were made available, it would be helpful to provide more tutorial-style documentation that uses that improved tooling .therefor creating Tooling support for OSGI Remote Services will be a benefit to developers.

Background – 

Last year also I have participated wit google summer of code with eclipse foundation and completed it success fully. so this year In the time leading up to the start of the GSoC program I am going to improve my knowledge about Eclipse Communication Framework . And my major goal is to get familiar with the OSGi Remote Services and Eclipse based Tooling .And thoroughly study the source code for existing Tooling supports for various eclipse projects. To improve my knowledge on above aspects I expect to read the documents regarding them and to have a discussion with the project mentors.

Deliverables –

 What do you expect to deliver? Be as specific as possible.

Schedule – 

  • March 31 - April 2
Preview the previous work and get familiar with it discuss about things that need to be change in pre created templates
  • April 3 – April 13
Fix the errors and complete them for deployment
  • April 14- April 28
Discuss about new templates and how it should be on the PDE template in public mailing list with all committers in the project 
  • April 29 – May 10
Prepare template for the raspberry pi tutorial and add them to project
  • May 10 – May 12
Test all the code in that project and send it to mentor for verify before inclusion
  • May 13- May 16
Include that project with ecf proper
  • May 17 - June 15
Study about eclipse JDT and EMF and its functionality towards a designed new wizards and views for the project
Discuss and design UI and its requirements for proposed wizard
Start coding
Start working  on GUI
  • June 16 - June 26
Midterm Evaluation
  • June 28 - July 24
Add required new classes and update existing classes which requires to add OSGi Remote service.
Further develop the GUI and integrate it with the code
Integrate all implemented parts eclipse single project.
  • July 25 - August 6
Test if added new functionality is working properly.
Do the required changes to fix the bugs.
  • August  7 - August 14
  • August  14 - August 28
Finish project and Submit Deliverable

Expectations –

 What do you expect from your mentor? What help are you going to need? (e.g. will you need help learning about Eclipse plug-in development, or about any specific features of Eclipse that you'll need to leverage as part of your project?).

Contact Information –

Email :
Phone number : +94776070991
Time-Zone : GMT+5:30
I’m Sakith Indula. I am a fourth  year  undergraduate in Department of Computing and information System in Sabaragamuwa University Of Srilanka .last year also I have participated with Google summer of code with eclipse ECF and I worked on creating PDE templates for OSGI remote services and successfully completed it on last august. I have much experience in java and developing various applications, basically I am doing programming with Java therefor I have a advance knowledge with programming in Java also I have experience with programming in  C,C++ and XML.I have implemented many projects in java including a one which spanned for four months .Also I was a project team member of the following  projects.

Track M : Bus Tracking System For National Trans Port Board [1]
Scloud : cloud base file sharing platform for any kind of mobile through Apache Stratos.

I am able to work 50 hours a week  for GSoC from April to August ( 6 hours on weekdays and 10 hours on weekends).So I’m confident enough to take up this project as I have the required skill set for this project and I will deliver my best to make this project a success. ‘And I would like continue forward the work for ECF even after GSoC finishes and to complete the work all the way to deployment.


Asynchronous communication and activities take place outside of real time. For example, a learner sends you an e-mail message. You later read and respond to the message. There is a time lag between the time the learner sent the message and you replied, even if the lag time is short. Bulletin board messages can be added at any time and read at your and the learners’ leisure; you do not read someone else’s message as it is being created, and you can take as much time as you need to respond to the post. Asynchronous activities take place whenever learners have the time to complete them. For example, viewing videos linked to the course site, reading a textbook, and writing a paper are all asynchronous activities .
There are some key advantages to asynchronous collaboration tools. For one thing, they enable flexibility. Participants can receive the information when it's most convenient for them. There's less pressure to act on the information or immediately respond in some way. People have time to digest the information and put it in the proper context and perspective. Another advantage is that some forms of asynchronous collaboration, such as email, are ubiquitous. These days, it's hard to find a co-worker, customer, business partner, consultant, or other party who doesn't have an email account.
The drawbacks of asynchronous collaboration are that they can lack a sense of immediacy and drama. There's less immediate interaction. Sometimes people have to wait hours, days, and even weeks to get a response to a message or feedback on a shared document. The lack of immediacy means that information can be out of date by the time someone views it. This is especially true in light of the rapid pace of change in today's business environment .
In contrast, synchronous, or real-time, communication takes place like a conversation. If your class uses only writing-based tools to communicate, the only synchronous communication possible is a chat session. Everyone gets online in the same chat room and types questions, comments, and responses in real time. Synchronous activities may include chat sessions, whiteboard drawings, and other group interactive work. If your class involves multimedia tools, synchronous communication might involve audio or video feeds to the computer. Some “online” courses require learners and teachers to get together at least once (or sometimes several times) in person, by conference call, or through closed-circuit television links.
One of the advantages of synchronous collaboration is its immediacy. You can send and receive information right away. This more closely resembles a face-to-face or telephone conversation between two or more people, so can present a more natural way of communicating. The sense of immediacy is more like to solicit a timely response from people. Synchronous collaboration, in general, is more interactive than asynchronous.
The downside of synchronous collaboration is that not everyone uses it. Although instant messaging, chat, and other such tools are becoming more common, they're still not as ubiquitous as technology such as email. Another drawback is that synchronous collaboration is not as flexible as asynchronous. All the parties involved must be ready and willing to collaborate at a given moment-or the session doesn't work as well. Also, not everyone does well with this kind of collaboration, particularly people who like to think over what they want to communicate.
When should you use asynchronous and synchronous collaboration? Much of the decision-making on this involves common sense. Asynchronous collaboration, such as email and document sharing, can certainly be used for day-to-day communications when an urgent response isn't needed. This sort of communication is suitable for sending out broadcast messages that don't necessarily need to be acted on right away, or for corresponding with clients, customers. and business partners without putting pressure on them to respond immediately.
On the other hand, you wouldn't want to use asynchronous collaboration if you need immediate interaction with people or if you seek to collaborate with a large group at the same time. Email wouldn't work, for example, as the sole means of conducting a staff meeting.
Synchronous collaboration is ideal when the collaboration needs to be immediate and spontaneous, like a conversation between two or more people. Using real-time chat, instant messaging, electronic whiteboarding, and other such tools is appropriate for virtual meetings, where parties in remote locations are expected to participate and ask questions. In many cases, these types of collaborations might serve as supplements to telephone conference calls.
Synchronous collaboration wouldn't be suitable for situations that call for less immediate response or where parties aren't able to respond right away. For example, it might not work as a way to collaborate with customers on new product design or development.
For many organizations, asynchronous and synchronous collaboration will each prove valuable in their own way.
Java annotations are used to provide meta data for your Java code. Being meta data, the annotations do not directly affect the execution of your code, although some types of annotations can actually be used for that purpose.
Java annotations were added to Java from Java 5. This text covers Java annotations as they look in Java 6. As far as I know, Java annotations have not changed in Java 7, so this text should be valid for Java 8 programmers too.

1.Why Annotations

Java annotations are typically used for the following purposes:
  • Compiler instructions
  • Build-time instructions
  • Runtime instructions
Java has 3 built-in annotations that you can use to give instructions to the Java compiler. These annotations are explained in more detail later in this text.
Java annotations can be be used at build-time, when you build your software project. The build process includes generating source code, compiling the source, generating XML files (e.g. deployment descriptors), packaging the compiled code and files into a JAR file etc. Building the software is typically done by an automatic build tool like Apache Ant or Apache Maven. Build tools may scan your Java code for specific annotations and generate source code or other files based on these annotations.
Normally, Java annotations are not present in your Java code after compilation. It is possible, however, to define your own annotations that are available at runtime. These annotations can then be accessed via Java Reflection, and used to give instructions to your program, or some third party API.

2.How It Works

2.1 simple annotaion


The @ character signals to the compiler that this is an annotation. The name following the @ character is the name of the annotation. In the example above the annotation name is Override.

2.2 Elements Of annotation

Annotations can have elements for which you can set values. An element is like an attribute or parameter. Here is an example of an annotation with an element:

@Entity(tableName = "vehicles")

The annotation in this example contains a single element named tableName, with the value set to vehicles. Elements are enclosed inside the parentheses after the annotation name. Annotations without elements do not need the parentheses.
An annotation can contain multiple elements. Here is an example:

@Entity(tableName = "vehicles", primaryKey = "id")

When an annotation just contains a single element named value, you can leave out the element name, and just provide the value. Here is an example:


2.3 Annotation Placement

You can put Java annotations above classes, interfaces, methods, method parameters, fields and local variables.

2.4 java built in annotations

Java comes with three annotations which are used to give the Java compiler instructions. These annotations are:
  • @Deprecated
  • @Override
  • @SuppressWarnings

3 Creating Your Own Annotations

It is possible to create your own annotations. Annotations are defined in their own file, just like a Java class or interface. Here is an example:

@interface MyAnnotation {

    String   value();

    String   name();
    int      age();
    String[] newNames();


This example defines an annotation called MyAnnotation which has four elements.
Notice that each element is defined similarly to a method definition in an interface. It has a data type and a name. You can use all primitive data types as element data types. You can also use arrays as data type. You cannot use complex objects as data type.
To use the above annotation, you do like this:

    newNames={"Jenkov", "Peterson"}
public class MyClass {


As you can see, I have to specify values for all elements of the MyAnnotation annotation.
Element Default Values
You can specify default values for an element. That way the element becomes optional and can be left out. Here is an example of how the annotation definition looks with a default value for an element:

@interface MyAnnotation {

    String   value() default "";

    String   name();
    int      age();
    String[] newNames();


The value element can now be left out when using the annotation. If you leave it out, it will be considered as if you had used the default value for the value element. Here is an example:

    newNames={"Jenkov", "Peterson"}
public class MyClass {


Notice that the value element is no longer present.


You can specify for your custom annotation if it should be available at runtime, for inspection via reflection. You do so by annotating your annotation definition with the @Retention annotation. Here is how that is done:
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;


@interface MyAnnotation {

    String   value() default "";


Notice the annotation added above the MyAnnotation definition:
This is what signals to the compiler and JVM that the annotation should be available via reflection at runtime. Accessing annotation at runtime is covered in my Java Reflection and Annotations tutorial, which is part of my Java Reflection Tutorial.
The RetentionPolicy class contains two more values you can use:
RetentionPolicy.CLASS means that the annotation is stored in the .class file, but not available at runtime. This is the default retention policy, if you do not specify any retention policy at all.
RetentionPolicy.SOURCE means that the annotation is only available in the source code, and not in the .class files and not a runtime. If you create your own annotations for use with build tools that scan the code, you can use this retention policy. That way the .class files are not poluted unnecessarily.


You can specify which Java elements your custom annotation can be used to annotate. You do so by annotating your annotation definition with the @Target annotation. Here is an example:

import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

public @interface MyAnnotation {

    String   value();

This example shows an annotation that can only be used to annotate methods.
The ElementType class contains the following possible targets:

  • ElementType.CONSTRUCTOR
  • ElementType.FIELD
  • ElementType.LOCAL_VARIABLE
  • ElementType.METHOD
  • ElementType.PACKAGE
  • ElementType.PARAMETER
  • ElementType.TYPE

Most of these are self explaining, but a few are not. Therefore is here an explanation of the few that are not obvious.
The ANNOTATION_TYPE target means annotation definitions. Thus, the annotation can only be used to annotate other annotations. Like the @Target and @Retention annotations.
The TYPE target means any type. A type is either a class, interface, enum or annotation.


The @Inherited annotation signals that a custom annotation used in a class should be inherited by subclasses inheriting from that class. Here is an example:


public @interface MyAnnotation {


public class MySuperClass { ... }

public class MySubClass extends MySuperClass { ... }

In this example the class MySubClass inherits the annotation @MyAnnotation because MySubClass inherits from MySuperClass, and MySuperClass has a @MyAnnotation annotation.


The @Documented annotation is used to signal to the JavaDoc tool that your custom annotation should be visible in the JavaDoc for classes using your custom annotation. Here is an example:

public @interface MyAnnotation {

public class MySuperClass { ... }

When generating JavaDoc for the MySuperClass class, the @MyAnnotation is now included in the JavaDoc.
You will not use the @Documented annotation often, but now you know it exists, if you should need it.

Eclipse Extension Points

Eclipse is one of the most popular and widely used developing platform. and the huge success of it lies in its extensibility. It is extensible through the means of extension points (well defined exposed places/hooks for others to provide extended functionality) and plugins ( providing extended functionality using existing extension points and optionally exposing new extension points). Eclipse itself is made up of many and many of plugins built around the small core runtime engine capable of dynamic discovery, loading, and running of plug-ins.

in this post i’m going to share few difficulty I faced when I started plugin development. After reading some introduction tutorials I wanted to know quickly which extension points I need to use for some particular tasks. Once we know the name of extension point we can find the details in official eclipse documentation (Extension Points Reference) or even better within platform itself (Plugin Development Environment) when trying to add an extension point it gives the description and sample implementation (if available) to understand.

Figure 1

in this post i will give you brief introduction regarding what are the extension points that you can use for your developments in eclipse. if you need more clearer idea about eclipse extensionpoits you can refer them through this link

figure 2

  1. base eclipse platform
  2. core run time engine provides extension point and plugin model
  3. for creating and managing resources
  4. define team programming model
  5. providing user interface for navigating the platform
  6. tools to create high level ui
  7. tools for creating low level ui
  8. providing help and other documents
  9. defines language independent debugging model
The various subsystems (on top of Platform Runtime) as described above define many extension points to provide the additional related functionality.

Below are the various components of the workbench UI.

figure 3
Now below describes the common functionality you want to extend/customize and which extensions points.

Add Views:

define additional views  for the workbench: org.eclipse.ui.views

Add Editors:

add new editors to the  workbench: org.eclipse.ui.editors

Add menus/buttons:

declare an abstract semantic behavior of an action (command) with optional default handler: org.eclipse.ui.commands

add menus, menu items and toolbar buttons in UI: org.eclipse.ui.menus

add specific handlers to a command: org.eclipse.ui.handlers

declare key bindings (or set of them called as schemes) to commands: org.eclipse.ui.bindings

Configure the launching of Applications:

define/configure a type for launching applications : org.eclipse.debug.core.launchConfigurationTypes

associate an image with a launch configuration type: org.eclipse.debug.ui.launchConfigurationTypeImages

define group of tabs for a launch configuration dialog: org.eclipse.debug.ui.launchConfigurationTabGroups

define shortcut for launching application based on current selection/ perspective: org.eclipse.debug.ui.launchShortcuts

Add resource markers:

add marker (additional information to tag to Resources like Projects, Files, Folders): org.eclipse.core.resources.markers

Add Preferences:

add pages to the preference dialog box: org.eclipse.ui.preferencePages

Add wizards:

add wizard to create a new resource: org.eclipse.ui.newWizards

add wizard to import a resource: org.eclipse.ui.importWizards

add wizard to export a resource: org.eclipse.ui.exportWizards

Contribute Help:

add help for an individual plugin: