Любое общение предположений предполагает некоторый протокол из взаимодействия.
Serializable - это один из таких протоколов. У этого протокола есть требование: все сериализиуемые классы должны быть как на отправляющей, так и на принимающей стороне. Поэтому, если вы хотите оставаться в рамках Serializable/Externalizable, то вы обязаны выполнить это требование. Например, вынести все передаваемые кастомные классы в отдельный джарник. Это нормальная практика.
Если это требование по каким-то причнам невыполнимо, то вам надо использовать другой протокол взаимодействия. Например:
1) Обычный TCP с вашим собственным протоколом. То есть вы берете ваш объект, проходитесь по его полям и каким-то образом записываете их в какой-нибудь DataOutputStream. А принимающая сторона делает симметричные действия по чтению в своем DataInputStream'е. Это похоже не Externalizable, но не требует наличия соответствующего класса на принимающей стороне.
2) Можно уйти с TCP на прикладной уровень, и заворачивать все это дело в HTTP.
3) Можно посмотреть в сторону какого-нибудь Hessian.
Минус этих подходов: много ручной работы. Плюс: принимающей стороне не нужны никакие сторонние классы.

4) Остаться при Serializable/Externalizable или другой механимз сериализации (вроде Kryo), и поставить принимающей стороне недостающие классы.
5) Использовать RMI, и поставить принимающей стороне классы-скелетоны.
6) Использовать SOAP, и сгенерировать не принимающей стороне классы-скелетоны.
Плюс этих подходов: мало ручной работы. Минус: принимающей стороне нужны сторонние классы.

МужикRMI умеет загружать классы вместе с данными, классы-скелетоны на клиенте не обязательны (dynamic class loading).Это не решает проблему. Вы можете загружать класс в runtime. Ну а как вы будете работать с объектами этих классов? Через reflection? То еще удовольствие.
Поэтому вам как минимум нужно иметь на принимающей стороне интерфейс, который загружаемый класс имплементирует, что все равно приводит нас к тому факту, что какую-то часть классов необходимо перенести с "отправителя" на "приемник" руками.

МужикАвтор указал только на одну проблему -- ClassNotFoundException. Значит, с самими классами на клиенте он точно не работает. Может он их там в XML или еще куда преобразует или через JavaScript, например, с ними работает.Ну давайте не будем строить догадок, что там делает автор. Ему виднее.

TimRX ,
В том же пакете создали? Внутренности классов совпадают?

TimRXА если в разных пакетах .. то такой механизм не отработает ?Ну а как он может работать? При сериализации объекта в стрим записывается его описание, так как в противном случае вы на принимающей стороне не будете понимать, что вам пришло.
Рекомендую почитать про то, что именно Java пишет ObjectOutputStream, тогда вопросы подобного рода отпадут сами собой.