MS vs GG

Oferta Microsoft  - MS Office Live Essential - produkt beta za darmo (potem 30$/mc)

Oferta Google -Google Apps 4 Domain - wersja basic beta za darmo (pod koniec roku będzie wersja premium - rozszerzona ale płatna)

Porównanie możliwości w Cnet.

Próbka tego jest poniżej:

Microsoft Office Live Basics beta
Google Apps for Your Domain

Compatibility
Internet Explorer 5.5; Windows 2000 /Internet Explorer 5.5, Firefox, Safari, Netscape 7.1; Windows, Mac, Linux

Domain name registration
Free /No

Web site storage space
30MB, 10MB bandwidth free, unlimited number of pages / 100MB through Google Page Creator

Web site traffic analysis
Yes / No

E-mail
Office Live Mail, 5 e-mail accounts, with 2GB of storage each / Multiple accounts through Gmail, with 2.8 GB of storage each

Chat
No / Google Talk

Calendar
Not included with Basics; available with paid Office Live Essentials or Collaboration / Google Calendar

Web page design
Built-in Site Designer with thousands of customizable, industry-specific templates / Google Page Creator

Privacy and Security
Privacy policy; must enable cookies / Privacy policies of each app; must enable cookies

Customer support
E-mail / Searchable knowledge base, forums

Paid versions
20 business applications and 24-hour phone support with Office Live Essentials or Collaboration; $29.95 and up per month after beta / No

Mydełko czyli SOAP

Co guru Leyman sądzi o wyborze nośnika WS: "REST is a possible style to implement a SOA. Especially if your application deals with large messages, or will benefit from caching, or has to render results immediately to end users, etc then a REST-based SOA does make a lot of sense. If you need to expose application specific interfaces, if you need message security along a message path with varying transport protocols, if you need choreography etc etc the WSDL/SOAP/... based SOA is preferable." Profesor Frank Leyman opublikował nawet mapę drogową dla SOAP.

Inny badacz Mark Baker jest znanym człowiekiem skłaniającym się jednak ku REST (REpresentational State Transfer) krytykujący wprowadzanie do WS standardów ignorujących potrzeby usług i niepotrzebnie komplikujacych ich implementację. Wywodzi się on z obozu DCE i Corba. Twórcą i pionierem tej technologii jest Roy Fielding który jest współzałożycielem protokołu HTTP 1.1 (udostępnia swoje interfejsy poprzez raz zdefiniowane i zafiksowane na stałe metody GET i POST, podobne ale bardziej rozwiniete idee są w REST. W SOAP jest to bardziej eleastyczne, opis interfejsu jest zawarty w WSDL) i autorem definicji REST. Co daje stały interfejs do usług?

Trzy zalety: prostota (liczba punktów swobody jest niewielka), skalowalność i niezawodność.

Każdy protokół wymiany powinien mieć cztery właściwości (wg. pracy dysertacyjnej Fielding) zapewniających:

1. Identyfikację zasobu ->URI
2. Działanie na zasobach ->GET, PUT, POST, DELETE
3. Samopisywalność komunikatów
4. Hypermedia jako transport stanu semantycznego

Więcej na ten temat: RESTwiki z resources section + tutorial

WS i bezpieczeństwo

To może być mojej początek przygody z WSE:

Źródło: theserverside.net (jest jeszcze wersja dla J2EE).

Tytuł:  "Using Role Based Security with WSE 2.0 Article Released"

Autor: Paul Ballard (styczeń 18, 2005 DIGG)

The MSDN Web Services Development Center has released a new article by Ingo Rammer on using role based security in WSE 2.0. The article starts by showing how to use X.509 certificates to digitally sign messages. He then builds on this to create a custom SecurityTokenManager to map certificates to users and roles.

Using HTTP to authenticate your Web services requests might seem like a great idea in the beginning, but as soon as WS-Routing enters the game, the situation changes substantially: There is no direct HTTP connection between the sender and the ultimate recipient of the message anymore, but a potentially larger number different protocols which could be used along the routing path. This renders any means of transport-level security as a purely optional add-on that cannot guarantee the end-to-end integrity and security of your messages.

Starting with programmatically adding a X.509 certificate to a WSE message, the article shows how to digitally sign a message as coming from a specific client. The article then shows how to accomplish the same task using client policy and the WSE 2.0 configuration tool.
Once the message has been signed, a mapping needs to be created on the server to identify clients with specific roles. This is done by creating a mapping file and supporting classes and then implementing a custom SecurityTokenManager. The SecurityTokenManager validates the certificate and then uses the mapping to return a custom IPrincipal with the roles set based on the mapping. Then in the web service code, you can use declarative and imperative security demands to allow role based access.
The article ends by showing all of the various settings that need to be configured to add the custom SecurityTokenManager to the WSE pipeline. Niestety link do MSDN nie działa.

