Z naciskiem na elastyczność

Akademickie podejście do budowania aplikacji jest dobre w warunkach akademickich. W biznesie potrzebna jest elastyczność i dostawcy technologii zaczynają to dostrzegać, ale byłoby jeszcze lepiej, gdyby dostrzegły to także uczelnie techniczne.

Akademickie podejście do budowania aplikacji jest dobre w warunkach akademickich. W biznesie potrzebna jest elastyczność i dostawcy technologii zaczynają to dostrzegać, ale byłoby jeszcze lepiej, gdyby dostrzegły to także uczelnie techniczne.

Z naciskiem na elastyczność

Współczesny cykl życia aplikacji coraz bardziej odbiega od rozwiązań znanych z innych dziedzin inżynierii, gdzie najpierw powstaje solidny projekt, produkt, potem (zwykle) następuje faza testów, a wreszcie dzieło przekazywane jest klientowi do eksploatacji. Przy tworzeniu oprogramowania bywa tak, że klient "wyrywa" (lub mu się "oferuje") produkt nieprzetestowany tylko dlatego, że nagle musi go zacząć używać i nie ma alternatywy. Albo nagle okazuje się, że część projektu może być realizowana później (albo wcale), a inna jest potrzebna "na już".

Projekt, w którym stosuje się "klasyczne" podejście do produkcji oprogramowania, trafia się naprawdę rzadko - zdarza się, że zmianie ulegają nawet te najbardziej fundamentalne założenia. Modyfikacje wcale nie muszą wynikać z niedokładnej analizy czy nieświadomości klienta/dostawcy. W polskich warunkach wystarczy policzyć średnią miesięczną liczbę aktualizacji prawa...

Zwykle zespół pracuje w mniej lub bardziej formalnym cyklu iteracyjnym, modyfikacje i zmiany po ustaleniach z klientem są więc wprowadzane do projektu na bieżąco. Rośnie popularność metod projektowych typu SCRUM, czy osławionego eXtreme Programming. W tym przypadku w samą metodykę wbudowana jest bardzo duża elastyczność, a klient jest niemal formalnie członkiem zespołu. Co prawda na końcu nie otrzymuje się dokładnie tego co "wydawało się", że jest budowane na początku tworzenia projektu, ale klient jest zadowolony (przynajmniej wg teoretycznych założeń metodologii), a na pewno ma istotny wpływ na rozwój w trakcie trwania projektu.

W tym kontekście istotna staje się możliwość definiowania aplikacji w taki sposób, by modyfikacje nie wymagały bardzo dużego nakładu prac. Twórcy systemów informatycznych zwykle nie zastanawiają się, "w czym" napisać daną aplikację. Wybór podyktowany jest albo doświadczeniem zespołu, albo wymaganiem klienta, który już zainwestował w jakąś infrastrukturę. Takie wybory nie muszą być złe, wręcz przeciwnie - często są całkiem dobre, ale...

Jeśli jest taka możliwość, czasami warto się chwilę zastanowić. Być może okaże się, że konkretny problem da się rozwiązać szybko za pomocą nieco innych niż zwykle technologii, biblioteki czy języka programowania. Jeżeli rozwiązanie ma przyzwoitą architekturę, wprowadzanie zmian nie jest tak bardzo kłopotliwe. Natomiast zawsze jest to ograniczone tym, co projektant sądził o zmianach, jakim oprogramowanie będzie podlegać w przyszłości.

Wspólny mianownik

Pojawienie się koncepcji SOA zmieniło trochę sposób myślenia o konstrukcji systemów. Co prawda na palcach jednej ręki można policzyć aplikacje realizowane od początku do końca zgodnie z wytycznymi SOA, ale na pewno koncepcja ta ma obecnie duży wpływ na konstruowanie rozwiązań.

Większość nowo tworzonych aplikacji ma jasno wydzielone moduły, pomiędzy którymi następuje komunikacja zgodna z ustalonymi zasadami "odpowiedzialności". Nie jest to może formalny "kontrakt" SOA, ale takie reguły określają, jaką rolę pełni moduł i co należy do niego przesłać, by uzyskać określony efekt. Zwykle dodatkowo taka komunikacja wykorzystuje standardowe protokoły, ale niekoniecznie musi to być właśnie WS Basic Profile - warstwa transportowa może być standardowa z punktu widzenia infrastruktury "zastanej" w danej firmie.

Producenci infrastruktury, reklamując swoje rozwiązania SOA, podkreślają możliwości działania na różnych platformach itp. Ale taki sposób myślenia o aplikacjach i kontraktowym powiązaniu pomiędzy modułami sprawia także, iż jest obojętne, w jakiej technologii, czy jakim języku napisany jest dany fragment. Należy pamiętać, że usługi Web są możliwe do zrealizowania chyba już w każdym języku , środowisku czy platformie. Ponieważ tylko sposób komunikacji ma być standardowy, nie ma ograniczeń co do metod realizacji poszczególnych modułów.

