Niestandardowe standardy

Java Community Process należy do najlepiej zorganizowanych komitetów standaryzacyjnych w przemyśle informatycznym.

Java Community Process należy do najlepiej zorganizowanych komitetów standaryzacyjnych w przemyśle informatycznym.

Scenariusz prawie zawsze wygląda podobnie - dwie firmy zawierają umowę dotyczącą wspólnych prac nad jakimś nowatorskim rozwiązaniem, z czasem przyłączają się do nich następne firmy, aż w końcu formuje się komitet standaryzacyjny, pozornie niezależny od jakiegokolwiek producenta sprzętu lub oprogramowania. Zdarza się również tak, że do opracowania standardu wystarczy jedna firma. Nie brakuje na rynku przykładów tzw. standardów de facto, których moc obowiązywania jest utrzymywana siłą i pozycją rynkową firmy promującej własne rozwiązanie.

Szkodliwe drobne poprawki

Wbrew dość powszechnemu wyobrażeniu, aby powstał standard respektowany przez większą część przemysłu informatycznego, nie wystarczy papierowa dokumentacja wieńcząca dzieło sztabu teoretyków. Zanim standard wejdzie do powszechnego użytku, konieczna jest jego implementacja, a więc dostarczenie programiście konkretnego interfejsu API opartego na specyfikacji zatwierdzonej przez komitet standaryzacyjny. W ostatnich latach częstym zjawiskiem stało się, że różnego rodzaju ciała standaryzacyjne mają ambicje konstruowania bardzo wysublimowanych specyfikacji, których później nie udaje się zastosować w praktyce. Przykładów takich martwych specyfikacji jest wiele. Najbardziej znany to język SQL 3, któremu brakuje pełnej implementacji (w dużej mierze ze względu na brak zainteresowania problemem ze strony przemysłu IT).

Wiadomo że standardy są pożyteczne tak długo, jak długo wszyscy posługują się nimi zgodnie z pierwotną specyfikacją. W rzeczywistości żaden komitet standaryzacyjny nie jest w stanie przeciwdziałać nagminnym praktykom firm, które na własną rękę poprawiają standardy. Do czego to prowadzi dobrze ilustruje przykład technologii CORBA, której powstanie nadzorował komitet OMG, zrzeszający prawie 1000 firm programistycznych. Mimo że w tym licznym gronie udało się wypracować kompromis i przedstawić spójną specyfikację, to praktyczne implementacje CORBA są ściśle powiązane z cechami poszczególnych serwerów aplikacyjnych i brokerów ORB (Object Request Broker - szyna komunikacyjna w technologii CORBA).

Złym praktykom stara się zaradzić WS-I, organizacja powołana do koordynowania prac nad standardami związanymi ze współpracą usług Web. Do umowy członkowskiej dodano klauzulę, że aby być "zgodnym ze standardem WS-I", należy nie tylko zaimplementować opracowany pod jej auspicjami protokół, ale ponadto nie wolno rozbudowywać go o własne rozszerzenia.

Komitet pod silnym przywództwem

Sun Microsystems, twórca Javy, powołał komitet JCP, którego zadaniem jest koordynacja rozwoju bibliotek programistycznych towarzyszących temu językowi. W odróżnieniu od większości komitetów, praca nad każdą nową specyfikacją dotyczącą Javy tzw. JSR nie kończy się na ustaleniu nowego interfejsu. W ramach procesu standaryzacyjnego JCP muszą powstać m.in. zestaw testów, zestaw narzędzi dla developerów i dokumentacja.

Każda firma będąca członkiem JCP płaci roczną składkę w wysokości 5 tys. USD (organizacje non-profit 2 tys. USD). W strukturach JCP tak samo ważny jest głos wielkiego IBM, jak głos małej firmy programistycznej. W rzeczywistości jednak z grona ponad 660 członków najwyżej kilkunastu jest w stanie udźwignąć ciężar prowadzenia samodzielnie projektu, który ma szansę przerodzić się w specyfikację JSR.

Ostateczna propozycja standardu Javy zostaje poddana ocenie wszystkich członków JCP. Nowy standard musi być zaakceptowany przez większość członków. Demokratyczne reguły nie eliminują całkowicie politycznych gier prowadzonych przez największe firmy wchodzące w skład JCP, ale z pewnością ograniczają to zjawisko.

