Przyszłość i ograniczenia usług sieciowych
Transkrypt
Przyszłość i ograniczenia usług sieciowych
IX Konferencja PLOUG Koœcielisko PaŸdziernik 2003 Przysz³oœæ i ograniczenia us³ug sieciowych prof. Czes³aw Jêdrzejek Instytut Technik Telekomunikacyjnych i Informatycznych Us³ugi sieciowe s¹ jednym z najpopularniejszych obecnie trendów w informatyce. Ich niezaprzeczalnymi zaletami s¹: l Standaryzacja: dostêpu, profili, procesów biznesowych. l Dostosowanie do modelu zorientowanego na us³ugi (Service Centric Model) przez co zwiêkszaj¹ siê mo¿liwoœci integracji i spada jej koszt. Spoœród kilkudziesiêciu standardów zwi¹zanych z us³ugami sieciowymi najwa¿niejsze to SOAP, WSDL, UDDI oraz WS-Security. UDDI i WS-Security oparte s¹ na pewnych za³o¿eniach biznesowych, które niekoniecznie musz¹ siê globalnie spe³niæ, bowiem zak³adaj¹ odejœcie od rynku pionowo zintegrowanego. Inne trudnoœci techniczne to skalowalnoœæ i pokonanie technicznych barier œrodowiska: wiele platform, sieci, podmiotów. Dlatego us³ugi sieciowe w skali masowej zaczn¹ siê liczyæ po roku 2005. W referacie skupiê siê na rzeczywistym stanie wdro¿eñ us³ug sieciowych i ilustracji zastosowañ us³ug sieciowych z wykorzystaniem jednej z ich najwa¿niejszych funkcjonalnoœci: negocjacji i mediacji (funkcja brokera). Zostanie przedstawiona aplikacyjno-sieciowa architektura projektu IST CADENUS w aspekcie skalowalnoœci. Niektóre aplikacje wymagaj¹ce przes³ania kilkudziesiêciu wiadomoœci bardzo trudno skaluj¹ siê na poziomie dynamicznych sesji przy zastosowaniu urz¹dzeñ i systemów obecnie wystêpuj¹cych na rynku. Informacja o autorze: Prof. dr hab. in¿. Czes³aw Jêdrzejek, w pocz¹tkowym okresie pracy zwi¹zany z AGH i UJ w Krakowie. Przez okres 10 lat odbywa³ sta¿e naukowe i pracowa³ jako Visiting Professor kolejno na kilku uczelniach w USA. W roku 1994 zwi¹za³ siê Francusko-Polsk¹ Wy¿sz¹ Szko³¹ Nowych Technik Informatyczno-Komunikacyjnych (EFP) w Poznaniu. Od paŸdziernika 1996 jest profesorem na Wydziale Telekomunikacji i Elektrotechniki Akademii Techniczno-Rolniczej w Bydgoszczy. Pracuje tak¿e w Instytucie Technik Telekomunikacyjnych i Informatycznych (ITTI) w Poznaniu, gdzie od 1999 roku zajmuje stanowisko Wiceprezesa Zarz¹du. Jest autorem lub wspó³autorem ponad 100 publikacji. Rozwin¹³ grupê software’ow¹ w ITTI (systemy informatyczne typu ERP i CRM dla przedsiêbiorstw, systemy zdalnego nauczania wraz z materia³ami). Kierowa³ kilkudziesiêcioma projektami dla wiod¹cych operatorów oraz dostawców sprzêtu telekomunikacyjnego w Polsce w zakresie ewolucji sieci i us³ug, in¿ynierii ruchu w sieciach teleinformatycznych oraz wykonania, integracji i wdro¿enia systemów informatycznych. Realizowa³ kilka projektów europejskich dotycz¹cych aplikacji informatycznych. Przyszłość i ograniczenia usług sieciowych 179 1. Wstęp Wytwarzanie aplikacji internetowych i sieciowych systemów informatycznych wymaga integracji produktów informatycznych na trzech poziomach: • komponentów, • warstwy pośredniej (ang.middleware), • aplikacji. Wzraz ze wzrostem funkcjonalnosci i złożoności sieciowych systemów informatycznych wzrasta koszt integracji. Na kongresie TMF w Nicei w roku 2002 podano, że w przypadku oprogramowania systemów telekomunikacyjnych koszt integracji wynosi 80% inwestycji. W dodatku cykle życia usług stają się porównywalne z czasem wdrożenia (głównie integracji). Ten fakt między innymi był i pozostaje powodem załamania w branży ICT1. Dlatego poszukiwane są nowe paradygmaty projektowanie i wytwarzanie systemów internetowych. Obecnie głównym trendem w tworzeniu i użytkowaniu komercyjnych aplikacji są usługi sieciowe2 (ang Web services3). „Usługi sieciowe (WS) są aplikacjami identyfikowanymi poprzez URI (Uniform Resource Identifier), których interfejsy i wiązania są zdefiniowane i rozpoznawane przy pomocy artefaktów XML”. Sprowadza się to do wysyłania i odbierania komunikatów używając zestandaryzowanych przez World Wide Web Consortium (W3C) formatów i mechanizmów. „Usługi sieciowe umożliwają bezpośrednie oddziaływanie komponentów, a komunikaty oparte są na protokołach internetowych”. Z perspektywy czasu przesłankami ogromnego zainteresowania i reklamy usług sieciowych były: 1. nadzieja na uniwersalną i globalną wzajemną komunikację, mimo istniejącej wcześniej niekompatybilności oprogramowania,. Istnieje wiele złożonych zagadnień biznesowych i technicznych, które zadecydują, która z tych opcji zostanie zrealizowana. Realizacja pozytywnego pierwszego scenariusza wymaga pokonania wielu barier. W artykule tym zajmę się analizą tych barier, bez zbytniego wchodzenia w szczegóły techniczne protokołów. 2. Architektura usług sieciowych Usługi sieciowe to samodzielne aplikacje oparte na komponentach, które mogą być opisane, opublikowane, zlokalizowane i wywołane w sieci internetowej (praktycznie szerokopasmowej) jak pokazano na rys. 1. 1 Information and Communication Technology rzadziej: serwisy sieciowe 3 „A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols.“ (W3C) 2 180 Czesław Jędrzejek Interakcje: Komunikacja: HTTP pu bli UD k a cj DI a XML Broker usług ie, łan e wo ani wy wią P po OA S Dane: Dostawca usług SOAP UDDI/WSDL Użytkownik wyszukanie Rys. 1. Cykl życia usługi sieciowej z architekturą protokołów Uruchomienie usługi sieciowej obejmuje utworzenie usługi oraz zdefiniowanie interfejsów i metod jej wywołania, a jej działanie wymaga co najmniej: • opublikowanie usługi w internetowym lub intranetowych katalogach (ang. Serwis directory) należących do brokera usług, • stworzenie możliwości odnalezienia jej przez potencjalnych odbiorców – klientów (ang. User), • zdalne wywołanie serwera dostawcy przez klienta. Nie będę się zajmował szczegółami protokołów ani działania wartwy pośredniej (ang. middleware) [1]. Wymiana komunikatów została przedstawiona na Rys. 2 181 Przyszłość i ograniczenia usług sieciowych Znajdź usługę http://www.uddi.org UDDI Link do dokumentu katalogu usług Broker (discovery) Klient usługi sieciowej http://yourservice.com HTML z linkiem do WSDL Jak się porozumiewamy (WSDL) http://yourservice.com/?WSDL Specyfikacja usługi (XML) Usługa sieciowa SOAP Zamawiam http://yourservice.com/svc1 Potwierdzam zamówienie (XML) Rys. 2. Wymiana komunikatów w najprostszej wersji komunikacji w ramach usługi sieciowej Aby zapewnić współdziałanie, usługi sieciowe wykorzystują uzgodnione standardy struktury danych (XML), przesyłania komunikatów (SOAP), wyszukiwania usług (UDDI) i opisy interfejsów (WSDL)4. Komunikaty SOAP w postaci tekstowej są przesyłane za pomocą standardowego protokołu internetowego HTTP. Załączniki są binarne lub w postaci wywołań RPC. Dzięki temu można przejąć większość rozwiązań internetowych. Teoretycznie, aby zapewnić działanie usług sieciowych nie trzeba zmieniać środowiska (Tabela 1) np. narzędzi bezpieczeństwa w postaci ścian ogniowych, ale w praktyce bardzo rozbudowana funkcjonalność spowodowała koniecznośc uzupełnienia podstawowych protokołów o kilkadziesiąt nowych specyfikacji . Usługa sieciowa po odebraniu żądania wykonania interpretuje je i wywołuje odpowiednią, zaimplementowaną metodę po stronie aplikacji biznesowej (w teoretycznie dowolnym języku oprogramowania, o ile istnieje odpowiedni interfejs jak to pokazano w Tabeli 1). W praktyce, jeśli chcemy wzbogacić usługi sieciowe o dodatkowe funkcjonalności nie jest to już tak proste. Np. Microsoft używa usług sieciowych do osiągnięcia przewagi konkurencyjnej platformy .Net. Tabela 1. Technologie związane z usługami sieciowymi 4 Funkcjonalność Technologia implementacja usługi teoretycznie dowolna użycie usługi teoretycznie dowolna opis usługi na poziomie interfejsów WSDL XML (Extensible Markup Language) SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) WSDL (Web Services Description Language), odpowiednik IDL w platformie Corba. 182 Czesław Jędrzejek Funkcjonalność Technologia wyszukiwanie usług UDDI przekazywanie komunikatów SOAP 3. Dodatkowe funkcjonalności Usługi sieciowe powstały z zapotrzebowania biznesowego w wyniku coraz szybszego tempa tworzenia usług i koniecznosci tworzenia złożonych łańcuchów wartości. W efekcie podstawowy model WS jest trakcie wzbogacania o kilkadziesiąt dodatkowych specyfikacji (Rys. 3) rozszerzajacych podstawowe funkcjonalności techniczne (tzn. protokoły SOAP, UDDI, WDSL), ale też specyfikujących interfejsy do inteligencji biznesowej i transakcji typu B2B i B2C5. Stos protokołów ulega wzbogaceniu. Tworzeniem bardziej złożonych protokołów zajmuje się kilka organizacji często ze sobą konkurujących [2]. Zupełnie nowe są nastepujace złożone procesy: • Choreografia (ang. Choreography) – definicja sekwencji i zależności dla interakcji pomiędzy podmiotami o określonych rolach w realizacji łańcucha wartości (Collaborative Process). • Orkiestracja (ang. Orchestration) - definicja sekwencji i zależności dla procesów realizujących jedną rolę, w szczególności realizacja wzajemnych powiązań • Konwersacja (ang. Conversation ) - instancja choreografii lub orkiestracji • Relacje zaufania (trust relationship) - ochrona danych i zachowanie poufności informacji elektronicznej dotyczącej podmiotów za pośrednictwem rozwiązań proceduralnych wspieranych przez technologie. Jedno z takich rozwiązań, Infrastruktura Klucza Publicznego, nie uzyskało akceptacji rynkowej. • Rozproszenie (ang. federation) - rozproszenie procesów i komponentów, tak aby uniknąć systuacji, kiedy awaria pojedynczego elementu (point of a single failure) powoduje awarię systemu. Standardy WS-Security i W-Trust (Rys. 4) realizują model bezpieczeństwa oparty na przydzielaniu tokenów i modelu zaufania w myśl zasady: „każdemu według jego potrzeb, od każdego według jego możliwości”6. 5 Aktualny stan prac dotyczacych standardów lub ich draftów znajduje się na www.webservices.org/ index.php/standards 6 Jak wiadomo ten teoretyczny model pochodzący od Marksa nie znalazł pozytywnej implementacji w zakresie działania społeczeństw (co raczej nie zachęca do optymizmu) 183 Przyszłość i ograniczenia usług sieciowych Message Encapsulation Inspection Federation Coordination Routing Trust Policy Other Web Services WS-Security WebSOAP Services SOAP SOAP Transport Layer (HTTP) Transport (HTTP) Rys. 3. Stos protokołów realizujących rozbudowane funkcjonalności usług sieciowych Sender Receiver Trust Engine Trust Engine Security Token Service Rys. 4. Uproszczona zasada działania zaufanej transmisji w oparciu o Trust Engine i Secure Token Service Do tej pory rozpatrywano uproszczone relacje biznesowe. W rzeczywistości użytkownik, który chce skorzystać z usługi sieciowej musi wejść do sieci poprzez operatora dostępu (ISP), a usługa np. na portalu musi skorzystać z transportu dostarczanego przez operatora telekomunikacyjnego (Resource Mediator). Funkcje te zostały przedstawione na Rys. 5-8. W tym pzrypadku broker to Access Mediator i Service Directory. Dostawca to Service Mediator. Nowym elementami w porównaniu z Rys. 1 to negocjacja oferty i komunikacja specyfikacji SLA (Service Level Agreement). Dlatego liczba wiadomości rośnie (także dlatego, że występuje 5 podmiotów). 184 Czesław Jędrzejek Access Mediator User 1 Wybór usługi e ni gę ta M py S słu Za listę h u 2 o cyc gę ą słu uj er M ch u S of y ta ąc Lis uj 3 ofer Service Directory Service Mediators Resource Mediators Sieć z QoS-capable funkcjonalnością Networks QoS Rys. 5. Scenariusz – Negocjacje usługi (kroki 1-3) User 7Szablon SLA 8Wypełniony Service Directory Access Mediator o informac je pytanie 4 Za egółow e o usłudze szcz szczeg łudze ółow e o us rmacje 5 Info Zapytanie o inf ormacje 4 szczeg ółowe o usłudze 5 Informacje szc zeg szablon SLA ółowe o usłudze 6 Budowa szablonu SLA Resource Mediators QoS-capable Sieć z Networks funkcjonalnością QoS Rys. 6. Scenariusz – Negocjacje usługi (kroki 4-8) Service Mediators 185 Przyszłość i ograniczenia usług sieciowych Access Mediator User Service Directory 9 us e o koszt Zapytani 10 Informacja o ługi ługi koszcie us Service Mediators 9 Zapytanie o koszt usługi 10 Informacja o koszcie usług i 11Obliczenie funkcji kosztu 12 Sortowanie według kosztu Resource Mediators Sieć z QoS-capable funkcjonalnością Networks QoS Rys. 7. Scenariusz – Negocjacje usługi (kroki 9-12) User Lista 14 proponowanych SLA Service Directory Access Mediator 15 Wybrane SLA 13 Budowa SLA 16 Wiadomo[ 16 Wiadomo[ rollback Service Mediators commit 17Zachowanie Nowe SLA Resource Mediators QoS-capable Sie z funkcjonalno[ Networks ci QoS Rys. 8. Scenariusz – Negocjacje usługi (kroki 13-17) 4. Problemy we wdrożeniu usług sieciowych Problemy we wdrożeniu usług sieciowych mogą być natury biznesowej lub technicznej. Istnieje ogromna literatura na ten temat. W świecie zdominowanym przez małą liczbę podmiotów idea równych praw nie będzie realizowana. Publiczne katalogi UDDI prowadzą m.in. IBM, Microsoft i SAP. Każdy chciałby być brokerem (tak jak każdy operator ISP zmierza do przyciagnięcia klientów do swojego portalu). Najsilniejsze podmioty na rynku np. telekomunikacyjnym mogą starać się zrealizować cały łańcuch wartości (ale np. postawa British Telecom jest inna). Globalni dostawcy oprogramowania (głównie Microsoft i IBM) starają się zwiekszać pozycję na rynku poprzez korzystne dla siebie rozwiązania w WS-X (X rozszerzone funkcjonalności, a przykładem może być uniwersalny profil użytkownika, dostep do aplikacji z pojedynczym uwierzytelnieniem, 186 Czesław Jędrzejek etc.). Może dojść do, że w teorii otwarte usługi zostaną związane z jedną platformą. Załamuje się wtedy cały model opierający się na fakcie, że usługi sieciowe nie stanowiaąsamodzielnie implementacji usług. Powinny być warstwą, pozwalającą wywołać zdalną usługę bez znajomości szczegółów implementacyjnych. Eksponują tylko warstwę biznesową, udostępniając publiczne API dla współpracujących serwisów. W aspekcie technicznym dzielę problemy implementacji WS na trzy klasy zagadnień: skalowalnośc, integracja, oraz model przetwarzania transakcyjnego. Skalowalność Ponieważ komunikacja odbywa się w trybie tekstowym cena za otwartość jest szybkość przetwarzania jest mniejsza wydajność. Typowy wynik przedstawiono na Rys. 9. J2EE Throughput 4000 J2EE SQL Tx 3500 J2EE DTC1 J2EE DTC2 3000 J2EE SOAP TPS 2500 2000 1500 1000 500 0 0 100 200 300 400 500 600 700 800 Client threads Rys. 9. Porównanie wydajnosci przetwarzania platformy J2EE z SOAP i binarmymi protokołami [3] Pojawiają się też duże problemy ze skalowalnością na poziomie liczby wiadomości sygnalizacyjnych. Dla scenariusza przedstawionego na Rys. 10 (realizacja aplikacyjno-sieciowa architektury projektu IST CADENUS) mamy do czynienia z 22 wiadomościami. Takie aplikacje wymagające przesłania kilkudziesięciu wiadomości bardzo trudno skalują się na poziomie dynamicznych sesji przy zastosowaniu urządzeń i systemów obecnie występujących na rynku. Nie się obecnie zrealizować masowych usług VoIP z negocjacją na poziomie sesji [4]. Przyszłość i ograniczenia usług sieciowych 187 Expected # Name servicetime Involved tasks (msec) 1 NegotiateNewSla 50 User authentication 2 GetAvailableServices 50 Execution of a query in a DB 3 RGetAvailableServices 50 Preparation of the answer to the user 4 ShowServiceList 5 SelectService 50 Preparation of the request to the service directory 6 GetServiceDetails 50 Execution of a query in a DB 7 RGetServiceDetails 50 Preparation of the GUI to be sent to the user 8 SendServiceGui 9 ServiceRequest 50 Storing of the user’s request and preparation of the associated request to the Service Directory 10 GetSMs 50 Execution of a query in a DB 11 RGetSMs 50 Preparation of the requests to the involved SMs 12 RequestServiceAvailability 50 Preparation of the answer to the AM 13 RRequestServiceAvailability 50 Preparation of the request to the SM for a quotation 14 RequestForQuotation 1500 SLA→SLS translation 15 SlsQuotation 1000 SLS Splitting 16 NextHopSlsQuotation 1000 SLS Splitting 17 TimeSliceQuotation 2000 Execution of a time-independent Admission Control for a single autonomous system 18 RTimeSliceQuotation 100 Collection of the responses for each time slice and selection of the best offer 19 RNextHopSlsQuotation 100 Preparation of the overall offer related to the provisioning of the service specified inside the SLS 20 RSlsQuotation 50 Preparation of the overall offer related to the provisioning of the service requested by the user. 21 RRequestForQuotation 100 Collection of the offers from the involved SMs and merging of such offers into the SLA to be subscribed by the user 22 RServiceRequest Rys. 10. Wiadomości aplikacyjno-sieciowej architektury projektu IST CADENUS z podanymi czasami wykonania 188 Czesław Jędrzejek Integracja Usługi sieciowe miały być panaceum na problemy z integracją. Niewątpliwie jest to krok w dobrym kierunku, pod warunkiem, że w średnim okresie czasu (np. 5 lat) WS jako technologia zdominuje platformy warstw pośrednich. Rzeczywiście WS usuwaja pewne wady np. platformy Corba (zbytnia sztywność komponentw, trudna obsługa zdarzeń). Jednak np. w systemach zarządzania w telekomunikacji, gdzie dominuje Corba i J2EE, nie należy się spodziewać dramatycznych zmian (np. eleminacji starszych platform) w tym okresie.Oznacza to wg autora, że WS będą funkcjonawać jako wyspa w świecie innych platform. Tymczasem konkurujące organizacje standaryzacyjne nie mogą się czasami porozumieć, czego przykładem standard Liberty Alliance vs WS-Federation . W dodatku praktyka integracji jest taka, że do istniejących interfejsów IDL, czy klas Javy dorabia się definicje WSDL. Zbyt to przypomina wdrażanie IPv6. O fakcie, że problem jest widoczny świadczy powstanie w luym 2002 roku organizacji WS-I (Web Services Interoperability - www.ws-i.org) – grupującej producentów oprogramowania i nastawionej na wspieranie niezależności WS od platform, systemów operacyjnych i języków programowania. Tzw. Basic Profile 1.0 został zatwierdzony w sierpniu 2003 r. Model przetwarzania transakcyjnego. Systemy wielodostępowe umożliwiają, jednoczesne przetwarzanie wielu transakcji (np. systemy rezerwacji miejsc, systemy bankowe, etc.). W systemach SZBD poprawność i kompletność realizacji operacji gwarantuje moduł zarządzania transakcjami opierający się na modelu ACID Cztery zasady ACID (związane z blokadą dostępu do pewnych elementów bazy danych podczas realizacji transakcji) to: 1. Niepodzielność (Atomicity): Wykonywana jest albo cała transakcja od początku do końca, 2. Spójność (Consistency), 3. Izolacja (Isolation), 4. Trwałość (Durability). Dla transakcji B2B zamodelowanych np. w ramach BPEL4WS (warstwa leżąca ponad WSTransaction i WS-Coordination) nie da się utrzymać własności niepodzielności (oraz całego modelu ATM, Advanced Transaction Model). Zamiast milisekund transakcje trwają o wiele dłużej. Muszą one przejś przez urządzenia sieciowe (np. routery usługowe), których opóźnienie może wynosić nawet 10 ms. A oprócz tego jednoprocesorowe routery generalnie mogą np. wykonywac tylko kilka transakcji AAA na sekundę [5]. Jest to bardzo poważny problem, jeśli usługa ma posiadać gwarantowaną jakość [6]. Standard WS-Transaction [7] wprowadza oprócz pojęcia Atomic Transaction pojęcie procesu biznesowego (business activity). Ten drugi proces zajmuje się obsługą wyjątków. Ale w świecie awarii i nieuczciwych partnerów liczba wyjątków (błędnych procesów) może gwałtownie rosnąć. Ma to szczególne znaczenie dla zarządzania autoryzacją i proponuje się metody usprawniające ten proces, jak: single sign-on. Przyszłość i ograniczenia usług sieciowych 189 5. Podsumowanie Usługi sieciowe są jednymi z najpopularniejszych, ale i w obecnej chwili najbardziej przereklamowanych trendów w informatyce. Ich niezaprzeczalnymi zaletami są: 1. standaryzacja: dostępu, profili, procesów biznesowych, 2. dostosowanie do modelu zorientowanego na usługi (Service Centric Model), przez co zwiększają się możliwości integracji i spada jej koszt. Niestety obecnie usługi sieciowe są wdrażane głównie w dużych globalnych firmach i ich sieci partnerów (wewnętrzne markety elektroniczne), a komunikacja generalnie ma charakter punktpunkt. Techniczne założenia kilkudziesięsiu standardów związanych z usługami sieciowymi oparte są na pewnych przesłankach biznesowych, które niekoniecznie muszą się globalnie spełnić, bowiem zakładają odejście od rynku pionowo zintegrowanego. Inne trudności techniczne to skalowalność i pokonanie technicznych barier środowiska: wiele platform, sieci, podmiotów. Dlatego usługi sieciowe w skali masowej zaczną się liczyć po roku 2005. 6. Bibliografia [1] np. seria artykułów czasopisma Oracle'owego PLOUG, Sebastian Wyrwał „Projektowanie i wytwarzanie aplikacji internetowych” [2] World Wide Web Consorcium - www.w3.org ; Organization for the Advancement of Structured Information Standards, OASIS - www.oasis-open.org; Liberty Alliance www.projectliberty.org; integracją zajmuje się OMG - www.omg.org [3] Paul Greenfield, prezentacja Web Services (and .NET) April 2003; podobne wyniki zostały uzyskane przez M. Litoiu, “Migrating to Web Services, Latency and Scalability,” IEEE Workshop on Web Site Evolution (WSE 2002), Montreal, Canada, October 2002 [4] Raport końcowy projektu IST Cadenus, wrzesień 2003 [5] Testy Network World Global Test Alliance, “ Filters on routers: The price of performance”, Network World, 07/14/03http://www.nwfusion.com/reviews/2003/0714rev.html [6] A. Flizikowski, C. Jędrzejek, A model of a software router, to be published [7] Dean Kuo, Alan Fekete, Paul Greenfield, Julian Jang and Doug Palmer, “ Just What Could Possibly Go Wrong In B2B Integration? „. Workshop on Architectures for Complex Application Integration(WACAI'03 - to appear), November 2003, Dallas, USA.