Architektur: Webservice entwerfen
Hallo zusammen,
jetzt heißt es für mich Werbedienste entwerfen.
Es soll ein Bestellsystem werden, nur stehe ich gerade auf dem Schlauch.
Ich möchte folgende Funktionen implementieren,
- Anmeldung, wer bin ich
- Bestellung Haupteigenschaften (Datum, meine Bestellnummer, Lieferanschrift, ...)
- Positionen zur Bestellung hinzufügen
Wird nun die ganze Bestellung in ein Objekt gepackt oder mache ich im meinem Webservice mehrer Funktionen.
Vielen Dank für eure Mühe im Voraus
LastGentleman
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
Original von LastGentleman
Hallo zusammen,
[...]
Ich möchte folgende Funktionen implementieren,
- Anmeldung, wer bin ich
Mit Session-Mangement?
- Bestellung Haupteigenschaften (Datum, meine Bestellnummer, Lieferanschrift, ...)
Erstell auf dem WebService eine "Bestellung" Fachklasse z.B. Order und pack dort alle relevanten Attribute rein. Der WS Consumer kann dann ebenfalls auf die Fachklasse zugreifen.
- Positionen zur Bestellung hinzufügen
Quasi ein Update auf vorhandene Bestellungen?
moq
Webdienste sind statuslos. Das bedeutet, dass sie (sehen wir vom Sitzungsstatus mal ab) zwischen zwei Methodenaufrufen alles vergessen. In kleinen Häppchen zu arbeiten ist also fehl am Platz.
Also ++**nicht **++so:
public Interface IOrderWebService
{
int CreateOrder(Customer customer, string customersDocumentNo);
int InsertItem(int orderID,OrderItem item);
}
Sondern so:
public Interface IOrderWebService
{
int CreateOrder(OrderDocument order);
}
Statt vieler kleiner Funktionen mit vielen Paramatern, eine dicke Funktion mit einem Dokument als Paramater. Als Dokumente eignen sich Objekte oder DataSets, die mit XML-Attributen versehen sind und einem XML-Schema genügen. Das OrderDocument würde also die kopfdaten und sämtliche Positionen der Bestellung beinhalten. Die CreateOrder-Funktion würde das eigende OrderDocument prüfen (validieren) und wenn alles ok ist, alles innerhalb einer Transaktion verbuchen.
Der Client des Webdienstes bereitet ein komplettes Dokument fix und fertig vor und schickt es dann zum verbuchen an den Webdienst. Bei häppchenweiser Verarbeitung hast Du auch Probleme alles in eine Transaktion zu fassen.
Danke moq
Erstell auf dem WebService eine "Bestellung" Fachklasse z.B. Order und pack dort alle relevanten Attribute rein. Der WS Consumer kann dann ebenfalls auf die Fachklasse zugreifen.
Quasi ein Update auf vorhandene Bestellungen?
Technisch gesehen würde das so aussehen, es gibt eine Login Klasse, wo ASP.Net in den Session Variablen das Passwort und den Benutzernamen hält.
Falls dies nicht gegeben ist, dann erzeugt eine Exception.
Mein Webdienst liefert mir beim Bestellung erstellen eine Liste von Detailpositionen zurück die ich wieder um lokal verändern und Zeilen anfügen kann und mittels einer Update-Funktion wieder in meine DB speichern.
Ich hoffe ich hab es richtig verstanden?
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
Hallo Rainbird,
danke auch für deinen Beitrag, deine Variante gefällt mir besser weil sie mehr dem SOA Prinzip entspricht.
Kurze Frage am rande würdet ihr die Benuzerdate auch in das Dokument packen?
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
Ich würde auch die Identität des Benutzers ins Dokuemnt packen. Schließlich ist das Dokument als kompletter Arbeitsauftrag für den Dienst anzusehen.
Die Identität sollte aber gegen die technische Identität des Aufrufers (Credentials) gegen geprüft werden. Damit Bob nicht im Namen von Alice eine Bestellung einbuchen kann (es sei denn das Sicherheitssystem implement eine Vertreterregelung 😉).
Die Identität sollte aber gegen die technische Identität des Aufrufers (Credentials) gegen geprüft werden. Damit Bob nicht im Namen von Alice eine Bestellung einbuchen kann (es sei denn das Sicherheitssystem implement eine Vertreterregelung 😉).
Das bedeutet also das die man separat noch dazu die Credentials des Service aufrufers prüfen sollte?
"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein
Ich würde mir ein eigenes Session-Mangement erstellen und wie Rainbird es angedeutet hat jeglich auf Methoden mit "großen" Parametern setzen.
Je nachdem was du noch für Funktionen implementieren möchtest/musst wäre es so leichter Benutzerbezogene Aufgaben zu erledigen. (Bsp. Passwort ändern / ...).
Der Nachteil dabei wäre allerdings das sich der Code teilweise künstlich aufbläht und jede Methode einen zusätzlichen Parameter bekommt. (-> eindeutige Nummer anhand die Consumer unterscheidbar sind).
[WebMethod]
public int Login(string username, string pwSHA1, string guid)
{
if(....)
{
SessionData data = new SessionData();
data.Username = username;
data.ExpirationDate = DateTime.Now.AddMinutes(30).ToLongTimeString();
data.XYZ = value;
data.IsLoggedIn = true;
SaveSession(guid, data);
return 0;
}
return -1;
}
[WebMethod]
public string GetUserName(string guid)
{
SessionData data = FindSession(guid);
return data.Username;
}
[WebMethod]
public int CreateOrder(OrderDocument order, string guid)
{
SessionData data = FindSession(guid);
(....)
}
Was sagt Herr Rainbird zu der o.g. Methodik?
Original von moq
Was sagt Herr Rainbird zu der o.g. Methodik?
Das funktioniert bestimmt gut.
Ich verwende allerdings lieber die eingebauten Sitzungs- und Authentifizierungswerkzeuge. Der Basisklasse Webservice stellt beides über die Eigenschaften User und Session zur Verfügung.
Natürlich passen die fertigen Sachen nicht immer optimal. Deshalb kann eine eigene Sitzungsverwaltung eine Alternative sein. Ich würde aber erst eine eigene Sitzungsverwaltung implementieren, nachdem ich die Standard-Tools auf Herz und Nieren geprüft und für unpassend befunden hätte. Erfahrungsgemäß fährt man mit den eingebauten Features nicht schlecht.