a completely decoupled OO system?

Question

To make an OO system as decoupled as possible, I'm thinking of the following approach:

1) we run an RMI/directory like service where objects can register and discover each other. They talk to this service through an interface

2) we run a messaging service to which objects can publish messages, and register subscription callbacks. Again, this happens through interfaces

3) when object A wants to invoke a method on object B, it discovers the target object's unique identity through #1 above, and publishes a message on the message service for object B

4) message services invokes B's callback to give it the message

5) B processes the request and sends the response for A on message service

6) A's callback is called and it gets the response.

I feel this system is as decoupled as practically possible, but it has the following problems:

1) communication is typically asynchronous

2) hence it's non real time

3) the system as a whole is less efficient.

Are there any other practical problems where this design obviously won't be applicable ? What are your thoughts on this design in general ?

Answer 1

Books

Enterprise Integration Patterns

It appears he's talking about using a Message Oriented Middleware

Here are some things to consider

Security

What will prevent another rogue service from registering as a key component in your system. You will need way to validate and verify that services are who they say they are. This can be done through a PKI system. There are scenarios that you might not need to do this, if your system is hosted entirely on your intranet. IF that is the case Social Engineering and Rogue Employees will be your biggest threat.

Contract

What kind of contract will your clients have with the services? Will messages all be serialized as XML and sent as a TextMessage? If you use a pure byte message you'll have to be careful about byte order if your services are to run on multiple platforms.

Synchronization

Most developers are not able to comprehend and utilize asynchronous messages correctly. Where possible it might be in the best interest of your design to create a way to invoke "synchronous" messages. I've done this in the past by creating a sendMessageAndWait() method with a timeout and a return object. Within the method you can create a temporary topic id to receive the response, register a listener for it, then use locks to wait for a message to be returned on your temporary topic.

Unsolicited Messages

What happens if you want to allow your service(s) to send unsolicited messages to your clients? A critical event happened in Service A and it must notify your clients or possibly a Watch Dog service. Allow for your design to register for a common communication channel for services to communicate with clients without clients initiating the conversation.

Failover

What happens if a critical service processing your credit cards goes down? You'll need to implement a Failover and Watch Dog service to ensure that your key infrastructure is always up and running. You could register a list of services within your registry then your register could give out the primary service, falling back to a secondary service if your primary stops communicating. Or if your Message Oriented Middleware can handle Round Robin messaging you might be able to register all the services on the same topic. Think about creating a way to know when a service has died. Since most messages are Asynchronous it will be difficult to determine when a service has gone offline. This can be done with a Heartbeat and Watch Dog.

I've created this type of system a few times in my past for large systems that needed to communicate. If you and other developers understand the pros and cons of such a system it can be very powerful and flexible.

The biggest piece of advice I can give is to build a toolkit for your other developers so they don't have to think about how to register a service, or implement failover, or respond to messages from a client. These are the sorts of things that will kill your system and have others say it is too complicated. Making it painless for them will allow your system to work the way you need it with flexibility and decoupling while not burdening your developers with understanding enterprise design patterns.

This is not a Ivory Tower Architect/Architecture. It would be if he said, "This is how it will do done, now go do it and don't bother me about it because I know I'm right." If you really wanted to reference a Anti-Pattern it could be Kitchen Sink, maybe. Nah now that I think about it, it isn't Kitchen Sink either.

If you can find one please post it as a comment. Anti-Patterns

Answer 2

Coupling is simply a balance between efficiency and re-usability. If you wish the modules of your system to be as reusable as possible then that will undoubtedly come at a cost.

Personally I think it best to define some key assumptions which may tighten coupling, but bring increased efficiency.

There are design patterns which never see the light of day just because the benefit they provide is not worth the cost in complexity.

Answer 3

What's the simplest thing that could possibly work? Do modularize into reasonable size routines, but avoid interfaces, services, messages and all of this unless you are going to have multiple implementations or multiple hardware resources to divide a job.

Make it simple, then refactor those parts that turned out to matter.