What are the best ways to achieve extremely loosely coupling?
If you want to modularize your Software to such an extreme extent that no parts are relying upon any other parts in your system, but they would still be able to communicate, which means would we have to use (technology agnostic) to achieve this goals then
Suggestions please, think of this as a brainstorm ... :)
Use some domain-detached data format to enable communication or exchange information between modules, like XML, RPC, HTTP etc.
Let different teams develop different modules without letting them talk to each other or coordinate their efforts. Set them a goal to design a unified module with a generalistic interface to be later used in various systems in various roles (within the function scope of the module, of course).
Use an Inversion of Control framework so that components don't have to know how to load their dependencies.
I think the only way to do this is a some form of "whiteboard" system, where components write down facts in some commonly accessible area and observe other components writing down their facts. Such architectures are used in distributed AI systems, but I've never heard of real-world distributed systems using them. Your components would obviously need to agree a format for the "whiteboard" messages, and an actual implementation, such as shared memory.
I think what you're mentioning can not be implemented or even if it can, it would be rather hard to implement and it'd have few advantages.
Modularization can be good, but there are limits. Of course, you can design your system so that some parts depend on APIs, but not specific implementations, and I'd encourage that, but "absolutely no dependencies" is an illusion. "communication" would most likely create dependencies.
It is good to try to modularize software, but you're going too far.
Have each system expose it's functionality as a REST or WS-* interface.
However, a more interesting question is when would you want to do this? You need to squeeze as much productivity / performance out off the technology that you have choosen, which means using technology specific solutions.
To be 100% modular is likely hard enough to not be worth the effort. For classes in an application, you can use Dependency Injection and Inversion of Control to loosely couple.
If you're talking about a more distributed system approach you can use SOAP or REST (REST being the most technologically neutral one) so that each module provides a contract, but in that case you're going to need some sort of centralized messaging/routing system that knows where the modules are and their contracts so that they can be called and implements some kind of standard communication for reporting success/failure, unless when your modules communicate you want it to go into a black hole to never be heard from again :)
Just remember the more you generalize, the more difficult it will be to debug, maintain, understand, and if your application requires any sort of performance these methods will be some of the slowest things you can likely do.
Data.
If you want to be loosely-coupled, the answer is data. Your programs or components will not "execute functions" on each other, they will pass data to each other. (Internally, this will probably be done by calling a method - but the mechanics aside, it should be, conceptually, passing data).
If the data, inside your process, is treated as immutable, even better.
This gives clear component boundaries, and protects, to a great extent, from changes blowing up on you (as you can transform one form of data into another relatively easily). It also makes it easy to transfer to multi-process or networked applications, as the semantics of data passing are the same everywhere - there's no assumption of magical hidden state changes without passing some new piece of data.
Well-defined interfaces that pass data, and you're golden. And I do mean data - not 'objects' that know how to do all kinds of magic things. Just simple, pure data.
By the way - that's not saying that objects don't have a place in your program - they're the things that act on your data.
Also, make sure that you keep the parts of your program that deal with the data separate from the parts of the program that are responsible for actually shuttling it around, and the parts that show it to the user. I know, it's that whole 'keep your business logic separate from your persistence and UI layer' stuff again.