Webservice w Lazarusie – proszę o kontakt, jeśli ktoś robił podobny projekt

0

Witam,

Mam aplikację napisaną w Lazarusie i chciałbym ją udostępnić moim klientom. Aplikacja korzysta z bazy danych MS SQL i chicałbym żeby klienci również mieli dostęp do niektórych danych. W tym celu chciałbym zaimplementować do niej moduł hosta i klienta. Klient wysyła zapytanie pod konkretny adres internetowy IP (niezmienny) host nasłuchuje na wybranym porcie, dokonuje autoryzacji zapytania (sprawdza NIP klienta oraz podane hasło) i po poprawnej autoryzacji zwraca klientowi wynik zapytania w formie pliku xml.
Z braku czasu chętnie zleciłbym wykonanie w/w modułów tak bym mógł je sam zaimplementować do mojej aplikacji. Jeśli ktoś robił już podobny projekt będę wdzięczny za kontakt.
Pozdrawiam

0

Napisze Ci to od ręki (tylko kiedy ja znajdę na to czas, hmm...), więcej to pewnie będzie instalacja Lazarusa trwała :D
Tylko, że:

  1. To co opisałeś, to nie jest WebService tylko XML-RPC, jeśli już.
  2. Skoro tak, to dlaczego nie REST?
  3. Dane w formie JSON niż XML; szybciej, prościej, mniej danych, no lepiej po prostu...

I nie daj się wrobić w jakieś pisanie Sewerów na ICS/Synapse/Indy itd.
Szkoda prądu i zachodu, skoro pod ręką jest doskonały mORMot.

0

Witam,

Tak jak napisałem, nie mam doświadczenia w temacie aplikacji komunikujących się przez internet.
Chciałbym koniecznie zaimplementować to do aplikacji na PC a nie tworzyć to np. w PHP .
Właśnie zastanawiałem się czy aby na pewno potrzebuję tutaj Webservice skoro komunikacja ma się odbywać między dwoma takimi samymi aplikacjami. (różniły się będą jedynie funkcjonalnością)
Wiem że Json jest bardziej uniwersalny, ale z uwagi na fakt że wszystko mam robione w xml wolę pozostać przy xml (jego struktura jest bardziej czytelna i łatwiej wyłapać ewentualne błędy)

Napisz na priv jak byś to widział.

Pozdrawiam

0

jeśli z jakichś powodów potrzebujesz XML do innych części systemu to użycie mORMota nadal wchodzi w rachubę - ewentualna konwersja JSON do XML (i odwrotnie) za pomocą dodatkowych modułów z Node.js:

https://www.npmjs.com/package/xmltojson
https://www.npmjs.com/package/jsontoxml

lub

https://www.npmjs.com/package/xml-js

są uruchamialne za pomocą SyNode z mORMota. XML może być dobry dla części gdzie się komunikujesz z innymi systemami/częścią swojego systemu które nie przyjmą innych danych. Używanie JSONa w mORMocie odbywa się często tak, że praktycznie nie wiesz, że go używasz ;).

0
hnb napisał(a):

jeśli z jakichś powodów potrzebujesz XML do innych części systemu to użycie mORMota nadal wchodzi w rachubę - ewentualna konwersja JSON do XML (i odwrotnie) za pomocą dodatkowych modułów z Node.js:

https://www.npmjs.com/package/xmltojson
https://www.npmjs.com/package/jsontoxml

lub

https://www.npmjs.com/package/xml-js

Tak, tak... żeby dojechać do sklepu też zamawiasz statek pełnomorski? ;-)

są uruchamialne za pomocą SyNode z mORMota. XML może być dobry dla części gdzie się komunikujesz z innymi systemami/częścią swojego systemu które nie przyjmą innych danych.

Wszystko pięknie ładnie, ale to akurat bez sensu w mormocie.
Wystarczy wiedzieć co ma na pokładzie (rozumiem, to wcale nie jest takie proste przy tym projekcie ze względu na jego ogrom i złożoność) i po prostu użyć.
http://blog.synopse.info/post/2014/08/05/mORMot-SOA-returns-XML

Używanie JSONa w mORMocie odbywa się często tak, że praktycznie nie wiesz, że go używasz ;).

