On 2013-02-19 14:32, Piotr Chamera wrote:
> W dniu 2013-02-19 09:39, Michal Kleczek pisze:
>> On 2013-02-17 22:00, Piotr Chamera wrote:
>
> Pisałeś: "nie da sie zintegrowac (pod)systemow bez _jednego_ wspolnego
> języka", teraz piszesz, że w teorii się da, ale praktyka jest inna...

Tak - nie dodalem "w praktyce".

> Ciekaw jestem z jakimi systemami (w jakiej dziedzinie zastosowań)
> pracujesz, że tak to widzisz?

- bankowosc
- publikacja tresci

> Czy taka integracja rzeczywiście coś daje,
> czy to tylko dobrze brzmiący marketing?
>

Jest trudna, ale _jakos_ trzeba to zrobic. Nie mozna dopuscic do
komunikacji "kazdy z kazdym", bo zlozonosc systemu rosnie w takim modelu
bardzo szybko.

> Ja odnoszę wrażenie, że jest wręcz odwrotnie - chciałoby się stworzyć
> coś, co obsłuży całą komunikację w złożonym systemie, ale w praktyce
> nie bardzo wychodzi...
>
> Weźmy za przykład jakiś serwis internetowy: interfejs użytkownika [IU]
> (w przeglądarce) gada z aplikacją [AP] po stronie serwera przez HTML,
> JSON itp, aplikacja z bazami danych [BD] przez SQL, ODBC itp.,

A jesli sa tez inne zrodla danych? A jezeli interfejsow jest kilka
(mobile, desktop, przegladarka, arkusze kalkulacyjne itd itp).
A jezeli te poszczegolne komponenty sa tworzone przez rozne zespoly i
harmonogramy wydawania wersji sa niezsynchronizowane?

> bazy
> danych replikują dane między sobą za pomocą własnych protokołów,

A jesli w systemie jest kilka roznych RDBMS?

> aplikacje zarządzające treścią [AZT] łączą się z [AP] np. przez SOAP
> itd.

Pod warunkiem, ze:
1. obie strony rozumieja SOAP
2. pod warunkiem ze obie strony posluguja sie tym samym modelem danych
(schema)

A jezeli aplikacji jest wiecej?

>
> A teraz jak by to wyglądało z ESB (gdybam, bo się nie znam, jestem
> tylko po pobieżnej lekturze strony na wikipedii
> http://en.wikipedia.org/wiki/Enterprise_service_bus)
:
> [IU] gada z ESB przez HTML i JSON, warstwa ESB konwertuje to np.
> na .NET i przekazuje do [AP], [AP] śle zapytanie do ESB, które
> konwertuje je do ODBC lub SQL i przekazuje do [BD], itd...
> Mamy warstwę pośrednią, dzięki której komponent nie musi znać języka,
> w którym komunikuje się jego rozmówca po drugiej stronie ESB, ale nadal
> każdy gada do ESB w takim języku, jaki mu najlepiej pasuje, bo nie da
> się użyć tego samego protokołu do komunikacji z przeglądarką
> internetową, monitorowania dostępności aplikacji, replikacji bazy
> danych...
>

No wlasnie dokladnie to tak dziala. Ale zeby to bylo mozliwe to ESB musi
sie umiec komunikowac z systemami zewn. Robi to przy pomocy wtyczek. A
wtyczki sa tworzone w _jednym_ jezyku - specyficznym dla ESB.

--
Michal

do góry

Użytkownik "Michal Kleczek" <m...@k...org> napisał:

> Kazda z powyzszych wprowadza ten jeden wspolny jezyk, o ktorym wlasnie pisalem.

Nie rozumiem? Mozesz precyzyjniej wyjasnic ?
Kazde z nich umozliwia m.in. uzyskanie wspolnego API bez wzgledu na
jezyk prog. (czyli dla kazdego uzywanego jezyka prog.).
Napewno nie wpowadza zadnego dodatkowego wspolnego jezyka.

AK

do góry

On 19/02/2013 09:44, AK wrote:
>
> Jaki mlyn ? Jakie spagetti ?
> Na palcach zaledwie jednej reki mozna policzyc dojrzale
> wieloplatformowo/wielojezykowe
> komponentowe technologie softwareowe.
> 1. CORBA (dosc ulomna w sesnie wielojezykowosci/latwosci uzytowania,
> b.dobra
> w sensie wydajnosci).
> 2. COM/DCOM/ActiveX - bardzo dojrzala
> 3. .NET - jeszcze bardziej dojrzala

EJB i alternatywy na Javę (Spring) są co najmniej tak samo
wieloplatformowe co .NET.

Problem jednak taki, że w wielu systemach z dobrych powodów nie stosuje
się "technologii komponentowych" albo przynajmniej uzupełnia się je
dodatkowymi metodami i protokołami komunikacji - asynchronous messaging,
REST, różne formaty reprezentacji danych itd. W sumie spaghetti może się
zrobić jak najbardziej.

do góry

Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:

> EJB i alternatywy na Javę (Spring) są co najmniej tak samo wieloplatformowe co
.NET.

Nie, gdyz zmuszaja do uzycie tylko jednego "jedynie slusznego" jezyka prog,
a _to wlasnie_ jest kompletnie bez sensu.
COM/.NET jest tu daleko do przodu.

> Problem jednak taki, że w wielu systemach z dobrych powodów nie stosuje się
"technologii
> komponentowych"

W zdecydowanej wiekszosci przypadkow nie widze _zadnych_ sensownych
powodow nieuzywania ich.

> albo przynajmniej uzupełnia się je dodatkowymi metodami i protokołami
> komunikacji - asynchronous messaging, REST, różne formaty reprezentacji danych
itd.

No wlasnie _to_ w zdecydowanej wiekszosci przypadkow jest bez sensu.
Zatrzymanie sie na etapie protokolow i formatow (itp _technicznych_ wylacznie
pier..łek) to zwyczajny krok wstecz w stosunku do naturalnej dla jezykow
programowania
(i nie tylko) idei APIs

> W sumie spaghetti może się zrobić jak najbardziej.

To prawda ze czlowiek jest mistrzem w bezsensownym mnozeniu sobie problemow :)

