Temat: Usługa a wymagania operatora

Witam,

mam pewną wątpliwość dotyczącą testowania aplikacji sprzężonych z zewnętrznymi interfejsami (REST).

Otóż powiedzmy, że chcę opracować pewną usługę wykorzystując interfejsy API platformy Telco 2.0 (czyli interfejsy telekomunikacyjneg) np:. Location API oraz SMS API.

A teraz proszę doradźcie mi, jakie parametry/cechy powinna spełniać/posiadać owa gotowa usługa, które są cenne/pożądane przez operatora telekomunikacyjnego (uwzględniając jego specyfikę oczywisćie) ?

Myślałem, czy nie iść w stronę zbadania w usłudze (jednak troche chyba mija się to z celem, gdyż musi być większe powiązanie z operatorem i jego platformą Telco 2.0 udostępniającą interfejsy) np:. "komutacji" oraz przetwarzania zapytań, wydajności, skalowalności (załóżmy, że do usługi ma dostęp parę mln abonentów sieci komórkowej), może bezpieczeństwa ?

Czy przeprowadzić testy aplikacji wykorzystującej dane interfejsy telekomunikacyjne takie jak :
- jaka teoretyczna powinna być wydajność platformy operatora (teoretyczna, bo takich testów przeprowadzić nie mogę), aby móc obsłużyć RESTowe zapytania usługi ?
- opisać testy funkcjami - opóźnienie serwisu, generowany ruch po stronie SMS/Location API w funkcji od ilości użytkowników aplikacji
- inne ?

Bardzo prosiłbym o pomoc ;) Jeżeli istnieje literatura do tego przypadku, czyli metodologi/schematów testowania aplikacji dla sektora telekomunikacyjnego bardzo prosiłbym o nakierowanie ;)
Pytanie dodatkowe - co to znaczy testować w usłudze parametry CAPS oraz TUPS ? (niestety nie mogłem tego znaleźć)

Pzdr,
ŁukaszŁukasz Cieśluk edytował(a) ten post dnia 16.04.12 o godzinie 13:40

Temat: Usługa a wymagania operatora

Rozumiem, ze to Telco2.0 to nie jest platforma z krwi i kosci (czy raczej z hardwaru i softwaru ;-) ), tylko taki biznesowy model (z propozycja API)? Na czyms musialbys to zaimplementowac?

To co operator potrzebuje to informacje:
* taka funkcjonalnosc realizowana,
*taki hardware, taki software,
* tyle "call attempts per second" (to te CAPS o ktore pytasz na koncu swojego postu) i taki load na procesorach z tym zwiazany.

To oczywiscie podstawowe info, bo on chce wiedziec milion roznych rzeczy: np. kwestie provisioningu (czyli jak ladowac dane dla pojedynczych userow i jak dla tysiecy na raz), kwestie backupow, load balancingu, redundancji, administracji, zapewnienia niezawodnosci uslugi, odpowiedniego czasu reagowania na bledy, supportu, kwestie upgradow, integracji z innymi elemntami sieciowymi.
Do tego chcialby widziec dokladne testy: robustness, overload, itp.

Jesli chcesz zaproponowac kompletna usluge operatorowi , ktora bedzie wykorzystywana przez "parę mln abonentów sieci komórkowej", to mozesz byc pewny, ze te rzeczy wspomniane powyzej go zainteresuja.

Temat: Usługa a wymagania operatora

Witam,

słowem wstępu, Telco 2.0 to koncepcja otworzenia sieci operatorów telekomunikacyjnych (z walled garden do open garden (zapewne wiesz o czym mowa ;)) i udostępnienia funkcjonalności sieci telekomunikacyjnej na zewnątrz w postaci interfejsów (API, w postaci SOAP i REST, ale bardziej REST), z wykorzystaniem których można budować własne aplikacje (bardziej w paradygmacie Web 2.0). Czyli Telco 2.0 to taki model biznesowy, który od strony technicznej realizowany jest przez owe interfejsy. Wcześniej były Parlay/OSA, JAIN i inne, teraz jest/będzie Telco 2.0 z REST'owymi interfejsami.

Dokładnie technologi, w której musiałbym to zaimplementować nie mam narzuconej. Bardziej myślałem o technologiach bardziej związanych z IT niż telekomunikacją np:. back-end framework Spring (moduły Spring Mobile, Data (MongoDB), Security, WebFlow, Batch), od front-endu jQuery Mobile i do tego owe interfejsy Telco 2.0 w back-endzie.

