Jak by należało myśleć o przekazaniu danych pomiędzy Javą (klient) a
.NET (mały serwer). Jakaś forma serializacji, przepakowania na
XML/JSON/whatever

Obecnie są to ręcznie zrobione 2 GET-u we własnej konwencji, na 5
danych, ale szybko rośnie potrzeba robić to lepiej i szybciej.
Połączenie chcę szybko nawiązywalne, i szybko zwalniane więc mało się
podoba długotrwały socket i dlatego http.

uwarunkowanie po stronie .NET
Środowisko bez IIS (mini serwer http realizuje popularny HttpListener ze
'zwykłych' programów WinForms / CommandLine, HttpListener ma pewne
ubóstwo w kodach HTTP i do ideału REST mu daleko)
silna awersja do dodatkowych asseblies, jak najmniej a najlepiej wcale.
Framework od 2.0 do 4.0 i więcej. To powoduje że wbudowany w 4.0 JSON
uznajemy za niedostępny. Ale z kolei jakieś rozwiązania z 2.0-3.5
przestały działać w 4.0.
Klasy C# podlegające 'serializacji' nie są własne i tylko widoczne przez
metadane.
Nie mam WSDL do nich.
obecnie wydaje mi najlepsze się pozyskiwanie danych automagiczne przez
refleksję ale z korektą ręczną(np. nie ujawnianie niektórych danych)
... oraz pytanie: jak po tej stronie się mówi o czymś co w J wiąże się
ze słowem Bean (jego edycja, transmisja, serializacja itd)

Na co zwrócić uwagę?


po stronie Javy. Tu dość dobrze się czuję.
Nie boli jeden-dwa niewielkie JAR-y a wiele z nich i tak już jest.
Klient np. Apache Http Client lub Url.
chętnie przyjęte 'po drucie' dane bym przyjął w obiekty, których klasy
można wygenerować np. półautomatycznie.