Dlatego przeszukałem MSDN Library na ciąg znaków: "role based security WSE" i znalazłem tam mnóstwo artykułów.

Zarządzanie tożsamością

Coraz więcej mówi się o zarządzaniu tożsamością. Jest wiele projektów. Jednym z nich jest OpenID. W ramach tego projektu firma Verisign wprowadziła możliwość poświadczenia swojej tożsamości poprzez PIP (personal Identity Management).

Inne pomysły

Co można zaoferować naszym klientom? Można i to wiele za niewielkie pieniądze. Oczywiście nie będą to aplikacje klasy MS Exchaneg czy IBM Notes. Na początek trzeba ustalić na jakie wsparcie techniczne (spolszczenie) i prawne (czy możne użyć ich aplikacji do celów komercyjnych) możemy liczyć od dużych firm oferujących aplikacje internetowe Web 2.0 i działające na rynku polskim.

Oto propozycje bazujące na typowych zintegrowanych aplikacjach Web 2.0:

1. Po pierwsze można udostępnić wspólny kalendarz w oparciu o jakiś standard internetowy Web 2.0 (np. z MS lub Google - ważne jest to, żeby był spolszczony; można się zwrócić do biur przedstawicielstw tych firm w Polsce).
2. Wprowadzenie innych pojedyńczych elementów współpracy portalowej np. wpółdzielenie dokumentów lub arkuszy.
3. Pomysł ten można rozwinąć poprzez wprowadzenie więcej elementów portalowych (znowu tu mamy wybór: MS Live lub Google Apps 4U Domain) na poziomie koopercji między klientami i nami oraz zintegrowanie ich między sobą.

Inne pomysły nie będące w ofercie zintergrowanej Web 2.0 dostępnej przez duże firmy a mające korzenie w projektach open-source. Przy wyborze należy kierować się nie tylko samym projektem, jego zawartością i wartością merytoryczną  ale również jego dojrzałością i możliwością rozwoju (nie ma sensu wchodzić w projekt tworzony przez małą grupę programistów):

1. Wprowadzenie do naszych stron elementów RSS lub nawet SPA (Single Page Agregator) - udostępniających skrót najważniejszych aktualnych informacji prezentowanych w naszym portalu.
2. Raporty w oparciu o GLX z LogicXML.

Lepsze wykorzystanie technologii telefonii internetowej oferowanej przez SKYPE poprzez integrację jej z naszymi aplikacjami (Skype API).

Skorzystanie z oferty krajowej firmy LeftHand oferującej swój  produkt klasy CRM.

Inne blogi

• Uwaga! Bardzo ciekawe jest formum Google Groups.
• Bardzo dużo ciekawych i opiniotwórczych (rozmowy z najwyższymi przedstawicielami firm branży informatycznej) blogów jest prezentowanych na witrynie cnet/zdnet - Alpha The CNET blog. Widać tu wyraźnie dwa opozy pro open source (Berling)  i pro Microsoft. Cóż taka jest reguła amerykańskiej poprawności.
• Z innej strony Google ma już dosyć dawno swojego bloga - www.blogger.com. Od wczoraj można otwarcie testować nową jego odsłonę. Narazie są dwie wersje stara i beta. Do nowej można logować się poprzez konto googla (inne od tego jakie służy do logowania do starego blogu). Jeżeli tak zrobimy to dostaniemy "rozbiegówkę" w której mamy wszystkie śmieci jakie Google zrobił w wersji beta a więc:
  •  gmail,
  •  reader,
  •  spreadsheet,
  •  write,
  •  page creator,
  • calendar i inne.

To wszystko realizowane jest w ramach nowej strategii Google Apps for Your Domain (pod tym adresem trzeba zacząć https://www.google.com/a/). Dla małych geszeftów będzie bezpłatna (wsparcie techniczne poprzez Google groups. Dla dużych i średnich przewiduje się serwis płatny premium udostępniający: wsparcie serwisowe, SLA,  usługi dodatkowe, API, logowanie pojedyńcze (SSO) oraz inne atrybuty ważne dla dużych przedsiębiorstw (lepsze zarządzanie).

Równolegle Microsoft otworzył podobny portal Live i Office Live, Yahoo postąpiło podobnie. Walka trwa.

Odpluskwić AJAX-a

W Firefox dostępna jest wtyczka FireBug służąca do testowania stron wykorzystujących tę technologię.

OpenSUN

No jeszcze nie tak do końca. Ale dzisiaj pojawiła się informacja o udostępnieniu przez firmę SUN projektuOpenSSOO (Single-sign-out). Jest to drugi projekt otwarty przez tę firmę. Pierwszym był OpenDS (Directory Servis) opisywany jako "otwarty na społeczność projekt mający za zadanie zbudowanie bezpłatnej i uniwersalnej usługi katalogowej". Projekt ten różni się znacznie od OpenLDAP nie tylko nazwą ale też i rozległością tematyczną, zawiera dodatkowe usługi wspierające: proxy do słownika, wirtualne katalogi, rozgłaszanie przestrzeni nazw oraz synchronizację danych.

MySQL na poważnie

Firma Connect z Warszawy organizuje semianrium na tema MySQL i jego wykorzystania w korporacji. Uwaga: proponuje użycie tej bazy jako motoru dla BusinessObject. Prawda jest taka, że cechą BO jest dużo operacji wyszukiwania i kojarzenia a to są cechy MySQL (jest szybki do wyciągania danych z bazy). Ktoś tu dobrze pogłówkował i sparował ze sobą komplementarnie uzupełniajace się technologie.

Turbo co?

Turbo C#, Borland odzyskuje trzeci oddech. Obiecuje od 1 wrzesnia udostępnić nową serię swoich produktów na linii Turbocos. Między innymi będzie Turbo C#. Bardzo ciekawa propozycja, ponieważ wersja Express jest bezpłatna i zawiera ponad 200+ wbudowanych kontrolek. Duża konkurencja dla MS C# też w wersji express. W wersji Professional będzie można m.in. rozszerzyć paletę kontrolek o swe własne lub firm trzecich. Stworzenie samego srodowiska edycyjnego i uruchomieniowego nie jest żadnym szczególnym osiągnięciem, ponieważ takie IDE to nic innego jak dobry edytor z wbudowanym silnikiem zorientowanym na składnię C#, który jest zresztą zestandaryzowany, a platforma run-time w postaci .NET już jest dostarczona przez Microsoft. Np. kompilacja (i inne funkcje RAD) może odbywać się poprzez wywołanie wtle odpowiedniego polecenia .NET Framework i przechwycenie wyniki do okna. Najciekawsze jest to, że nadal będą wspierane dwa środowiska .NET i Win32. Borland nie porzucił starej platformy, która ciągle ma sens w świetle tego, że nadal jest wiele starych (i sprzętowo i programowo) komputerów. To dlatego będzie dostępny Turbo Delphi i Turbo Delphi .NET.

Kiedy AJAX upada

Wiele się mówi o wykorzystaniu technologii AJAX w aplikacjach Web 2.0 (słynne wyrażenie 'mashup' - miszmasz, czyli udostępnianie funkcjonalości różnorodnych usług "sklejonych" Javascriptem poprzez wykorzystanie AJAX-a. Coraz więcej stron publikuje swoje API  w celu wygodnego korzystania z funkcjonalności danej witryny (hej! czy to nie jest to samo co usługa webowa, ale na bardziej przystępnym poziomie ?). Ale z drugiej strony pojawiają się głosy o zgrożeniach jakie niesie niekontrolowany dostęp do zasobów (infrastruktury firmy) poza stroną internetową. Pierwsze sygnały ostrzegawcze zabrzmiały na konferencji Black Hat w Las Vegas. Billy Hoffman z SPI Dynamics wykazał możliwość naruszenia ochrony strony. Strony udostępniające funkcjonalność poprzez AJAX powinny przewidzieć dodatkową ochronę przed włamaniem do swych zasobów.

Korzystając z AJAX-a atakujący może wstrzykąć skrypt na stronę docelową lub skrypt wywołujący skrypty z innej strony, bądź wysłać atak poprzez zmasowane żądanie HTTP. Dlatego bardzo ważne jest filtrowanie danych wprowadzanych przez użytkownika.

W domyśle AJAX jest ograniczony do jednego hosta internetowego. Istnieje jednak możliwość zbudowania tzw. AJAX bridges - mostu umożliwającego sięganie do zasobów (np. skryptów) pochodzących z innych domen. W przykładzie Billy Hoffama widać, że np. strona Amazon otwierając się na świat poprzez udostępnie swego API pozwalającego na komunikację z jej zasobami poprzez AJAX tak dokładnie nie wie kto z niej korzysta: użytkownik czy program (złośliwy czy dobry) . Jest to poważne zagrożenie bezpieczeństwa jej zasobów.

AJAX bridges posiadają wiele szczelin zagrażających bezpieczeństwu:  nie autentykują danych wejściowych a w zakresie zabezpieczeń polegają na innych komponentach (które nie zawsze wpełni zabezpieczają). Możliwe jest w niewidoczny sposób wykorzystać słabości w zabezpieczeniu jednej witryny w celu zaatakowania innej lub nawet przeprowadzić zmasowany atak na witrynę trzecią coś w rodzaju DoS 

Jaka jest na to rada? Dokładna walidacja danych wejściowych wprowadzonych przez użytkownika, należy minimalizować udostępnianą przez aplikację internetową logikę działania, należy również wszędzie korzystać ze standardów.

Artykuł poprzedni: Security Watch: JavaScript plus AJAX equals trouble

Źródło:CNet Security Watch (Robert Vamosi)