Powyższe rozważania dotyczą integracji na wyższym poziomie funkcjonalnym niż np. poszczególne klasy i funkcje. Jeżeli chcemy mieć takie połączenie na niższym poziomie, to problem wciąż istnieje. Najniższym poziomem zgodności jest prosta funkcja C. Chyba nie ma środowiska, w którym ten kompilator nie byłby dostępny. Ma proste zasady wywoływania - różnice mogą dotyczyć raptem kolejności umieszczania parametrów na stosie i ewentualnie kolejności lub długość słowa. Nie ma tu przekazywania "obiektów" itp., ale wystawienie prostej funkcjonalności jako usługi nadal jest możliwe.

Microsoft .Net znacznie ułatwia integrację na niższych poziomach. W specyfikacji wydzielonych zostało kilka "poziomów" zgodności pomiędzy językami i jasno nakreślono mechanizmy pozwalające wymieniać typy itp. Co prawda w świecie Javy nie ma tak formalnie zdefiniowanych zasad komunikacji pomiędzy różnymi językami, ale także tam pojawiają się próby stworzenia języka innego niż Java, który będzie generował kod dla JVM. Wtedy "poziomem" zgodności są typy Javy.

Popularność, rzecz względna

Warto zwrócić uwagę na popularność języków programowania mierzoną przez TIOBE Software (www. tiobe. com). To tak naprawdę jedyna firma, która zajmuje się mierzeniem popularności języków, badając, w jaki sposób ludzie publikują i szukają informacji na określony temat. Co prawda do metodologii (to badanie oparte jest na podsumowaniu wyników wyszukiwania w Google, MSN, Yahoo i Google Groups) można mieć trochę zastrzeżeń, ale ponieważ od kilku lat jest taka sama, widoczne są pewne trendy.

W tym roku po raz pierwszy C stał się mniej popularnym językiem niż Java i prawdopodobnie tendencja spadkowa w przypadku tego języka utrzyma się dosyć długo. Co ciekawe, C++, czy stary Visual Basic zachowują stały "udział" w badaniu. Pozycja Delphi nieznacznie spada, zaś C# przeskoczył z 9. miejsca na 7. Warto odnotować, że coraz bardziej popularny staje się czołowy język funkcyjny Lisp i jego młodszy brat Scheme. W badaniu ze stycznia 2006 r. po 49% miały języki proceduralne i obiektowe, ale obiektowe zyskały w stosunku do poprzedniego roku 3%, a prawie tyle samo straciły języki proceduralne.

Podobne ruchy można zaobserwować w przypadku powolnej migracji do języków typowanych (czyli takich, w których zmienna ma jasno określony typ i w przypadku gdy trzeba przekształcać wartości pomiędzy różnymi typami, stosowane są dodatkowe funkcje konwertujące), które obecnie mają 65% (rok temu było to 62%). Tego typu język sprawia, że programista ma "odrobinę" mniejszą możliwość popełnienia głupiego błędu, ale za to miejscami kod jest bardziej skomplikowany.

Języki obiektowe to nie tylko pewna określona składnia, klasy itp., ale sposób podejścia do problemu. Koncepcja "wzorców" projektowych - tych niskopoziomowych, jak schemat factory czy schemat singleton, czy bardziej rozbudowanych, określających sposób działania obliczeń klastrowych z wyrównywaniem obciążeń, albo np. schemat Brookera. Witryny, takie jakhttp://patternshare.org czy www.martinfowler.com, prezentują fundamenty wzorców, omawiając je zwykle w oderwaniu od konkretnego języka. Natomiast już po krótkim przeglądzie samych wzorców i sposobów ich implementacji widać wyraźnie, że owszem - prawie w każdym języku obiektowym można je zrealizować, ale są takie, gdzie kod implementacji zajmie 1000 linii oraz takie, gdzie tych linii będzie 50.

J2EE tak, ale...

Wszyscy poważniejsi producenci infrastruktury dla przedsiębiorstw (z wyjątkiem Microsoftu) skupili się na rozwiązaniach związanych z Javą, oferując serwery aplikacyjne i ich rozszerzenia. Po początkowym okresie, gdy Java (a potem stos J2EE) była nowością, dzięki wsparciu silnych dostawców stała się pozornie "jedyną" platformą do pisania aplikacji dla wielkich firm. W tamtym czasie alternatywą była inwestycja w mainframe i przetwarzanie terminalowe albo też rozwiązania klient-serwer, w których skalowalność ograniczały w zasadzie koszty licencji baz danych oraz fakt, że nikt nie tworzył tych rozwiązań z myślą o WWW i dużych, okresowych obciążeniach.

Początkowo J2EE miało być "pojemnikiem" na komponenty, który pozwalał na programowanie obiektowe (ale nie komponentowe!) z podstawowymi metodami usługowymi, jak np. propagacja kontekstu transakcyjnego, wyrównywanie obciążeń itp. Wszystko co potrzebne ujęte zostało w specyfikacji i teoretycznie programista mógł w analogiczny sposób programować systemy, które działały na różnych serwerach aplikacyjnych.


TOP 200