2012-01-02 19 views
5

Po prostu szukałem programowania API .NET WCF. Być może będziemy musieli często aktualizować interfejsy API.Implementacja interfejsu WCF API Wersja

Jak zarządzać wieloma wersjami wdrożenia API?

+0

po pierwsze, Twoje pytanie poważnie brakuje jakości. Na początek zadajesz trzy oddzielne pytania, więc powinieneś utworzyć trzy pytania. Po drugie, na osiem pytań, na które udzielono odpowiedzi, tylko na dwie z nich udzielono odpowiedzi.To zniechęci ludzi do pomocy. Prosimy o ponowne sprawdzenie tych pytań i udzielenie odpowiedniej odpowiedzi. –

+0

Dzięki Hugh! Mam zaktualizowane pytanie do zawężenia. Za odpowiedzi, które otrzymałem do tej pory, udzieliłem odpowiedzi na pytania, w których znalazłem je jako rozwiązanie, pozostałe to sugestie, które nie prowadzą do żadnego odpowiedniego rozwiązania. Nadzieję, że rozumiecie. –

+0

Jeśli żadna z otrzymanych odpowiedzi nie doprowadziła Cię do rozwiązania problemu, prawidłową rzeczą jest opublikowanie znalezionego rozwiązania, a następnie oznaczenie jako odpowiedzi. Wtedy ludzie przychodzący na twoje pytanie mogą przynajmniej zobaczyć, jak udało ci się go rozwiązać. –

Odpowiedz

6

Wersjonowanie usług to ogromny temat z wieloma uwagami i wskazówkami.

Na początek istnieją różne klasy zmian, które można wprowadzić; pełne łamanie, półłamanie i nie łamanie.

non-breaking zmiany (nie potrzeba do istniejących klientów zmień) obejmują:

  • zmianę wewnętrznej realizację usługi przy zachowaniu narażoną kontrakt niezmienionej
  • zmianę rodzaju umowy w sposób, który nie rozbijać klientów, na przykład, dodając pola do typów zwracanych przez operacje (większość serializatorów podniesie zdarzenie, a nie wyrzuci wyjątek podczas napotkania nieoczekiwanego pola przy deserializacji)
  • polimorficznie eksponuje nowe typy (za pomocą atrybutu ServiceKnownType)
  • zmieniając ustawienia zarządzania instancją usługi (per-call do Singleton, sessionless do sessionful itp, chociaż czasami będzie to wymagało zmian w konfiguracji lub nawet kod)

Semi-rozerwanie zmiany (zwykle mogą być skonfigurowane na klient) inlcude:

  • zmiany położenia usługi
  • zmianie rodzaju transportu usługa jest odsłonięte po drugiej stronie (choć zmienia się z dwukierunkowym do uni-kierunkowe transportu - np http do Msmq - może być w pełni przełomowa zmiana)
  • zmieniając dostępność usługi (poprzez zastosowanie okien usługowych itp)

pełni łamiących zmiany (trzeba nową wersję klienta) obejmują:

  • zmieniające usługowa podpisów pracy
  • zmieniające typy odsłonięte w sposób łamiący (usuwanie pól, itp.)

Kiedy zamierzasz dokonać pół-pełnej zmiany, powinieneś ocenić najlepszy sposób robienia tego. Czy zmuszasz wszystkich klientów do aktualizacji do nowej wersji, czy też obsługujesz obie wersje tej usługi na różnych punktach końcowych? Jeśli wybierzesz tę drugą, to w jaki sposób będziesz kontrolować i zarządzać propagacją różnych zależności wersjonowania, które to może wprowadzić?

Podejrzane do ekstremum, można przyjrzeć się dynamicznej rozdzielczości punktu końcowego, w której klient rozwiązuje odpowiedni punkt końcowy, aby wywołać w środowisku wykonawczym za pomocą pewnego rodzaju usługi przelicznika.

Jest dobry odczyt na ten temat tutaj: http://msdn.microsoft.com/en-us/library/ms731060.aspx

+0

Dzięki Hugh! To da początek. Pozwól mi wejść w szczegóły. Planuję wdrożyć usługę, która będzie zużywana przez natywne aplikacje mobilne. Chciałbym użyć numeru wersji podczas uzyskiwania dostępu do adresu URL usługi, np. Www.example.com/MojeService/1.0/. Być może trzeba okresowo aktualizować aplikacje natywne i dodawać/aktualizować metody w mojej usłudze i wdrażać je z innym numerem wersji, aby móc korzystać z wielu wersji aplikacji mobilnych i usług, a następnie mogę odejść od starszej wersji aplikacji mobilnej i usługi od od czasu do czasu. –

Powiązane problemy