Pełna zgoda.

0

Wspomniana technologia konwersji JSON do XML wbudowana w mORMota nie do końca działa w sposób oczekiwany a użycie wspomnianych paczek daje lepsze (w sensie bardziej poprawne) rezultaty. Jeśli nie ma dużych obciążeń ww technologia jest w porządku. Koniec kropka.

0
hnb napisał(a):

Wspomniana technologia konwersji JSON do XML wbudowana w mORMota nie do końca działa w sposób oczekiwany

A jaki jest ten oczekiwany sposób?
Imo działa zgodnie z konwencją, a więc nie rozumiem...

a użycie wspomnianych paczek daje lepsze (w sensie bardziej poprawne) rezultaty. Jeśli nie ma dużych obciążeń ww technologia jest w porządku.

Osobiście nie lubię używać czegoś zewnętrznego, jeśli nie muszę. Zawsze z tym (prędzej czy później) kłopot jest. Inna sprawa, jak ktoś ma jeden hosting na własny serwer, a inna kiedy ma się n klientów a każdy ma inne wymagania/infrastrukturę itd.
Tak czy siak, im mniej zależności w instalce, tym lepiej.

No i w jakim sensie owe rezultaty są bardziej poprawne albo dlaczego te które produkuje JSONBufferToXML nie są poprawne?
Pytam, bo nie wiem.
Rozumiem, że ten XML jest prosty - ale taki powinien być.
Ważne, ze jest poprawny (tj. well-formed) i to też jest OK.

Koniec i kropka.

Nie skomentuję.

0

Jest problem z atrybutami. Jak zauważyłeś mORMot ma uproszczony XML. Odczyt z XML nie istnieje. Nie musisz komentować moich postów - na pewno będę za to wdzięczny, odpisywanie na Twoje elaboraty "obnażające niewiedzę" jest po prostu męczące i irytujące.

0

Mam pytanie odnośnie mORMot . Dzięki koledze z forum mam przykładowe aplikacje klienta i hosta. Obie te aplikacje korzystają ze współdzielonych .pas. Moje pytanie brzmi czy musi tak być. Chciałbym aby zarówno host jak i klient znajdował się w tej samej aplikacji i w zależności od sytuacji uruchamiać aplikację jako hosta lub jako klienta.

1
Wujek74 napisał(a):

Mam pytanie odnośnie mORMot . Dzięki koledze z forum mam przykładowe aplikacje klienta i hosta. Obie te aplikacje korzystają ze współdzielonych .pas. Moje pytanie brzmi czy musi tak być.

Co do zasady i samego modułu, to nie musi tak być, ale...
Jeśli posługujesz się zdefiniowanymi typami danych (klasy, rekordy, itd.) do komunikacji klient-serwer, to zarówno serwer jak i klient musi te deklaracje typów znać.
I stąd ten współdzielony moduł przez serwer i klienta.
Jednakże możesz po prostu przesyłać czyste dane z serwera do klienta, npp. w postaci JSON.
Wtedy nie musisz współdzielić modułu z typami danych, ale to niewygodne, błędogenne itd.
Nie polecam.

Chciałbym aby zarówno host jak i klient znajdował się w tej samej aplikacji i w zależności od sytuacji uruchamiać aplikację jako hosta lub jako klienta.

No i w czym problem?

0

Geniuszu, obiekty klas serializuje się do json i klient niczego więcej nie musi znać, wystarczy że , zdeserializuje dane po swojej stronie

0

Witam,

Mam już upchnięte oba moduły w jednym programie łącznie z zawartością współdzielonych plików. Przesyłanie danych z hosta do klienta działa jednakże nie mogę pobrać danych z servera sql (MSSQL 2016), wywala mi serie błędów: https://www.dropbox.com/s/5iky6zm055o380k/b%C5%82%C4%99dy.png?dl=0
Mam też pytanie czy przy wyciąganiu danych z servera sql można korzystać z ZEOS. Jeśli nie można korzystać z ZEOS to jak podłączyć się do serwera MSSQL 2016?