De facto nie chcem nastawiać się na klientów natywnych Androida czy iPhona, ale wolałbym użyć jQuery Mobile, który będzie wyglądał/działał podobnie na wszystkich urządzeniach mobilnych. Dla zwykłych przeglądarek standardowy jQuery. Jeżeli zły wybór prosiłbym o korektę ;)

Bardzo dziękuje za owe milion rzeczy, które wypisałeś ! ;)

W grę wchodzi jedynie software (pomijam hardware). Backup również pomijam, upgrade, support oraz administrację raczej też. Bardziej zależy mi na podejściu czysto technicznej niż całościowo biznesowej ;)
Dochodzę również do wniosku, że testy/badania związane z usługą od strony kodu również pomijam...(redundacja się w to wpisuje?)

Myślałem również o tym (chociaż dopiero dziś przekopuje literaturę), czy da się zastosować jakieś metryki dotyczące tworzenia usług mających pochodzenie w telekomunikacji (RM-ODP/MDA ? - nie znam się) i zastosować je, nieco może nawet na siłę w testowaniu usługi.

Oczywiście testy robustness, overload, stress, caps/tups etc i może ciekawe podejście typu provisioning, integracja z innymi elementami sieciowymi (btw. jak to zbadać :>), ale ujmę to tak, że brakuje mi jakiegoś nowatorskiego podejścia, nie krojonego na siłę, ale takiego przeniesionego z świata telecomów do it ;)

Sprawdzać SLA, czyli określenie/sprawdzenie pomiędzy klientem usługi, a jego dostawcą ?

Marcinie, a jakąś literaturę byś mógł polecić ?

Pzdr,
ŁukaszŁukasz Cieśluk edytował(a) ten post dnia 16.04.12 o godzinie 21:03

Temat: Usługa a wymagania operatora

Literatury na ten temat nie znam, wiec tu Ci nie pomoge.

Ale mam kilka uwag natury ogolnej ;-)
1)Pamietam zamieszanie w branzy jak Parlay byl modny. Ojej, co to mialo byc. Nie mialo juz byc wojen, glodu ani chlodu. Wszystko mialo byc piekne i latwe i mialo to sie skonczyc ekplozja uslug dodanych i totalna zmiana na runku IT. Nie zostala po tym konsorcjum nawet strona WWW, a w najlepszych czasach wspierane bylo przez Ericssona, NSN, Motorole, Oracle, Telcordie, IBM, BEA i wielu operatorow i wiele innych firm z branzy. Takie koncepcje pojawiaja sie co jakis czas, nie nalezy sie do nich za bradzo przyzwyczajac jako do nowego pardygmatu w branzy.
2)Troche Parlayowych implementacji w zyciu widzialem, wszystkie byly stworzone jednak w obrebie sieci operatorow, oni maja jakas taka naturalna niechcec do udostepniania swoich zasobow firmom trzecim. Kocepcja "open garden" byla wtedy bardzo mocno promowana, ale ostatecznie wszystkie te aplikacje byly implementowane jako uslugi oferowane przez operatora. I juz.
3)Operator nie kupuje softwaru, ktory moze sobie "zainstalowac na serwerze", tylko Gotowe Rozwiazanie, ktore nalezy zintegrowac z jego siecia i ktore bedzie dzialac. Wszystkie kwestie, ktore poruszylem we wczesniejszym poscie (no i wiele innych) sa wazne i niezbedne w ofercie (gdy mowimy o ofercie ktora ma byc podstawa dla oferowania uslug dla tysiecy(milionow?) uzytkownikow.

Na stronie glownej zwiaznae z tym Telco 2.0 jest cos takiego: "What is the Telco 2.0™ Initiative?" "Telco 2.0™ is a collection of research, brainstorming andconsulting services designed to catalyse change in the Telecoms-Media-Technology sector." Troche to takie lanie wody. Nie moge tam znalezc informacji o API, o konkretnych implementacjach Gaetewayow po stronie operatora, by te API oferowaly itp. Masz link do tego? Mam takie niejasne wrazenie, ze to wszystko jest na razie oferowane w formie "slidewaru" ;-)

Temat: Usługa a wymagania operatora

Witam,

Odnośnie opinii związanej z Parlay'em w pełni się zgadzam ;) Ale podałem go jako przykład (że również pozwalał na dostęp do funkcjonalności sieci, ale bardziej w obrębie sieci).