AK

do góry

On 21/02/2013 08:34, AK wrote:
> Użytkownik "Andrzej Jarzabek" <a...@g...com> napisał:
>
>> EJB i alternatywy na Javę (Spring) są co najmniej tak samo
>> wieloplatformowe co .NET.
>
> Nie, gdyz zmuszaja do uzycie tylko jednego "jedynie slusznego" jezyka prog,
> a _to wlasnie_ jest kompletnie bez sensu.
> COM/.NET jest tu daleko do przodu.

EJB-y można tworzyć na pewno w Scali i w Groovy, więc nie wiem, czy tak
znowu daleko.

>> Problem jednak taki, że w wielu systemach z dobrych powodów nie
>> stosuje się "technologii komponentowych"
>
> W zdecydowanej wiekszosci przypadkow nie widze _zadnych_ sensownych
> powodow nieuzywania ich.

Ależ są - choćby koszta integracji z aplikacjami/komponentami nie
używającymi ich. Poza tym np. kwestie wydajnościowe.

do góry

On 2013-02-19 17:16, AK wrote:
> Użytkownik "Michal Kleczek" <m...@k...org> napisał:
>
>> Kazda z powyzszych wprowadza ten jeden wspolny jezyk, o ktorym wlasnie
>> pisalem.
>
> Nie rozumiem? Mozesz precyzyjniej wyjasnic ?
> Kazde z nich umozliwia m.in. uzyskanie wspolnego API bez wzgledu na
> jezyk prog. (czyli dla kazdego uzywanego jezyka prog.).

A to API to w jakim jezyku jest zdefiniowane?

> Napewno nie wpowadza zadnego dodatkowego wspolnego jezyka.
>

IDL?
CLI?

--
Michal

do góry

W dniu niedziela, 27 stycznia 2013 22:28:51 UTC+1 użytkownik Wojciech Muła napisał:

> Ale jak napisałem, to tylko wrażenie. Czy znacie publikacje
> analizujące zależność defektów programów od języka?

Nie wiem, do czego to przypiąć, bo w tym wątku w kilku miejscach była mowa np. o tym,
że języki dynamiczne pozwalają na to i owo, np. na serializację obiektów w locie,
ładowanie kodu, itd.

Może to kogoś zainteresuje:

http://www.kalzumeus.com/2013/01/31/what-the-rails-s
ecurity-issue-means-for-your-startup/

Jeśli się komuś nie chce czytać, to chodzi właśnie o ładowanie czegoś w locie.

Języki dynamiczne dają "wolność do", podczas gdy statyczne dają "wolność od".
Jedno lub drugie może być pożądane, w zależności od potrzeb.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry