rodzaj: POSTANOWIENIE
data dokumentu: 2018-08-20
rok: 2018
data dokumentu: 2018-08-20
rok: 2018
sygnatury akt.:
KIO 1569/18
KIO 1569/18
po rozpoznaniu na posiedzeniu niejawnym
bez udziału stron oraz uczestników postępowania
w dniu 20 sierpnia 2018 roku, w
obec cofnięcia w dniu 16 sierpnia 2018 roku odwołania
wniesionego
do Prezesa Krajowej Izby Odwoławczej w dniu 6 sierpnia 2018 roku przez
wykonawcę S&T Services Polska Spółka z ograniczoną odpowiedzialnością z siedzibą
w Warszawie,
w postępowaniu prowadzonym przez Straż Miejską miasta stołecznego
Warszawy z siedzibą w Warszawie
bez udziału stron oraz uczestników postępowania
w dniu 20 sierpnia 2018 roku, w
obec cofnięcia w dniu 16 sierpnia 2018 roku odwołania
wniesionego
do Prezesa Krajowej Izby Odwoławczej w dniu 6 sierpnia 2018 roku przez
wykonawcę S&T Services Polska Spółka z ograniczoną odpowiedzialnością z siedzibą
w Warszawie,
w postępowaniu prowadzonym przez Straż Miejską miasta stołecznego
Warszawy z siedzibą w Warszawie
postanawia:
1) umarza
postępowanie odwoławcze;
2) nakazuje
zwrot z rachunku bankowego Urzędu Zamówień Publicznych na rzecz
wykonawcy S&
T Services Polska Spółka z ograniczoną odpowiedzialnością z siedzibą
w Warszawie kwoty 13 50
0 zł 00 gr (słownie: trzynaście tysięcy pięćset złotych zero
groszy), sta
nowiącej 90% uiszczonego wpisu.
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. -
Prawo zamówień
publicznych (t.j. Dz. U. z 2017 r. poz. 1579 ze zm.) na niniejsze postanowienie - w terminie
7 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby
Odwoławczej do Sądu Okręgowego w Warszawie.
P
rzewodniczący: ………………………………
..…………………………….
………………………………
Sygn. akt: KIO 1569/18
Uzasadnienie
Zamawiajacy
– Straż Miejska miasta stołecznego Warszawy z siedzibą
w Warszawie
prowadzi postępowanie pod nazwą: Wykonanie Systemu “Zintegrowana
Platforma
Wymiany Danych” wspomagającego procesy w obszarze wspomagania
dowodzeniai rea
lizacji zadań Straży Miejskiej m.st. Warszawy.
Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej -
numer ogłoszenia 2018/S 141-323062. Postępowanie prowadzone jest w trybie przetargu
nieograniczonego, o wartości zamówienia powyżej kwot określonych w przepisach wydanych
na podstawie art. 11 ust. 8 ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych
(t.j. Dz. U. z 2017 r., poz.1579 z późn. zm.) zwaną dalej „ustawą” lub „Pzp”.
W dniu 6 sierpnia
2018 roku do Prezesa Krajowej Izby Odwoławczej wpłynęło
odwołanie wniesione przez wykonawcę S&T Services Polska Spółka z ograniczoną
odpowiedzialnością z siedzibą w Warszawie (zwanego dalej Odwołującym) wobec
postanowień Specyfikacji Istotnych Warunków Zamówienia (zwanej dalej SIWZ) w zakresie
opisu przedmiotu zamówienia (załącznik nr 1 do SIWZ), tj. wobec:
1)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.1:
„Wbudowane wsparcie dla współdzielenia kodu (np. bibliotek) pomiędzy wieloma
aplikacjami (Web, EJB, Web services). Biblioteki (]AR, WAR, EAR, EJB) powinny być
instalowane w serwerze aplikacyjnym jednokrotnie i wiele aplikacji może z nich
skorzystać Możliwość zainstalowania wielu wersji bibliotek równocześnie.
Możliwość konfiguracji, która wersja biblioteki będzie wykorzystywana przez aplikację.
Konfiguracja powinna odbywać się w sposób deklaratywny (za pomocą deployment
deskryptorów) - nie poprzez kopiowanie kodu bibliotek do aplikacji. Przykład - wiele
implementacji JSF działających równocześnie w serwerze aplikacyjnym”;
2)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA. 2:
„Konfiguracja komponentów w aplikacjach webowych (np. servletow, filtrów servletow,
web services) za
pomocą odpowiedniej adnotacji”;
3)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA. 4:
„Wbudowane wsparcie dla przechowywania (persistence) sesji webowych i EJB
w p
liku, bazie danych i pamięci”;
4)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.5:
„Możliwość przechowywania istotnych informacji dotyczących sesji użytkownika (w tym
sesja http, kont
eksty usług typu Servlet oraz konteksty usług typu Session EJB)
w
zewnętrznej pamięci cache poza głównym procesem maszyny wirtualnej.
Oprogramowanie musi umożliwiać mechanizmy klastrowania aplikacji w powyższy
sposób, czyli z wykorzystaniem cache’a zewnętrznego";
5)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.8:
„Wbudowana obsługa pul połączeń do baz danych z uwierzytelnieniem połączeń.
Tworzenie pul połączeń JDBC, w których jest możliwość zmapowania użytkowników
serwera aplikacyjnego na użytkowników zdefiniowanych w bazie danych. Powinna być
możliwość wykonania mapowania typu „user id per connection”;
6)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.10:
„Wbudowana obsługa zawieszania i wznawiania transakcji rozproszonych (XA)
w ramach JTA
API (suspend/resume)”;
7)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.27:
„Możliwość konfiguracji dynamicznego członkostwa ról, np. uwzględniającego datę
i czas, zawartość wybranych elementów w komunikatach SOAP (Web services),
wartość atrybutów żądań HTTP, wartość atrybutów sesji HTTP, czy parametrów metod
EJB”;
8)
wymagania zawartego w pkt 2.7.5.2.Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.36:
„Wbudowana możliwość klastrowania połączeń JDBC”;
9)
wymagania zawartego w pkt 2.7.5.2 Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.37:
„Możliwość klastrowania obiektów typu singelton w aplikacjach”;
10)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.47:
„Serwer aplikacji musi mieć możliwość instalacji na systemach operacyjnych typu Linux
oraz na komercyjnych systemach operacyjnych wiodących producentów takich jak
IBM, HP, Sun/Oracle i Microsoft”
11)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.48:
„Wbudowana obsługa zaawansowanych mechanizmów kolejkowych QMS): możliwość
łączenia komunikatów JMS w jednostki (grupy), a następnie przetwarzanie jednostek.
Klient J
MS nie może przetwarzać danej jednostki, dopóki w JMS nie pojawią się
wszystkie komunikaty wchodzące w skład danej jednostki. Przetwarzanie różnych
jednostek (niezależnych od siebie grup komunikatów) powinno być jednak możliwe”;
12) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.49:
„Wbudowana integracja EJB 3.0 i Spring";
13) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.50:
„Certyfikacja Spring Framework”;
14) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.51:
„Wbudowane wsparcie dla specyfikacji Commons J Work Manager API i Timer API”;
15) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.52:
„Wbudowane wsparcie dla specyfikacji JSR-88 - plany wdrożeń (Deployment Plan)”;
16) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.54:
„Publicznie dostępne raporty (benchmarki) dotyczące wydajności serwera
aplikacyjnego. Raporty powinny zawierać szczegółowe informacje o zastosowanej
konfiguracji serwera aplikacyjnego, JVM, bazy danych, sprzętu i innych komponentów
użytych podczas testowania”;
17) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
w pozycji SK.1:
„Oprogramowanie udostępni adapter kolejkowy umożliwiający komunikację
wg następujących standardów: -JMS, -MQ, -AQ”;
18) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
w pozycji SK.2:
„Wbudowana możliwość klastrowania JMS (w tym automatyczne przełączanie klientów
JMS w momencie failover serwerów JMS)";
19) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
w pozycji SK.4:
„Wbudowany interfejs do JMS dla aplikacji napisanych w C (JMS C API)”,
20) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
wpozycji SK.5:
„Wbudowany interfejs do JMS dla aplikacji napisanych w Microsoft .NET C# (JMS
C#
API]”;
21) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
w pozycji SK.14:
„Wbudowana obsługa zaawansowanych mechanizmów kolejkowych (JMS):
grupowanie komunikatów przesyłanych do JMS z gwarancją zachowania kolejności ich
przetworzenia (konsumpcji) wynikającą z kolejności ich utworzenia (produkcji)”;
22) wymagania zawartego w pkt 2.7.5.8.
Wymagania dla podsystemu zarządzania w tabeli
21 w pozycji PZ.15:
„Monitorowanie zasobów serwerów aplikacyjnych takich jak póle połączeń JDBC,
kolejki JMS,
źródła danych”.
Odwołujący zarzucił Zamawiającemu zarzut naruszenia następujących przepisów:
art. 29 ust. 1, 2 i 3 w zw. z art. 7 ust. 1 Pzp, poprzez dokonanie opisu przedmiotu
zamówienia bez uwzględnienia wszystkich okoliczności i wymagań mogących mieć wpływ na
sporządzenie oferty, utrudniający uczciwą konkurencję i naruszający zasady
przepro
wadzenia postępowania z poszanowaniem zasad uczciwej konkurencji, w tym przez
wskazanie przez Zamawiającego konkretnych parametrów rozwiązania, które wskazują na
produkty jednej technologii, co powoduje uprzywilejowanie lub wyeliminowanie niektórych
wykona
wców lub produktów;
Wobec powyższych naruszeń Odwołujący wniósł o uwzględnienie odwołania oraz nakazanie
Zamawiającemu następujących modyfikacji SIWZ:
1)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji SA.
1 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowane wsparcie dla współdzielenia kodu (np. bibliotek) pomiędzy wieloma
aplikacjami
(Web,
Web
services).
Biblioteki
powinny
być
instalowane
w serwerze aplikacyjnym jednokrotnie i wiele apli
kacji może z nich skorzystać
Możliwość zainstalowania wielu wersji bibliotek równocześnie.
Możliwość konfiguracji, która wersja biblioteki będzie wykorzystywana przez aplikację.
Konfiguracja powinna odbywać się w sposób deklaratywny (za pomocą deployment
d
eskryptorów) - nie poprzez kopiowanie kodu bibliotek do aplikacji. Przykład - wiele
implementacji działających równocześnie w serwerze aplikacyjnym";
2)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w poz
ycji SA.2 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Konfiguracja komponentów w aplikacjach webowych za pomocą
odpowiedniej adnotacji";
3)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji SA
.4 (Załącznik nr 1 do SIWZ) następującym
wymaganiem: „Wbudowane wsparcie dla przechowywania (persistence) sesji
w
ebowych bazie danych i pamięci";
4)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji
SA.5 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Możliwość przechowywania istotnych informacji dotyczących sesji
użytkownika w zewnętrznej pamięci cache. Oprogramowanie musi umożliwiać
mechanizmy klastrowania aplikacji w powyższy sposób, czyli z wykorzystaniem
cache'a zewnętrznego".
5)
Wykreślenie całego wymagania z pkt pkt 2.7.5.2. Wymagania dla serwera aplikacji
w tabeli 15 w pozycji SA.8;
6)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji S
A.10 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowana obsługa transakcji rozproszonych”;
7)
Wykreślenie całego wymagania z pkt pkt 2.7.5.2. Wymagania dla serwera aplikacji
w tabeli 15 w pozycji SA.27;
8)
Wykreślenie całego wymagania z pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli
15 w pozycji SA.36.
9)
Wykreślenie całego wymagania z pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli
15 w pozycji SA.37;
10)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2.Wymagania dla serwera
aplikacji w
tabeli 15 w pozycji SA.47 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Serwer aplikacji musi mieć możliwość instalacji na przynajmniej jednym z systemów
operacyjnych: Linux, I
BM, HP, Sun/Oracle, Microsoft”;
11)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji SA.48 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowana obsługa zaawansowanych mechanizmów kolejkowych
(JMS): możliwość łączenia komunikatów JMS w jednostki (grupy), a następnie
przetwarzanie jednostek. Klient JMS nie może przetwarzać danej jednostki, dopóki
w JMS nie pojawią się wszystkie komunikaty wchodzące w skład danej jednostki.
Przetwarzanie różnych jednostek (niezależnych od siebie grup komunikatów) powinno
być jednak możliwe”;
12)
Wykreślenie całego wymagania z pkt pkt 2.7.5.2. Wymagania dla serwera aplikacji
w tabeli 15 w pozycji SA.49;
13)
Wykreślenie całego wymagania z pkt pkt 2.7.5.2.Wymagania dla serwera aplikacji
w tabeli 15 w pozycji SA.50;
14)
Wykreślenie całego wymagania z pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli
15 w pozycji SA.51;
15)
Wykreślenie całego wymagania z pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli
15 w pozycji SA.52;
16)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji SA.54 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Publicznie dostępne raporty (benchmarki) dotyczące wydajności
serwera aplikacyjnego. Raporty powinny zawierać szczegółowe informacje
o zastosowanej konfiguracj
i serwera aplikacyjnego bądź aplikacji, bazy danych,
sprzętu i innych komponentów użytych podczas testowania";
17)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.1 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Oprogramowanie udostępni adapter kolejkowy umożliwiający komunikację wg jednego
ze standardów: -JMS, -MQ, -AQ, AMQP";
18)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.2 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowana możliwość klastrowania adaptera kolejkowego”;
19)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.4 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowany interfejs dla aplikacji napisanych w C”;
20)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.5 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowany interfejs dla aplikacji napisanych w Microsoft .NET C#”;
21)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.14 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowana obsługa zaawansowanych mechanizmów kolejkowych";
22)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.8. Wymagania dla podsystemu
zarządzania w tabeli 21 w pozycji PZ.15 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Monitorowanie zasobów serwerów aplikacyjnych".
W dniu 16 sierpnia
2018 r. Odwołujący, przed otwarciem rozprawy złożył pismo,
w którym oświadczył, że cofa wniesione odwołanie w całości.
Ze względu na fakt, że odwołanie można cofnąć w każdym czasie do zamknięcia
rozprawy, jego cofnięcie, zgodnie z art. 187 ust. 8 ustawy Pzp oznacza, że postępowanie
odwoławcze podlega umorzeniu.
W tym stanie rzeczy Krajowa Izba
Odwoławcza – zgodnie z przepisem art. 187 ust. 8
zd. pierwsze ustawy Pzp
– postanowiła umorzyć postępowanie odwoławcze.
Ponadto zgodnie z art. 187 ust. 8 zd. drugie ustawy Pz
p oraz na podstawie § 5 ust. 1
pkt 3 lit. a) rozporządzenia Prezesa Rady Ministrów z dnia 15 marca 2010 r. w sprawie
wysokości i sposobu pobierania wpisu od odwołania oraz rodzajów kosztów w postępowaniu
odwoławczym i sposobu ich rozliczania (Dz. U. z 2018 poz. 972) Izba orzekła o dokonaniu
zwrotu na rzecz Odwołującego 90% kwoty wpisu uiszczonego w wysokości 15 000,00 zł.
Przewodniczący: ………………………………
……………………………….
……………………………….
1) umarza
postępowanie odwoławcze;
2) nakazuje
zwrot z rachunku bankowego Urzędu Zamówień Publicznych na rzecz
wykonawcy S&
T Services Polska Spółka z ograniczoną odpowiedzialnością z siedzibą
w Warszawie kwoty 13 50
0 zł 00 gr (słownie: trzynaście tysięcy pięćset złotych zero
groszy), sta
nowiącej 90% uiszczonego wpisu.
Stosownie do art. 198a i 198b ustawy z dnia 29 stycznia 2004 r. -
Prawo zamówień
publicznych (t.j. Dz. U. z 2017 r. poz. 1579 ze zm.) na niniejsze postanowienie - w terminie
7 dni od dnia jego doręczenia - przysługuje skarga za pośrednictwem Prezesa Krajowej Izby
Odwoławczej do Sądu Okręgowego w Warszawie.
P
rzewodniczący: ………………………………
..…………………………….
………………………………
Sygn. akt: KIO 1569/18
Uzasadnienie
Zamawiajacy
– Straż Miejska miasta stołecznego Warszawy z siedzibą
w Warszawie
prowadzi postępowanie pod nazwą: Wykonanie Systemu “Zintegrowana
Platforma
Wymiany Danych” wspomagającego procesy w obszarze wspomagania
dowodzeniai rea
lizacji zadań Straży Miejskiej m.st. Warszawy.
Ogłoszenie o zamówieniu zostało opublikowane w Dzienniku Urzędowym Unii Europejskiej -
numer ogłoszenia 2018/S 141-323062. Postępowanie prowadzone jest w trybie przetargu
nieograniczonego, o wartości zamówienia powyżej kwot określonych w przepisach wydanych
na podstawie art. 11 ust. 8 ustawy z dnia 29 stycznia 2004 r. Prawo zamówień publicznych
(t.j. Dz. U. z 2017 r., poz.1579 z późn. zm.) zwaną dalej „ustawą” lub „Pzp”.
W dniu 6 sierpnia
2018 roku do Prezesa Krajowej Izby Odwoławczej wpłynęło
odwołanie wniesione przez wykonawcę S&T Services Polska Spółka z ograniczoną
odpowiedzialnością z siedzibą w Warszawie (zwanego dalej Odwołującym) wobec
postanowień Specyfikacji Istotnych Warunków Zamówienia (zwanej dalej SIWZ) w zakresie
opisu przedmiotu zamówienia (załącznik nr 1 do SIWZ), tj. wobec:
1)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.1:
„Wbudowane wsparcie dla współdzielenia kodu (np. bibliotek) pomiędzy wieloma
aplikacjami (Web, EJB, Web services). Biblioteki (]AR, WAR, EAR, EJB) powinny być
instalowane w serwerze aplikacyjnym jednokrotnie i wiele aplikacji może z nich
skorzystać Możliwość zainstalowania wielu wersji bibliotek równocześnie.
Możliwość konfiguracji, która wersja biblioteki będzie wykorzystywana przez aplikację.
Konfiguracja powinna odbywać się w sposób deklaratywny (za pomocą deployment
deskryptorów) - nie poprzez kopiowanie kodu bibliotek do aplikacji. Przykład - wiele
implementacji JSF działających równocześnie w serwerze aplikacyjnym”;
2)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA. 2:
„Konfiguracja komponentów w aplikacjach webowych (np. servletow, filtrów servletow,
web services) za
pomocą odpowiedniej adnotacji”;
3)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA. 4:
„Wbudowane wsparcie dla przechowywania (persistence) sesji webowych i EJB
w p
liku, bazie danych i pamięci”;
4)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.5:
„Możliwość przechowywania istotnych informacji dotyczących sesji użytkownika (w tym
sesja http, kont
eksty usług typu Servlet oraz konteksty usług typu Session EJB)
w
zewnętrznej pamięci cache poza głównym procesem maszyny wirtualnej.
Oprogramowanie musi umożliwiać mechanizmy klastrowania aplikacji w powyższy
sposób, czyli z wykorzystaniem cache’a zewnętrznego";
5)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.8:
„Wbudowana obsługa pul połączeń do baz danych z uwierzytelnieniem połączeń.
Tworzenie pul połączeń JDBC, w których jest możliwość zmapowania użytkowników
serwera aplikacyjnego na użytkowników zdefiniowanych w bazie danych. Powinna być
możliwość wykonania mapowania typu „user id per connection”;
6)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.10:
„Wbudowana obsługa zawieszania i wznawiania transakcji rozproszonych (XA)
w ramach JTA
API (suspend/resume)”;
7)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.27:
„Możliwość konfiguracji dynamicznego członkostwa ról, np. uwzględniającego datę
i czas, zawartość wybranych elementów w komunikatach SOAP (Web services),
wartość atrybutów żądań HTTP, wartość atrybutów sesji HTTP, czy parametrów metod
EJB”;
8)
wymagania zawartego w pkt 2.7.5.2.Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.36:
„Wbudowana możliwość klastrowania połączeń JDBC”;
9)
wymagania zawartego w pkt 2.7.5.2 Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.37:
„Możliwość klastrowania obiektów typu singelton w aplikacjach”;
10)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.47:
„Serwer aplikacji musi mieć możliwość instalacji na systemach operacyjnych typu Linux
oraz na komercyjnych systemach operacyjnych wiodących producentów takich jak
IBM, HP, Sun/Oracle i Microsoft”
11)
wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.48:
„Wbudowana obsługa zaawansowanych mechanizmów kolejkowych QMS): możliwość
łączenia komunikatów JMS w jednostki (grupy), a następnie przetwarzanie jednostek.
Klient J
MS nie może przetwarzać danej jednostki, dopóki w JMS nie pojawią się
wszystkie komunikaty wchodzące w skład danej jednostki. Przetwarzanie różnych
jednostek (niezależnych od siebie grup komunikatów) powinno być jednak możliwe”;
12) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.49:
„Wbudowana integracja EJB 3.0 i Spring";
13) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.50:
„Certyfikacja Spring Framework”;
14) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.51:
„Wbudowane wsparcie dla specyfikacji Commons J Work Manager API i Timer API”;
15) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.52:
„Wbudowane wsparcie dla specyfikacji JSR-88 - plany wdrożeń (Deployment Plan)”;
16) wymagania zawartego w pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli 15
w pozycji SA.54:
„Publicznie dostępne raporty (benchmarki) dotyczące wydajności serwera
aplikacyjnego. Raporty powinny zawierać szczegółowe informacje o zastosowanej
konfiguracji serwera aplikacyjnego, JVM, bazy danych, sprzętu i innych komponentów
użytych podczas testowania”;
17) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
w pozycji SK.1:
„Oprogramowanie udostępni adapter kolejkowy umożliwiający komunikację
wg następujących standardów: -JMS, -MQ, -AQ”;
18) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
w pozycji SK.2:
„Wbudowana możliwość klastrowania JMS (w tym automatyczne przełączanie klientów
JMS w momencie failover serwerów JMS)";
19) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
w pozycji SK.4:
„Wbudowany interfejs do JMS dla aplikacji napisanych w C (JMS C API)”,
20) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
wpozycji SK.5:
„Wbudowany interfejs do JMS dla aplikacji napisanych w Microsoft .NET C# (JMS
C#
API]”;
21) wymagania zawartego w pkt 2.7.5.3.
Wymagania dla silnika komunikatów w tabeli 16
w pozycji SK.14:
„Wbudowana obsługa zaawansowanych mechanizmów kolejkowych (JMS):
grupowanie komunikatów przesyłanych do JMS z gwarancją zachowania kolejności ich
przetworzenia (konsumpcji) wynikającą z kolejności ich utworzenia (produkcji)”;
22) wymagania zawartego w pkt 2.7.5.8.
Wymagania dla podsystemu zarządzania w tabeli
21 w pozycji PZ.15:
„Monitorowanie zasobów serwerów aplikacyjnych takich jak póle połączeń JDBC,
kolejki JMS,
źródła danych”.
Odwołujący zarzucił Zamawiającemu zarzut naruszenia następujących przepisów:
art. 29 ust. 1, 2 i 3 w zw. z art. 7 ust. 1 Pzp, poprzez dokonanie opisu przedmiotu
zamówienia bez uwzględnienia wszystkich okoliczności i wymagań mogących mieć wpływ na
sporządzenie oferty, utrudniający uczciwą konkurencję i naruszający zasady
przepro
wadzenia postępowania z poszanowaniem zasad uczciwej konkurencji, w tym przez
wskazanie przez Zamawiającego konkretnych parametrów rozwiązania, które wskazują na
produkty jednej technologii, co powoduje uprzywilejowanie lub wyeliminowanie niektórych
wykona
wców lub produktów;
Wobec powyższych naruszeń Odwołujący wniósł o uwzględnienie odwołania oraz nakazanie
Zamawiającemu następujących modyfikacji SIWZ:
1)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji SA.
1 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowane wsparcie dla współdzielenia kodu (np. bibliotek) pomiędzy wieloma
aplikacjami
(Web,
Web
services).
Biblioteki
powinny
być
instalowane
w serwerze aplikacyjnym jednokrotnie i wiele apli
kacji może z nich skorzystać
Możliwość zainstalowania wielu wersji bibliotek równocześnie.
Możliwość konfiguracji, która wersja biblioteki będzie wykorzystywana przez aplikację.
Konfiguracja powinna odbywać się w sposób deklaratywny (za pomocą deployment
d
eskryptorów) - nie poprzez kopiowanie kodu bibliotek do aplikacji. Przykład - wiele
implementacji działających równocześnie w serwerze aplikacyjnym";
2)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w poz
ycji SA.2 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Konfiguracja komponentów w aplikacjach webowych za pomocą
odpowiedniej adnotacji";
3)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji SA
.4 (Załącznik nr 1 do SIWZ) następującym
wymaganiem: „Wbudowane wsparcie dla przechowywania (persistence) sesji
w
ebowych bazie danych i pamięci";
4)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji
SA.5 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Możliwość przechowywania istotnych informacji dotyczących sesji
użytkownika w zewnętrznej pamięci cache. Oprogramowanie musi umożliwiać
mechanizmy klastrowania aplikacji w powyższy sposób, czyli z wykorzystaniem
cache'a zewnętrznego".
5)
Wykreślenie całego wymagania z pkt pkt 2.7.5.2. Wymagania dla serwera aplikacji
w tabeli 15 w pozycji SA.8;
6)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji S
A.10 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowana obsługa transakcji rozproszonych”;
7)
Wykreślenie całego wymagania z pkt pkt 2.7.5.2. Wymagania dla serwera aplikacji
w tabeli 15 w pozycji SA.27;
8)
Wykreślenie całego wymagania z pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli
15 w pozycji SA.36.
9)
Wykreślenie całego wymagania z pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli
15 w pozycji SA.37;
10)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2.Wymagania dla serwera
aplikacji w
tabeli 15 w pozycji SA.47 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Serwer aplikacji musi mieć możliwość instalacji na przynajmniej jednym z systemów
operacyjnych: Linux, I
BM, HP, Sun/Oracle, Microsoft”;
11)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji SA.48 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowana obsługa zaawansowanych mechanizmów kolejkowych
(JMS): możliwość łączenia komunikatów JMS w jednostki (grupy), a następnie
przetwarzanie jednostek. Klient JMS nie może przetwarzać danej jednostki, dopóki
w JMS nie pojawią się wszystkie komunikaty wchodzące w skład danej jednostki.
Przetwarzanie różnych jednostek (niezależnych od siebie grup komunikatów) powinno
być jednak możliwe”;
12)
Wykreślenie całego wymagania z pkt pkt 2.7.5.2. Wymagania dla serwera aplikacji
w tabeli 15 w pozycji SA.49;
13)
Wykreślenie całego wymagania z pkt pkt 2.7.5.2.Wymagania dla serwera aplikacji
w tabeli 15 w pozycji SA.50;
14)
Wykreślenie całego wymagania z pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli
15 w pozycji SA.51;
15)
Wykreślenie całego wymagania z pkt 2.7.5.2. Wymagania dla serwera aplikacji w tabeli
15 w pozycji SA.52;
16)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.2. Wymagania dla serwera
aplikacji w tabeli 15 w pozycji SA.54 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Publicznie dostępne raporty (benchmarki) dotyczące wydajności
serwera aplikacyjnego. Raporty powinny zawierać szczegółowe informacje
o zastosowanej konfiguracj
i serwera aplikacyjnego bądź aplikacji, bazy danych,
sprzętu i innych komponentów użytych podczas testowania";
17)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.1 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Oprogramowanie udostępni adapter kolejkowy umożliwiający komunikację wg jednego
ze standardów: -JMS, -MQ, -AQ, AMQP";
18)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.2 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowana możliwość klastrowania adaptera kolejkowego”;
19)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.4 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowany interfejs dla aplikacji napisanych w C”;
20)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.5 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowany interfejs dla aplikacji napisanych w Microsoft .NET C#”;
21)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.3. Wymagania dla silnika
komunikatów w tabeli 16 w pozycji SK.14 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Wbudowana obsługa zaawansowanych mechanizmów kolejkowych";
22)
zastąpienie aktualnego wymagania z punktu pkt 2.7.5.8. Wymagania dla podsystemu
zarządzania w tabeli 21 w pozycji PZ.15 (Załącznik nr 1 do SIWZ) następującym
wymaganiem:
„Monitorowanie zasobów serwerów aplikacyjnych".
W dniu 16 sierpnia
2018 r. Odwołujący, przed otwarciem rozprawy złożył pismo,
w którym oświadczył, że cofa wniesione odwołanie w całości.
Ze względu na fakt, że odwołanie można cofnąć w każdym czasie do zamknięcia
rozprawy, jego cofnięcie, zgodnie z art. 187 ust. 8 ustawy Pzp oznacza, że postępowanie
odwoławcze podlega umorzeniu.
W tym stanie rzeczy Krajowa Izba
Odwoławcza – zgodnie z przepisem art. 187 ust. 8
zd. pierwsze ustawy Pzp
– postanowiła umorzyć postępowanie odwoławcze.
Ponadto zgodnie z art. 187 ust. 8 zd. drugie ustawy Pz
p oraz na podstawie § 5 ust. 1
pkt 3 lit. a) rozporządzenia Prezesa Rady Ministrów z dnia 15 marca 2010 r. w sprawie
wysokości i sposobu pobierania wpisu od odwołania oraz rodzajów kosztów w postępowaniu
odwoławczym i sposobu ich rozliczania (Dz. U. z 2018 poz. 972) Izba orzekła o dokonaniu
zwrotu na rzecz Odwołującego 90% kwoty wpisu uiszczonego w wysokości 15 000,00 zł.
Przewodniczący: ………………………………
……………………………….
……………………………….
Wcześniejsze orzeczenia:
- Sygn. akt KIO 1946/18 z dnia 2018-10-15
- Sygn. akt KIO 1951/18 z dnia 2018-10-12
- Sygn. akt KIO 1878/18, KIO 1879/18, KIO 1880/18 z dnia 2018-10-08
- Sygn. akt KIO 1819/18 z dnia 2018-10-01
- Sygn. akt KIO 1357/18, KIO 1367/18, KIO 1387/18 z dnia 2018-09-26
