I believe SOA is still maturing and there are many organization implementing SOA bottom up rather than top-down or meet in middle. Lack of proper governance is another reason why many SOA implementations are not truly realized. There is also a misconception that SOA is all about WebServices (impl. in Java/.net).

As more and more organization adopt SOA, there is a risk of Rogue Webservices. I would like to know your experiences in dealing with such Rogue services and what measure can the organizations take.

I have to agree that the lack of proper governance is a big problem in an SOA.  I have been pushing for the purchase of WSRR for several years now in my current organization because of the rouge nature of our services.  Basically its every service for itself.  I see textbook examples of why we need SOA governance regularily.  However, even if we could get the funding for WSRR, I believe greater funding is needed for proper ongoing governance. 

In my organization our application teams operate in their own silos, and are resistant to any form of central governance.  This means leadership must break the mold and enforce application teams to comply with a centralized governance for SOA to be successful.  We could have all the tools like WSRR in place, but without executive support and application compliance, we would not be successful.

For example, an application team hosts a service, they upgrade their service, move it onto a different server, do not use a DNS name for the service endpoint, do not supply a WSDL to consumers, and they take the old service down.  The application team is aware that others use the service, and they are sure to update the endpoints for their own application usage, but dont tell any other consumers of the application.  When support calls come in, they dont even realize this is their problem and refer the issues to the service consumers who cant connect to their service.

Now, put all of the tools in place such as WSRR, ESB (or WMB in my case), governance policies, and a governance team.  What if the application team doesnt do endpoint lookups in the registry, and instead hardcodes its endpoints wherever used?  They are able to skip over the governance.  They dont need the new version of the service and endpoint approved in WSRR, they have implemented the new version of the service (for their own purposes anyways), sidestepping all governance.  Without enforcement that they resolve their enpoint through a registry lookup, and thus needing to go through SOA governance and approval to make the new version of the service discoverable, the SOA is undermined.

Another issue is SOA knowledge and training.  SOA is a contemporary IT buzzword, much like "cloud" that alot of people like to throw around to make it sound like they are on the up-and-up, but they really dont know what it means.  Like you say, some think it is limited to WebServices. Some think it applies only to applications and not EAI, and vice versa.  Some think a WebService by itself is SOA.  I am seeing more and more universities encorporating SOA in their cirriculum after a good dose of Object Orientated design, but organizations need to be sure they are providing training to those who havent had any SOA exposure, or even any formal IT training.  You cant get by with what you read in Information Week or some other publication/advertisement.

I agree with Andrew.

I just wanted to add a few comments.
Depending on the size of your company WSRR might not be an option.
If service points are defined and a centralized view is kept a registry might not even be used.

What is essential however to success is that you have a small team dedicated to centralise all the needed information and evaluate each change / new service that is being put into place.

Any change not submitted to this team is considered as rogue and can be reversed at any time, until the formal process is followed and the change is then controlled.

This formal change process should then also take care of documentation and ability to label the changes correctly in your different systems (source control, deployment control, etc...).