Otóż potrzebuję (mówiąc szczerze do magisterki :D) tak jak wcześniej napisałem obmyślić jakieś nowe, może nieco na siłę lub nowatorskie podejście w testowaniu usługi, która wykorzystuje funkcjonalności sieci komórkowej. Dlatego nie skupiam się póki co na szerokim spectrum ujęcia usługi dla operatora. Interesuje mnie strona techniczna, powiązanie softu z telecomem.

Póki co obmyśliłem (bardzo prosiłbym o korektę), że może elementy badania jakości usługi QoS, która de facto określa charakterystyki jakości dla usługi telekomunikacyjnej 'zapożyczyć' i uzupełniając o jakieś metody testowania ze świata IT, opracować metodologię (taką własną/nowatorską albo już istniejąca), która wykorzystywałaby trochę podejść ze świata telekomunikacji oraz it w testowaniu usług. Wiem wiem, pokręcone ;p

Może podejście uzupełnić o np:. Service Level Agreement (SLA) ... niestety mało się na tym znam.

To co znalazłeś odnośnie Telco 2.0 to opracowania firmy konsultingowej STL Partners mające na celu ujęcie biznesowej strony. Bardziej chodzi o :
- http://www.tu.rd.tp.pl/portal/index.php?option=com_con...
- http://www.tu.rd.tp.pl/portal/index.php?option=com_con...

Pozdrawiam,
Łukasz

Temat: Usługa a wymagania operatora

Witam,

ostatnio znalazłem ciekawą koncepcję, która mogłaby znaleźć zastosowanie do testowania aplikacji/usług zbudowanych powiedzmy w środowisku Web 2.0. Otóż chodzi mi o lifecycle testowania usług telekomunikacyjnych bazujących na NGOSS. Znalazłem, że opiera się on na 4 widokach - Business, System/Architecture, Implementation oraz Deployment. Dwa środkowe odnoszą się do testowania aplikacji dostarczanych przez developera tzn. unit test, integration, quality and performance, sanity, regression, load testing. Gdyby 'zapożyczyć' założenia NGOSS i podeprzeć założeniami jakości usług QoS, to może byłoby to nowatorskie podejście do testowania aplikacji webowych z zastosowaniem metodologi (jeżeli chodzi o standard) ze świata telekomunikacyjnego ?

Pozdrawiam,
Łukasz

Temat: Usługa a wymagania operatora

Glowna idea przyswiecajaca temu Telco2.0 jest taka, zeby te aplikacje pracowaly jako zwykle aplikacje IT, ktorych nie obchodzi co jest "po drugiej stronie", wiec niejako z definicji nie potrzeba specjalnych (innych niz obecnie w IT) sposobow testowania do nich.
Koniecznie chcesz wykorzystac "nowatorskie podejście do testowania aplikacji webowych z zastosowaniem metodologi (jeżeli chodzi o standard) ze świata telekomunikacyjnego" - to chyba niedobry pomysl w tym kontekscie.

No jedyny punkt zaczepienia to konkretna implementacja tego "Telco Gatewaya" ktora jest u operatora "brama" pomiedzy jego infrastruktura a siecia zewnetrzna. Tam sie ustawia te "Service Level Agreement" czyli pewne ograniczenia dotyczace aplikacji IT, ktora chce korzystac z infrastruktury operatora (np. jakie funkcje API moze uzywac (moze nawet byc zastrzezony zakres wartosci parametrow w tych funkcjach), ile "Call Atempt Per Second" moze robic itp.). Te SLA ustawia sie dla konkretnej aplikacji dzialajacej w domenie IT. Testowanie czy wszystkie "Agreementy" sa spelnione, to jedyny taki "telekomunikacyjny element".

Np. Twoja plikacja ma ustawione, ze mozesz wykonac 5 requestow do infrastruktury operatora na sekunde. Uzytkownicy Twojej aplikacji generuja ruch 8 requestow per second. W rzeczywistosci czesc z tych requestow bedzie odrzucana przez Telco Gateway. Jak zachowa sie aplikacja (wraz hostujacym ja srodowiskiem)?
To miejsce dla "telekomunikacyjnych testow". Inna sprawa, zemusisz miec jakas koncepcje zeby wiedziec czego oczekujesz od tego przypadku, takaby test mogl dac jasna odpowiedz - dobrze sie zachowuje system, czy zle.