Czy usługa .NET Remoting jest rzeczywiście przestarzała?

95

Wszyscy mówią, w jaki sposób .NET Remoting jest zastępowany przez WCF, ale zastanawiam się, jak dokładne jest to. Nie widziałem żadnego oficjalnego słowa, że Remoting jest przestarzały i wydaje mi się, że z pewnością istnieją scenariusze, w których Remoting ma więcej sensu niż WCF. Żaden z obiektów ani metod związanych z obsługą zdalną nie został uznany za przestarzały, nawet w wersji 4.0 platformy. Rozumiem również, że System.AddIn we frameworkach 3.5 i 4.0 używa Remotingu.

Czy ktoś ma jakieś oficjalne słowo, że jest inaczej?

W artykule Wybieranie opcji komunikacji w .NET (dla wersji 3.0, ponieważ jest to najnowsza wersja tego artykułu), stwierdza:

8 Komunikacja domeny między aplikacjami

Jeśli potrzebujesz obsługiwać komunikację między obiektami w różnych domenach aplikacji w ramach tego samego procesu, musisz korzystać z usług zdalnych .NET.

To oczywiście nie jest dokładne, ponieważ WCF z pewnością można wykorzystać do przekraczania granic domeny aplikacji, ale czy daje oficjalną rekomendację dla tego scenariusza?

Aktualizacja: Wysłałem Clemensowi Vastersowi (który był w zespole, który jest właścicielem Remotingu i WCF) to pytanie:

Clemens, rozumiem, że należysz do zespołu, który jest właścicielem zarówno usług zdalnych, jak i WCF, i mam kilka pytań, które moim zdaniem powinny znaleźć się w źródle.

Po pierwsze, mam pytanie, czy zdalny dostęp odchodzi. Konkretnie, mamy dość dużą aplikację, która intensywnie wykorzystuje usługi zdalne do komunikacji między domenami w trakcie procesu, i zastanawiałem się, czy to użycie zdalnej komunikacji jest uważane za „starsze”. Jeśli tak, czy AppDomain.CreateInstance i przyjaciele zostaną zastąpieni czymś innym?

Oto jego odpowiedź:

Usługi zdalne są częścią .Net Framework i jako takie nie znikają. COM był w systemie Windows od czasu Windows NT 3.5 / Windows 95 i nie zniknął i nie sądzę, żeby w najbliższym czasie zniknął.

To powiedziawszy, inwestycje w Remoting są bardzo minimalne. WCF jest następcą komunikacji zdalnej i zastępuje model COM / DCOM dla kodu zarządzanego.

W przypadku komunikacji między aplikacjami w procesie Komunikacja zdalna to natywny sposób komunikacji środowiska CLR. Jeśli widzisz problemy z wydajnością pompowania większych ilości danych lub bardzo wielu komunikatów w krótkim czasie, powinieneś poważnie przyjrzeć się WCF i NetNamedPipeBinding.

.net wcf remoting

— znak
źródło

1

Zobacz stackoverflow.com/questions/1295353/…, aby dowiedzieć się, dlaczego WCF jest o wiele wolniejsze niż obsługa zdalna w mojej konkretnej sytuacji.

— Mark

1

Usługi zdalne są nieodłącznym elementem .NET, a szczegółowe informacje na temat roli, jaką odgrywa i jak działa, można znaleźć w Essential .NET autorstwa Don Boxa i Chrisa Sellsa. Jednak rozpada się, gdy komunikacja między komponentami jest zawodna lub powolna, a praktycznie wszystkie transporty - nawet gigabitowa sieć LAN - są zawodne i wolne w porównaniu z przesyłaniem komunikatów w procesie. Kiedy ludzie mówią o powolnym działaniu WCF, zwykle myślą o usługach internetowych. Usługi internetowe działają zbyt wolno, jeśli spróbujesz ich użyć do komunikacji w procesie. Są jednak zaprojektowane tak, aby tolerować powolne i zawodne połączenia i dobrze służyć w takich warunkach.

— Peter wygrał

3

@Peter: dziękuję za informację, ale kilka Twoich założeń jest całkowicie błędnych. Po pierwsze, komunikacja zdalna jest powolna lub zawodna. To nie jest. Jest bardzo szybki i niezawodny (oczywiście na niezawodnych kanałach). Innym jest to, że „usługi sieciowe” (cokolwiek to znaczy) działają wolno. Oni nie są. Oczywiście wszystko w toku będzie znacznie szybsze niż cokolwiek w sieci, ale wcale nie o to chodzi w tym pytaniu ...

— Mark

54

Nazwanie tego starszą technologią jest dokładniejszym opisem.

http://msdn.microsoft.com/en-us/library/72x4h507%28VS.85%29.aspx

Ten temat dotyczy starszej technologii, która jest zachowywana w celu zapewnienia zgodności z istniejącymi aplikacjami i nie jest zalecana do nowego rozwoju. Aplikacje rozproszone powinny teraz być opracowywane przy użyciu Windows Communication Foundation (WCF).

Aktualizacja: WCF nie rozróżnia między / intra / process / inter / intra-appdomain. Jeśli używasz komunikacji z pojedynczym komputerem w programie WCF, używasz nazwanych potoków - użycie go powinno zapewnić dobrą wydajność w praktycznie wszystkich realistycznych scenariuszach.

Porównanie wydajności różnych technologii komunikacji rozproszonej znajduje się tutaj .

— RichardOD
źródło

Czy ten artykuł nie odnosi się konkretnie do korzystania z usług zdalnych w komunikacji międzyprocesowej? Wydaje mi się, że w komunikacji międzyaplikacyjnej (AppDomain.CreateInstanceFromAndUnwrap i przyjaciele) nadal ma miejsce zdalne zarządzanie.

— Mark

Tak to jest. Gdyby te klasy zostały „przestarzałe”, zastosowałyby do nich ObsoleteAttribute- msdn.microsoft.com/en-us/library/system.obsoleteattribute.aspx .

— RichardOD

2

@Mark, @RichardOD: Ten artykuł jest głównym artykułem na temat .NET Remoting. Nie dotyczy tylko komunikacji między procesami. Również fakt, że ObsoleteAttribute nie znajduje się na nich w .NET 3.5, nic nie znaczy, ponieważ decyzja o ogłoszeniu usług zdalnych (i usług internetowych ASMX) jako „starszych” została podjęta po .NET 3.5 RTM.

— John Saunders

@John: W 4.0 też nie są oznaczone jako [Przestarzałe] (przynajmniej jeszcze nie).

— Mark

@Mark: masz na myśli 4.0 beta 1.

— John Saunders

11

Tak. Usługi zdalne są przestarzałe ... i są oficjalne od firmy Microsoft. Oto link:

.NET Remoting

Pierwsza linia artykułu jest pogrubiona:

Ten temat dotyczy starszej technologii, która jest zachowywana w celu zapewnienia zgodności z istniejącymi aplikacjami i nie jest zalecana do nowego rozwoju. Aplikacje rozproszone powinny teraz być opracowywane przy użyciu Windows Communication Foundation (WCF).

Myślałem, że to słowo jest „przestarzałe”, ale najwyraźniej nazywają je „dziedzictwem”

— Justin Niessner
źródło

21

IMO „przestarzałe” jest silniejsze niż „starsze”: „starsze” oznacza „nie uruchamiaj”, a przestarzałe oznacza „jeśli już zacząłeś, przestań teraz, ponieważ może zostać całkowicie usunięty w przyszłych wersjach”.

— ChrisW,

1

@Mark: Nie czytam tego w ten sposób. Wydaje się, że program WCF ma zastosowanie do komunikacji między procesami, tak jak w przypadku komunikacji zdalnej (zobacz NetNamedPipeBinding w programie WCF).

— Michael Petrotta

1

@Mark: Niezależnie od tego, Remoting jest przestarzały. @ChrisW: Wątpię, czy Remoting zostanie usunięty w najbliższym czasie, ale możesz spodziewać się mniejszej liczby poprawek błędów, jeśli w ogóle, i mniejszego wsparcia, jeśli w ogóle.

— John Saunders

1

@Mark - jakie jest Twoje prawdziwe pytanie? Obsługa zdalna jest uważana za starszą technologię. Wygląda na to, że nie chcesz, aby to było prawdą. Możesz mieć dobre powody, ale to nie odpowiada aktualnym zaleceniom Microsoftu.

— Michael Petrotta

1

@John: Chyba tak. W szczególności wykonuję komunikację między domenami w procesie (przy użyciu AppDomain.CreateInstanceFromAndUnwrap i przyjaciół) i nie widzę sposobu, aby to zrobić tak czysto (lub tak wydajnie) przy użyciu WCF. Z przyjemnością zamiast tego używam WCF (używam go często w innych scenariuszach), ale w tym przypadku mam problemy z uruchomieniem go tak, jak chcę. Opublikuję kolejne pytanie dotyczące tego konkretnego scenariusza.

— Mark

6

Jeśli lubisz migrować do .NET Core, i tak musisz znaleźć inne rozwiązanie dla Remotingu:

.NET Remoting został zidentyfikowany jako problematyczna architektura. Służy do komunikacji między AppDomain, która nie jest już obsługiwana. Ponadto usługi zdalne wymagają wsparcia w czasie wykonywania, które jest kosztowne w utrzymaniu. Z tych powodów usługa .NET Remoting nie jest obsługiwana na platformie .NET Core i nie planujemy dodawania jej obsługi w przyszłości.

Źródło: https://docs.microsoft.com/en-us/dotnet/core/porting/libraries#remoting

— Jean-Claude
źródło

1

Tutaj możesz znaleźć dyskusję o tym, jakie alternatywy są dostępne w .NET Core: github.com/dotnet/corefx/issues/18394

— Jean-Claude

Wspomniany również tutaj: docs.microsoft.com/en-us/dotnet/core/porting/…

— Jean-Claude

2

Clemens Vasters, kierownik techniczny ds. Microsoft .NET Service Bus (to znaczy zarówno usługi zdalne, jak i WCF), mówi o WCF kontra zdalnej komunikacji w tym poście na forum . Podsumowując post, w końcu poleca WCF za pośrednictwem komunikacji zdalnej.

Nie jestem pewien, czy .NET 4.0 korzysta z komunikacji zdalnej wewnętrznie, ale możesz spróbować wysłać Clemensowi pytanie ... Jestem pewien, że zna odpowiedź.

— JohannesH
źródło

11

Pracownik firmy Microsoft zalecający użycie nowej metody błyszczącej-nowej-niezgodnej-ze-wszystkim-innym zamiast jakiejkolwiek formy standardu? Wstrząsający.

— quillbreaker

14

W jaki sposób WCF nie jest zgodne ze wszystkim innym? A z czym był kompatybilny Remoting?

— John Saunders

2

Jeśli szukasz zgodności, WCF jest -only- wyborem (z wyjątkiem oczywiście asmx, ale to również jest „starsze”). Komunikacja zdalna nigdy nie była odpowiednia w scenariuszach, w których wymagana była zgodność.

— Mark

3

Przyjąłem twoją sugestię i zapytałem Clemensa. Jego odpowiedź: „Remoting jest częścią .Net Framework i jako taki nie odejdzie ... W trakcie komunikacji między aplikacjami Remoting jest rodzimym sposobem komunikacji CLR”.

— Mark

1

Następnie mówi, że należy „poważnie przyjrzeć się WCF i NetNamedPipeBinding”.

— John Saunders

2

Myślę, że teraz (2015) jest to całkiem jasne, nawet w przypadku domen obejmujących wiele aplikacji: https://msdn.microsoft.com/en-us/library/vstudio/ms180984(v=vs.100).aspx

Usługi zdalne między domenami aplikacji Ten temat jest specyficzny dla starszej technologii, która jest zachowywana w celu zapewnienia wstecznej zgodności z istniejącymi aplikacjami i nie jest zalecana do nowego rozwoju. Aplikacje rozproszone powinny teraz być opracowywane przy użyciu Windows Communication Foundation (WCF).

Następnie należy użyć WCF również dla domen między aplikacjami.

— Armando
źródło