procedure TCitiesService.GetCities(const Name: RawUTF8; out Cities: TDTOCities);
begin 
  FConnection := TOleDBMSSQL2012ConnectionProperties.Create('serwersql','Baza','Uzytkownik', 'Haslo');
  FSQLDBRows := FConnection.Execute('SELECT nr_zamowienia, nazwa_towaru FROM przyjecie_towaru WHERE data_dokumentu LIKE ?', [Name]);

  while FSQLDBRows.Step do  
  begin
    with Cities.Add do
    begin
      Name := FSQLDBRows.ColumnUTF8('nr_zamowienia');
      PostalCode := FSQLDBRows.ColumnUTF8('nazwa_towaru');
    end;
  end;
end;
0
kulson napisał(a):

Geniuszu, obiekty klas serializuje się do json

Robi "się to samo" korzystając z RTTI, a to z definicji wymaga znajomości TypeInfo, czyli typu.

i klient niczego więcej nie musi znać, wystarczy że , zdeserializuje dane po swojej stronie

Jak po stronie klienta wykonać deserializację z JSON do obiektu, kiedy klient nie zna typu obiektu, do którego ma wykonać
deserializację?

Geniuszu?

0

A wiesz, że klient może być dynamicznie typowany i może mieć głeboko w poważaniu Twoje definicje typów?

0
kolaborant napisał(a):

A wiesz, że klient może być dynamicznie typowany i może mieć głeboko w poważaniu Twoje definicje typów?

Czy ja napisałem że nie można? Odpowiedziałem na pytanie do czego ów unit służy.

Pewnie, można i zrobić sobie binding - dynamiczny, statyczny, jakikolwiek - ALE PO CO?
To trochę bez sensu...
Po co robić DTO i nie korzystać z niego?

Poza tym, chyba nie do końca wiesz jak to działa. Masz gotowy serwer oparty na interfejsch, Klient używa dokładnie tych samych typów
po prostu wywołujesz metodę i otrzymujesz wyniki.

A Ty proponujesz przepraszam co?
Ręczną rzeźbę z wywołaniem POST/GET serwera REST przez HTTP i odebraniem wyników?
A potem ten strumień "typować dynamicznie po stronie klienta"?
No można. Tylko po co?

0
wloochacz napisał(a):

A Ty proponujesz przepraszam co?
Ręczną rzeźbę z wywołaniem POST/GET serwera REST przez HTTP i odebraniem wyników?

Ty programowałeś kiedyś w czymś innym niż Delphi?

A potem ten strumień "typować dynamicznie po stronie klienta"?
No można. Tylko po co?

Mam wrażenie, że klapki na oczach Ci się zbyt mocno zacisnęły.

0
kolaborant napisał(a):
wloochacz napisał(a):

A Ty proponujesz przepraszam co?
Ręczną rzeźbę z wywołaniem POST/GET serwera REST przez HTTP i odebraniem wyników?

Ty programowałeś kiedyś w czymś innym niż Delphi?

Zdarzało mi się, ale co z tego?
Poza tym, wszędzie jest podobnie jak tu opisano.
Różni się tym jak taki kod z deklaracjami typów się generuje, czy po prostu używa.
Ale wątek dotyczy mORMota (dla Delphi/FPC), który używa po stronie serwera i klienta dokładnie tych samych typów danych.

Poza tym widziałem tonę kodu, które używały dynamicznego dostępu do danych przez wpisanie literałów w kodzie.
Pewnie, można - ale to nie jest dobre podejście.

Zdecydowanie lepiej wygenerować kod do operacji na danych, np. tak dla TypeScript:
http://json2ts.com/
lub bardzo podobnie dla Delphi:
https://jsontodelphi.com/

...albo użyć modułu z deklaracją typów DTO... o czym mowa od początku...

A potem ten strumień "typować dynamicznie po stronie klienta"?
No można. Tylko po co?

Mam wrażenie, że klapki na oczach Ci się zbyt mocno zacisnęły.

Przypomnij sobie jakie było pytanie i w jakim podało kontekście, a potem po prostu przeproś, ponieważ zagalopowałeś się i po sprawie.
Każdemu się zdarza.
Ba jak na razie nie odpowiedziałeś na żadne pytanie. Zero. Null.

1 użytkowników online, w tym zalogowanych: 0, gości: 1