Konieczność uzyskania zgody większości powoduje natomiast, że procedura standaryzacyjna JCP pochłania wiele czasu. Według Suna proces ustalania jednej specyfikacji JSR zajmuje średnio ok. 9 miesięcy. Opóźnienia w standaryzacji Javy szczególnie dały o sobie znać przy okazji tworzenia bazowych standardów związanych z usługami Web. Aby usługi Web z koncepcji przerodziły się w konkretne produkty, oprócz uniwersalnego protokołu wywoływania usług, konieczne było stworzenie odpowiednich API dla programistów. W przypadku Javy prace nad interfejsem zaczęły się dosyć szybko, ale równolegle każdy producent serwera aplikacyjnego opracowywał własne biblioteki API. Standardowe interfejsy Javy do usług Web weszły dopiero do specyfikacji J2EE 1.4 (obecnie dostępna jest zaledwie beta 2 wzorcowego serwera aplikacyjnego zgodnego z tym standardem), podczas gdy większość producentów od dawna oferuje swoje rozwiązania łączące Javę ze światem usług Web.

Obecnie większość producentów oprogramowania, którzy na własną rękę pracowali nad implementacją usług Web w Javie, planuje przejście na rozwiązanie standardowe opracowane w ramach JCP. Niektórzy jednak, np. Oracle, bardzo ostrożnie podchodzą do tego zagadnienia. Tłumaczą to tym, że trudno wyobrazić sobie taką usługę Web, która uruchomiona na serwerze aplikacyjnym BEA Systems nie będzie w stanie komunikować się z serwerami Oracle 9iAS czy IBM WebSphere - niezależnie od producenta, interfejsy API Javy opracowane na potrzeby poszczególnych serwerów aplikacyjnych zawierają ustalony, prawie identyczny zestaw protokołów.

Podobnie sytuacja wygląda w przypadku WS-Security - rozwiązania, które ma umożliwić podpisywanie cyfrowo usług Web. JCP prowadzi prace nad standardowym API, ale jednocześnie IBM - jeden z największych promotorów Javy - w swoim pakiecie do tworzenia usług Web już zaimplementował własne "konkurencyjne" rozwiązanie.

Szerokie otwarcie

Kierownictwo Suna przyjęło scenariusz rozwoju Javy pod okiem JCP już w połowie lat 90. (JCP praktycznie zaczął sprawnie działać od 1998 r.). Tym firma tłumaczy fakt, że - mimo ostrej krytyki i to nie tylko ze strony konkurentów - nie zgodziła się powierzyć nadzoru nad Javą niezależnemu komitetowi standaryzacyjnemu - odpowiedniego organu nie było i nadal nie ma.

Na deklaracje Suna o udostępnieniu kilku standardów Javy środowiskom open source należy patrzeć nie tylko jak na krok w kierunku otwarcia tej platformy, ale także jako na próbę zaszczepienia w środowisku "otwartego kodu" mechanizmów standaryzacyjnych wzorowanych na JCP. Obecnie "otwarte" są m.in. specyfikacje JSR związane z usługami Web, projektem JXTA (ma on na celu określenie zasad współpracy różnych urządzeń w sieciach peer-to-peer) oraz JINI (mechanizm do tworzenia rozproszonych systemów, przekazywania zdarzeń, transakcji itp.).

Proces JCP
  1. Rozpoczęcie prac. Członek społeczności JCP proponuje specyfikację nowego API. Specyfikacja jest zatwierdzana do dalszych prac przez komitet wykonawczy.
  2. Powstaje wewnętrzny szkic specyfikacji. Formowana jest grupa ekspertów, która tworzy kolejne edycje dokumentu. Prace może kontrolować też komitet wykonawczy. Powstają kolejne recenzje i wersje szkicu. O przejściu do dalszego etapu decyduje komitet wykonawczy (a nie grupa ekspertów pracujących nad daną specyfikacją).
  3. Powstaje ogólnodostępna specyfikacja. Każdy może komentować i sugerować zmiany, jednak to komitet wykonawczy decyduje, jakie sugestie uwzględnić w dalszych pracach. Równocześnie trwają prace nad referencyjną implementacją i TCK (Technology Compatibility Kit). W momencie gdy lider grupy ekspertów uznaje, że implementacja jest zakończona, przesyła dokument do ostatecznej akceptacji komitetowi wykonawczemu.
  4. Po akceptacji następuje faza ''utrzymania'', w której zarówno specyfikacja, jak i referencyjna implementacja są aktualizowane zgodnie z napływającymi żądaniami. O kolejności prac lub pominięciu pewnych żądań decyduje komitet wykonawczy.
Wszystkie organy, w tym komitet wykonawczy, są wybierane w sposób demokratyczny spośród członków JCP.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200