Cała specyfikacja - SCA_AssemblyModel_V100.pdf - zajmuje 90 stron i jest to najgorsza, pod względem wyglądu, specyfikacja, jaką przyszło mi ostatnio czytać. Treść czyta się płynnie i nie zawiera górnolotnych stwierdzeń zrozumiałych dla wtajemniczonych, więc pod tym względem jest w porządku.
Spróbuję streścić zawartość specyfikacji w pojedyńczej notatce.
Podwalinami SCA jest postrzeganie rozwiązań biznesowych jako zbioru usług, które można scalić w celu udostępnienia kolejnej, bardziej specjalizowanej funkcjonalności. Rozwiązania mogą zawierać nowe usługi stworzone specjalnie na potrzeby nowej aplikacji, jak również wykorzystać już istniejące usługi (jest to generalnie podejście architektoniczne zwane SOA - Service-Oriented Architecture, ale jako, że jest wyłącznie podejście musi mieć podwaliny technologiczne i właśnie SCA jest ich częścią).
SCA udostępnia model tworzenia oraz integracji usług za pomocą różnorodnych technologii. W SCA komponenty mogą być tworzone przy pomocy wielu języków programowania - Java, C++ i BPEL oraz szkieletów programistycznych, które są związane z nimi, np. Spring Framework (istnieje również możliwość rozbudowywania środowiska uruchomieniowego SCA o nowe technologie). Do ich integracji SCA udostępnia całą gamę technologii komunikacyjnych oraz upraszczających dostęp do usług - JAX-WS, JMS, RPC.
Specyfikacja modelu montażu SCA składa się z artefaktów, które definiują konfigurację domeny SCA za pomocą SCAleń, które z kolei zawierają komponenty usługowe, powiązania oraz zależne artefakty, które opisują jak one są związane za pomocą łączy.
Podstawowym elementem SCA jest komponent (ang. component), który jest elementarną jednostką konstrukcji w SCA. Komponent składa się z egzemplarzy implementacji dostarczających funkcje biznesowe. Funkcja biznesowa dostarczana jest do użycia przez komponenty jako usługa (ang. service). Implementacje mogą opierać się o usługi dostarczane przez inne komponenty, które nazywamy referencjami (ang. references). Implementacje mogą udostępniać możliwość zmiany wartości właściwości (ang. properties), które wpływają na przebieg działania oferowanej funkcji biznesowej. Komponent jest, więc konfiguracją implementacji przez ustawienie wartości właściwości oraz przez związanie referencji do usług udostępnianych przez inne komponenty.
SCA umożliwia tworzenie komponentów za pomocą języków Java, C++, BPEL oraz języków skryptowych PHP czy JavaScript jak i języków deklaratywnych XQuery oraz SQL.
SCA opisuje zawartość i montaż aplikacji w postaci SCAleń. SCAlenia mogą zawierać komponenty, usługi, referencje, deklaracje właściwości oraz wiązania, które opisują połączenia między tymi elementami. SCAlenie może korzystać z komponentów stworzonych w dowolnej, dostępnej w środowisku uruchomieniowym SCA, technologii umożliwiając w ten sposób dopasowanie technologii realizacji funkcji biznesowej do jej wymagań i możliwości wytwórczych zespołu projektowego. Z kolei, SCAlenia mogą być używane jako gotowe implementacje, które mogą stanowić składowe kolejnych SCAleń umożliwiając w ten sposób hierarchiczne budowanie rozwiązań biznesowych, gdzie usługi wyższego poziomu są złożeniami usług niższego poziomu. W ten sposób można konstruuować rozwiązania bardziej specjalizowane i dopasowane do potrzeb klienta na bazie dostępnych usług.
SCAlenia są uruchamiane w ramach domeny SCA (ang. SCA domain). Zazwyczaj, domena reprezentuje zbiór usług udostępniających obszar funcjonalności biznesowej kontrolowanej przez pojedyńczą organizację.
SCA definiuje format pliku konfiguracyjnego XML. Deskryptory XML są przenośną reprezentacją statycznych bytów SCA.
Komponent jest podstawowym elementem funkcji biznesowej w zestawie SCA (ang. SCA assembly), które są łączone w gotowe rozwiązania biznesowe przez SCAlenia.
Komponenty są gotowymi do użycia instancjami implementacji. Komponenty dostarczają i korzystają z usług. Więcej niż jeden komponent może używać i konfigurować tą samą implementację na potrzeby jej wymagań.
Komponenty są zadeklarowane jako podelementy SCAlenia w pliku - deskryptorze XML o rozszerzeniu .composite. Komponent jest reprezentowany przez element component będącym potomkiem elementu composite. Element composite może zawierać wiele elementów component. Obowiązkowym atrybutem elementu component jest atrybut name nadający nazwę komponentu, która musi być unikatowa w ramach SCAlenia (wewnątrz composite).
<component name="DictionaryServiceComponent">
<implementation.java class="pl.jaceklaskowski.sca.dictionary.DictionaryServiceImpl" />
<reference name="englishPolishDictionaryService" target="EnglishPolishDictionaryServiceComponent" />
<reference name="germanPolishDictionaryService" target="GermanPolishDictionaryServiceComponent" />
</component>
<component name="EnglishPolishDictionaryServiceComponent">
<implementation.java class="pl.jaceklaskowski.sca.dictionary.EnglishPolishDictionaryServiceImpl" />
</component>
<component name="GermanPolishDictionaryServiceComponent">
<implementation.script script="pl/jaceklaskowski/sca/dictionary/groovy/GermanPolishDictionaryServiceImpl.groovy"/>
</component>
Element component może zawierać wiele elementów implementation.*, które wskazują na implementację używaną przez komponent. Komponent bez implementacji nie może być uruchomiony, jednakże może służyć jako możliwość nakreślania usług przy konstruowaniu komponentów metodą "od góry - w dół", czyli od ogólnego spojrzenia do szczegółów.
Komponent może zawierać wiele elementów services jako sposób konfiguracji usług komponentu. Usługi możliwe do konfiguracji są zdefiniowane przez implementację.
Element service posiada obowiązkowy atrybut name, który nadaje nazwę usłudze i która musi odpowiadać nazwie usługi zdefiniowanej przez implementację.
<service name="DictionaryService" promote="DictionaryServiceComponent">
<interface.java interface="pl.jaceklaskowski.sca.dictionary.DictionaryService" />
</service>
Usługa posiada wiele elementów interfejs, które opisują operacje udostępniane przez usługę. Jeśli nie określono interfejsu usługi, wtedy obowiązującym interfejsem jest interfejs określony przez implementację. Jeśli określono interfejs, to musi być on podzbiorem interfejsu udostępnianego przez implementację, czyli określać podzbiór operacji zdefiniowanych przez implementację.
Element service może zawierać wiele elementów binding. Jeśli nie podano żadnego elementu binding, wtedy binding wyznaczany jest przez implementację.
Element component może posiadać wiele elementów reference, które określają referencje komponentu do usług. Referencje, które mogą być konfigurowane, określone są przez implementację. Element reference posiada obowiązkowy atrybut name, który przypisuje nazwę referencji, która z kolei musi odpowiadać nazwie referencji zdefiniowanej przez implementację.
Referencja może posiadać wiele elementów interface, które opisują operacje wymagane przez referencję. Jeśli nie podano żadnego elementu interface, obowiązujący interfejs określony jest przez implementację. Interfejs musi określać zbiór interfejsów dostarczanych przez implementację, tj. dostarczać operacje zdefiniowane przez implementacje dla danej referencji.
Element reference zawiera wiele elementów binding. Podobnie jak przy elemencie binding dla service, tak i tutaj albo podajemy zbiór zgodny z możliwościami implementacji, albo przy jego braku wyznaczany jest na podstawie implementacji. Element binding może określać endpoint, który będzie jego realizacją. Referencja nie może korzystać równocześnie z endpoint w ramach wiązania oraz docelowymi endpoint określonymi przez atrybut target. Jeśli atrybut target jest określony, elementy binding mogą jedynie definiować typy wiązania określone przez atrybut target. Jeśli endpoint są określone w elementach binding, wtedy każdy endpoint musi korzystać z typu binding, w którym jest zdefiniowany. Dodatkowo, w takim przypadku każdy element binding potrzebuje określić pewien endpoint.
Element component może zawierać wiele elementów property, które są używane do konfiguracji właściwości implementacji. Właściwości do konfiguracji i ich typy określone są przez implementację.
Implementacja może zadeklarować wielowartościową właściwość.
Wartość właściwości może być określona w jeden z poniższych sposobów:
- Jako wartość dostarczoną jako zawartość elementu property.
- Jako referencję do właściwości innego SCAlenia, który zawiera ten komponent. Referencja jest tworzona przez atrybut source jako wyrażenie XPath.
- Jako adres URI będący wskazaniem na plik, którego zawartość jest traktowana jako wartość właściwości, za pomocą atrybutu file.
Opcjonalnie, typ właściwości może być określony na jeden z poniższych sposobów:
- przez pełną nazwę typu zdefiniowanego w schemacie XML za pomocą atrybutu type.
- przez pełną nazwę globalnego elementu w schemacie XML za pomocą atrybutu element.
Element property posiada obowiązkowy atrybut name, który przypisuje nazwę właściwości, która musi odpowiadać nazwie właściwości zdefiniowanej przez implementację.
Implementacje komponentów są konkretnymi implementacjami funkcji biznesowych, które udostępniają usługi i/lub korzystają z innych. Dodatkowo, implementacje mogą udostępniać możliwość zmiany własnych właściwości.
SCA posiada wiele typów implementacji, takich jak Java, BPEL, C++. Wybór typu określa użycie technologii implementacji, która poza wykorzystaniem języka programowania (Java lub C++), może określać szkielet programistyczny lub środowisko uruchomieniowe, np. Spring Framework lub EJB.
Dostępne są następujące typy implementacyjne:
- implementation.java
- implementation.bpel
- implementation.composite
- implementation.spring
- implementation.ejb
<interface.java interface="pl.jaceklaskowski.sca.dictionary.PolishEnglishDictionaryService" />
<implementation.script script="pl/jaceklaskowski/sca/dictionary/groovy/GermanPolishDictionaryServiceImpl.groovy" />
Usługi, referencje oraz właściwości są zmiennymi elementami implementacji. SCA określa je jako typ komponentu. Typ komponentu jest wyznaczany na podstawie implementacji, jednakże wiele z elementów może zostać nadpisanych przez komponent, który korzysta z i konfiguruje implementację według własnych potrzeb. Typ składa się z oferowanych usług, referencji do innych usług poprzez wiązania oraz właściwości, które mogą być modyfikowane. Możliwość przesłaniania (nadpisywania) charakterystyki komponentu, jak ustawianie właściwości czy referencji, może być ograniczona, np. udostępniane interfejsy mogą być jedynie zawężane (muszą być zgodne z typami obsługiwanymi przez implementację).
Sposoby deklarowania usług, referencji oraz właściwości zależą od typu implementacyjego. W przypadku języka Javy (implementation.java) można skorzystać z adnotacji.
Podczas działania, postać egzemplarza implementacji zależy od wykorzystywanej technologii. Logika biznesowa działania egzemplarza są niezmienne i zależy od implementacji, lecz wartości właściwości i referencje pochodzą również od komponentu, który konfiguruje implementację na własne potrzeby.
Wyznaczanie typu komponentu jest realizowane dwukrokowo. Najpierw przeglądana jest implementacja, wliczając w to sprawdzenie adnotacji. Kolejny krok to uzupełnienie informacji o dane zawarte w pliku typu komponentu (ang. component type file). Bez względu na możliwość realizacji pierwszego (brak wsparcia dla analizy typu czy adnotacji), czy drugiego kroku (brak pliku), po ich wykonaniu środowisko uruchomieniowe oczekuje kompletnej informacji o typie. W typach implementacyjnych, gdzie możliwe jest korzystanie z analizy typu (prześwietlanie - ang. reflection) oraz adnotacji wykorzystanie pliku typu komponentu będzie znikome.
Nazwa pliku typu komponentu odpowiada nazwie pliku implementacji z rozszerzeniem .componentType. Typ komponentu jest definiowany przez element componentType wewnątrz pliku. Miejsce położenia pliku jest związane z mechanizmami wspieranymi przez typ implementacyjny i jest opisany w odpowiadającej mu specyfikacji modelu implementacji SCA.
Interfejs definiuje funkcje biznesowe. Funkcje są dostarczane przez usługi i używane przez referencje. Usługa dostarcza funkcjonalność biznesową dokładnie jednego interfejsu, która może być używana przez inne komponenty. Każdy interfejs definiuje operacje z komunikatami wejściowymi (ang. request (input) message) i komunikaty zwrotne (ang. response (output) message). Komunikaty mogą być typami prostymi bądź złożonymi.
SCA wspiera typy interfejsów zdefiniowane przez następujące języki:
- interfejsy Java (element interface.java)
- portType w WSDL 1.1 (element interface.wsdl)
- interfejsy WSDL 2.0 (element interface.wsdl)
Wyróżniamy interfejsy lokalne i zdalne. Interfejs zdalny może być wywołany przez klienta uruchomionego na systemie zewnętrznym w stosunku do usługi. Interfejs Java jest zdalny, jeśli zostanie udekorowany przez adnotację @Remotable. Interfejsy zdefiniowane przez WSDL są zawsze zdalne.
Komunikaty wejściowe operacji określonych przez interfejs zdalny są zawsze przekazywane przez wartość. Istnieje możliwość oznaczenia komunikatu (parametru) wejściowego jako przekazywanego przez referencję, dla klientów, którzy uruchamiani są w tej samej przestrzeni, co usługa, mimo korzystania z interfejsu zdalnego przez adnotację @AllowsPassByReference.
Lokalne interfejsy nie mogą być opublikowane przez zdalne usługi komponentów. Interfejs lokalny może być wywoływany przez klientów z tej samej przestrzeni, gdzie uruchomiony jest komponent realizujący interfejs. Brak adnotacji @Remotable w interfejsie jest oznaczeniem interfejsu jako lokalny.
Wybór typu interfejsu - lokalny vs zdalny - wiąże się ze sposobem interakcji między usługobiorcą a usługodawcą. Interfejs zdalny przewidziany jest do komunikacji pojedyńczej, bardzo złożonej, w przeciwieństwie do interfejsu lokalnego, który wykorzystywany jest do komunikacji bardzo drobnej w sensie jej złożoności biznesowej.
SCAlenie (ang. composite) służy do połączenia elementów SCA w logiczną całość. SCAlenie jest podstawową jednostką konstrukcji w ramach domeny SCA. SCAlenie składa się ze zbioru komponentów, usług, referencji i wiązań, które łączą je oraz zbioru właściwości, które służą do konfiguracji komponentów.
SCAlenia mogą być typem implementacyjnym komponentów (implementation.composite).
Zawartość SCAlenia może być używana w ramach innego przez włączenie, co powoduje, że cała zawartość jest dostępna we włączającym SCAleniu jak, gdyby była umieszczona w nim bezpośrednio.
SCAlenie może być używane jako jednostka dystrybucji. SCAlenia dostarczają elementy do domeny SCA. SCAlenie może zostać zainstalowane w domenie SCA albo poprzez włączenie, albo jako implementacja.
SCAlenie zdefiniowane jest w pliku o rozszerzeniu .composite. SCAlenie jest reprezentowane przez element composite. Jedynym obowiązkowym atrybutem elementu composite jest name, który nadaje nazwę SCAleniu.
Nadanie nazwy SCAleniu już istniejącego SCAlenia w domenie SCA może spowodować konflikt nazw. Za pomocą opcjonalnego atrybutu targetNamespace możliwe jest uniknięcie konfliktu.
SCAlenia zawierają właściwości, usługi, komponenty, referencje, wiązania i włączenia.
Komponenty zawierają gotowe do użycia implementacje, które dostarczają logikę biznesową SCAlenia. Komponenty oferują usługi i wymagają dostępności usług wskazanych przez referencje. Usługi SCAlenia definiują usługi publiczne dostarczane przez SCAlenie. Referencje SCAlenia reprezentują zależności od innych, zewnętrznych usług. Wiązania opisują połączenia między usługami i referencjami komponentów w SCAleniu. Włączone SCAlenia (włączenia) dostarczają elementy, które rozbudowują możliwości SCAlenia.
Z usługami SCAlenia związane jest pojęcie promocji (ang. promotion) jednej usługi komponentu w ramach SCAlenia, co oznacza, że usługa SCAlenia jest w zasadzie dostarczana przez jeden z komponentów w ramach SCAlenia. Podobnie jest z właściwościami. Wszystkie promocje, które korzystają z tego samego komponentu, korzystają z tej samej instancji komponentu.
Referencje SCAlenia są definiowane przez promocję referencji definiowanych przez komponenty zawarte w SCAleniu. Każda z referencji wymaga, aby odpowiadający jej komponent był osiągalny poza SCAleniem. Referencje definiowane są za pomocą elementu reference z obowiązkowymi atrybutami name oraz promote.
Usługi SCAlenia są definiowane przez promocję usług definiowanych przez komponenty zawarte w SCAleniu. Usługi definiowane są za pomocą elementu service z atrybutami name oraz promote.
Łącza SCA (ang. SCA wires) w SCAleniu łączą referencje źródłowe komponentu z usługami komponentu docelowego. Jednym ze sposobów definicji wiązania jest konfiguracja referencji komponentu korzystając z atrybutu target elementu reference. Innym sposobem jest wykorzystanie elementu wire. Oba sposoby są semantycznie identyczne.
SCAlenia mogą być typem implementacyjnym komponentu przez użycie elementu implementation.composite. W takiej konfiguracji, komponenty we włączanym SCAleniu nie mogą być bezpośrednio wykorzystane przez włączające SCAlenie. Włączające SCAlenie może jedynie wiązać usługi i referencje SCAlenia włączanego oraz ustawiać wartości właściwości. Wewnętrzna budowa włączanego SCAlenia jest niewidoczna dla SCAlenia włączającego.
SCA udostępnia możliwość budowania SCAlenia jako rozłącznych elementów projektowych, które ostatecznie będą złączone w pojedyńczą logiczną jednostkę. W ten sposób budowa SCAlenia może zostać rozłożona na kilka zespołów programistycznych.
Za pomocą elementu include treść konfiguracji SCAlenia (zawartość pliku .composite) jest włączana do pliku konfiguracyjnego włączającego SCAlenia. Korzystając z takiej możliwości należy zapewnić unikalność nazw składowych SCAlenia.
Jedynym i obowiązkowym parametrem elementu include jest name, który definiuje nazwę SCAlenia, które będzie włączane teksowo, tj. zawartość załączanego pliku composite SCAlenia będzie włączona (wklejona) w miejscu wystąpienia elementu include.
SCAlenia mogą składać się z kilku typów implementacyjnych, np. jeden komponent będzie reprezentowany przez typ implementacyjny Java, podczas gdy kolejny przez proces BPEL.
SCA umożliwia ograniczanie typów implementacyjnych komponentów przez element constrainigType. Pozwala to na tworzenie SCAleń "odgórnie", tj. architekt definiuje strukturę SCAlenia, włączając w to wymaganą postać implementacji, zanim implementacja zostanie zbudowana.
Element constrainigType jest wyrażony jako zbiór usług, referencji i właściwości. Jako, że constrainigType jest niezależny od implementacji nie może zawierać żadnych informacji wprowadzanych do komponentu podczas jego budowy, w szczególności niedozwolone jest użycie binding, policySet, wartości właściwości oraz domyślnych informacji o wiązaniach.
Definicja constrainingType jest łączona z komponentem przez atrybut constrainingType elementu component.
Wiązania (ang. bindings) są używane przez usługi i referencje. Referencje korzystają z wiązań do opisania mechanizmu dostępu wykorzystywanego przy wywołaniu usługi. Usługi korzystają z wiązań, aby opisać mechanizm dostępu, który klienci muszą użyć do jego wywołania.
Istnieje wiele typów wiązań, np. usługa SCA, usługa sieciowa, bezstanowy komponent sesyjny EJB, procedura składowana, usługa EIS. Środowisko uruchomieniowe SCA musi udostępniać wsparcie dla wiązań będących usługą SCA oraz usługą sieciową.
Wiązanie zdefiniowany jest przez element binding w ramach elementu service lub reference w deskryptorze SCAlenia (plik composite).
Wiązanie SCA jest wiązaniem wyrażonym za pomocą elementu binding.sca. Używane do konfiguracji współpracy referencji i usług w ramach pojedyńczej domeny SCA. Realizacja wiązania jest specyficzna dla środowiska uruchomieniowego SCA. Wiązanie SCA jest domyślnym wiązaniem dla usług i referencji bez jawnie podanego elementu binding. Wykorzystanie binding.sca sprowadza się do sytuacji nadpisywania konfiguracji, lub kiedy definiowany jest zbiór binding i binding.sca byłby jednym z nich.
Wiązanie usług sieciowych opisane jest w dokumencie SCA Web Services Binding V1.00.
Wiązanie JMS opisane jest w dokumencie SCA JMS Binding V1.00.
Domena SCA reprezentuje pełną konfigurację uruchomieniową, potencjalnie rozproszoną na kilka połączonych węzłów (serwerów).
Domena SCA definiuje zakres widoczności dla działania mechanizmów SCA. Połączenia SCA mogą być używane wyłącznie dla komponentów w ramach pojedyńczej domeny SCA. Połączenia z usługami spoza domeny muszą korzystać z mechanizmu wiązań. W ogólności, sposób realizacji usługi od strony klienta powinien być nieistotny i realizacja usługi za pomocą SCA jest jedynie szczegółem implementacyjnym.
Typowa domena SCA reprezentuje obszar funkcjonalności biznesowej zarządzanej przez pojedyńczą organizację. Domena może reprezentować całe przedsiębiorstwo, albo pojedyńczy departament.
Domena SCA może wymagać innych elementów do poprawnej pracy. XML jest domyślnym typem artefaktów SCA, których elementem głównym jest composite, componentType, constrainingType lub definitions. Inne typy XML, pliki binarne specyficzne dla języka programowania wykorzystywanego do budowy komponentów SCA mogą być wymagane przez SCAlenia. SCA definiuje format dystrybucji SCAleń, w którym zip jest formatem domyślnym. Nie określa się, czy instalacja dystrybucji spowoduje utrzymanie formatu po instalacji. Środowisko uruchomieniowe SCA oparte o platformę Java EE może zmodyfikować format zip do pakietu EAR.
Zakłada się, że w korzeniu drzewa artefaktów SCA istnieje katalog META-INF zawierający plik o nazwie sca-contribution.xml, który zawiera listę SCAleń w ramach przekazania (ang. contributions). Możliwe układy katalogów i plików w ramach przekazania zawierają katalog, pakunek OSGi, spakowany katalog (w formacie zip, gzip, itp.), lub plik jar (z możliwymi odmianami jak WAR, EAR).
Nie istnieje możliwość zagnieżdżania przekazań w dystrybucji, tj. przekazania nie zawierają przekazań. Jeśli plik jar, który jest przekazaniem, zawiera inne pliki jar nie są one traktowane jako przekazania, a jedynie jako wewnętrzne składowe.
Podkreśla się, że do instalacji i wykorzystania przekazania nie wymagana jest żadna modyfikacja podczas instalacji.
Przekazania mogą być samowystarczalne, tj. wszystkie artefakty konieczne do uruchomienia zawartości przekazania zawarte są wewnątrz przekazania. Możliwa jest sytuacja, w której artefakty przekazania korzystają z artefaktów zewnętrznych w stosunku do pliku przekazania (inne artefakty SCA, pliki WSDL, XSD, klasy Java, skrypty BPEL, itp.).
Do rozwiązywania referencji zewnętrznych służą m.in. atrybuty wsdlLocation i schemaLocation czy mechanizmy dystrybucji OSGi. Jeśli atrybuty są wykorzystywane muszą być podstawą do rozwiązania referencji.
SCA udostępnia mechanizm rozwiązywania (położenia) artefaktów, który wykorzystywany jest w sytuacji braku innych wskazań na położenie potrzebnych artefaktów czy następuje rozwiązywanie położenia różnych przekazań używających różnych technologii do ich budowy - np. łączenie przekazania opartego o OSGi, które korzysta z przekazania opartego o usługi opisane przez WSDL.
Mechanizm rozwiązywania (położenia) artefaktów SCA polega na założeniu, że przekazanie, które korzysta z zewnętrznych artefaktów deklaruje ich potrzebę przez element import w deskryptorze przekazania. Przekazanie może określić dostępność swoich artefaktów za pomocą elementu export w deskryptorze.
Przekazanie może zawierać dokument, który deklaruje dostępne SCAlenia, udostępniane i zewnętrzne artefakty w pliku deskryptorze przekazania SCA. Deskryptor znajduje się w META-INF/sca-contribution.xml w korzeniu przekazania. Uzupełnieniem pliku sca-contribution.xml jest opcjonalny plik META-INF/sca-contribution-generated.xml, który w przypadku wystąpienia kolizji deklaracji ma niższy priorytet.
Deskryptor sca-contribution.xml składa się z opcjonalnych elementów deployable, import i export. Istnienie elementu deployable wskazuje na SCAlenia, które są uruchamiane jako byty podstawowe w ramach domeny, podczas gdy pozostałe SCAlenia są jedynie wykorzystywane przez inne SCAlenia.
Zakłada się, że typowe działanie mechanizmu rozwiązywania artefaktów zależnych ogranicza się do zbioru przekazań w ramach pojedyńczego środowiska uruchomieniowego na jednym serwerze. Zakłada się jednak możliwość rozwiązywania artefaktów uruchomionych w ramach innego środowiska uruchomieniowego SCA, a stąd, aby środowiska SCA wspierały URI przekazań jako specyfikację położenia (opcjonalny atrybut location elementu import). Format adresu URI jest specyficzny dla środowiska SCA.
Rozdział 2.2 Koncepcje SCA kończy dokument i jest doskonałym jego podsumowaniem. Przedstawia fundamentalne pojęcia związane ze specyfikacją SCA i warto się z nim zapoznać podczas rozpoznawania specyfikacji (chociażby, aby upewnić się, że moje zrozumienie tematu i jego przedstawienie tutaj odpowiadają rzeczywistości). Wydawać by się mogło, że rozdział powinien znaleźć się na początku dokumentu, jednakże terminologia jest również wyjaśniona w międzyczasie, a podsumowanie dobrze uporządkowuje pojęcia i zrozumienie specyfikacji SCA.
Wiązanie (ang. binding) - używane przez usługi i referencje. Referencje korzystają z wiązań do określenia sposobu dostępu podczas wywołania usługi, z którą są związane. Usługi korzystają z wiązań do opisania mechanizmu dostępu, jaki powinien być wykorzystany przez klientów korzystających z nich.
Wyróżniamy wiązania: usługa SCA, usługa sieciowa, bezstanowe ziarno sesyjne EJB, procedura składowana, usługa EIS. Istnieje możliwość rozbudowania środowiska SCA o dodatkowe wiązania.
Komponent (ang. component) jest przygotowanym egzemplarzem implementacji SCA, który udostępnia i korzysta z usług. Wyróżniamy technologie implementacyjne: Java, BPEL, C++. Istnieje możliwość rozbudowania środowiska SCA o nowe typy implementacyjne. Wybór podstawowej technologii implementacyjnej pozostawia się dostawcom SCA.
Usługa (ang. service) - lokalna (ang. local) i zdalna (ang. remotable) deklaruje dostępne usługi dostarczane przez implementację. Usługa może być dostarczana jako zdalna usługa SCA, usługa sieciowa, bezstanowe sesyjne ziarno EJB, usługa EIS, itp. Usługi korzystają z wiązań do opisania sposobu ich udostępniania.
Zdalne usługi określone są przez WSDL lub interfejs Javy udekorowany przez adnotację @Remotable. Przekazywanie parametrów odbywa się przez wartość.
Lokalna usługa określona jest przez interfejs Javy nieudekorowany przez adnotację @Remotable. Przekazywanie parametrów odbywa się przez referencję (w sensie programowania w Javie nie SCA).
Referencja (ang. reference) reprezentuje usługę, która jest wykorzystywana przez implementację podczas realizacji własnych funkcjonalności biznesowych. Referencje są określane przez interfejsy.
Implementacja (ang. implementation) określa technologię informatyczną służącą do dostarczania realizacji usług, np. klasa Javy, proces BPEL, transformata XSLT, klasa C++. SCAlenie przedstawia również implementację.
Interfejs (ang. interface) definiuje funkcje biznesowe dostarczane przez usługi. Interfejs jest wykorzystywany przez komponenty za pomocą referencji. SCA wspiera dwa typy interfejsów: interfejsy w Javie oraz portType w WSDL.
Istnieją interfejsy dwukierunkowe (ang. bi-directional), które posiadają funkcje, które muszą być dostarczane przez obie strony komunikacji, które można wykorzystać do modelowania komunikacji zwrotnej (ang. callback).
SCAlenie (ang. composite) - podstawowa jednostka konstrukcji w SCA. SCAlenie jest bytem złożonym z komponentów, usług, referencji i łączeń. Za ich pomocą dostarczane są przekazania do domeny SCA.
Włączenie (ang. composite inclusion) - część definicji SCAlenia oparta o pewne inne SCAlenie. Włączenie następuje tekstowo.
Właściwość (ang. property) umożliwia konfigurację implementacji. Definiowane specyficzne do użytego typu implementacyjnego, np. adnotacji w Javie lub plik componentType.
Domena (ang. domain) jest zbiorem usług udostępniających funkcje biznesowe kontrolowane przez pojedyńczą organizację. W SCA domenę można traktować również jako SCAlenie, tj. domena udostępnia usługi i referencje oraz łącza, które je spajają.
Łącze (ang. wire) łączy referencje z usługami. Poprawnymi źródłami łączy w SCAleniu są referencje komponentu i usługi SCAlenia, podczas gdy odbiorcami mogą być usługi komponentu i referencje SCAleń. Odbiorcy mogą być zdalni w stosunku do domenu SCA.
Nie nudzę?! Raczej tak. Pora skończyć z SCA (ale tylko na chwilę zanim rozpoznam implementation.spring) i wrócić do lektury specyfikacji JPA, a później EJB. Tak zupełnie przy okazji - pojawiły się egzaminy JPA i EJB 3 - Basic na javaBLACKbelt. Kiedyś deklarowałem stworzenie ich, ale nie starczyło zapału i cieszę się, że pojawili się chętni (poprawiać kogoś jest o wiele prościej ;-)) Ciekawym Waszych wyników - ja jeszcze poczytam specyfikację zanim wystawię się na publiczną falę krytyki.
Brak komentarzy:
Prześlij komentarz