nicht angemeldet
Hi,
Du müsstest es sehr viel detaillierter beschreiben (am besten auch mit graphischer Unterstützung), bis ich eine Beurteilung wagen würde.
nun, ich bin noch in der Pre-Planungsphase. ;-)
Also, diese Auskunftskomponente, die hat Webanwendungen und rich clients als Abnehmer. Und die liefert ihre Leistung entweder sofort oder spaeter. Das mit dem sofort ist kein Problem, da kaeme dann ein wie auch immer gearteter Webservice ("low level" oder SOAP) in Frage.
Die besondere Herausforderung besteht m.E. in den asynchron zu bearbeitenden Requests der Webanwendung oder des rich clients. Bei genauerer Uberlegung geht es um die rich clients, VB6 Prograemmchen zum Beispiel. Diese koennten von einer zweiten Komponente ueber den Eingang einer Auskunft benachrichtigt werden (mittels einer TCP/IP-irgendwas Loesung, auch auf dem Austausch von XML-Dokumenten basierend). Alternativ koennte man fordern, dass die rich clients halt immer wieder mal anfragen muessen, ob was gekommen ist.
Und da weiss ich nicht so recht, was ich machen soll. Die TCP/IP Komponente will ich zum Beispiel nicht, das Pullen der rich clients macht mich nicht ganz happy und ein server push auf HTTP(S)-Ebene geht nicht.
Auf den ersten Blick springen mir allerdings einige Begriffe entgegen, die Du nicht erwähnst und von denen ich daher annehme, dass sie Dir helfen könnten, nämlich vor allem Web Services (Stichwort z.B. WSDL) und Long bzw. Unknown Duration Transactions.
Ja, das mit den transactions hoert sich ganz gut an. Wie bearbeitet man also "profikorrekt" solche Anforderungslagen. Kommt man da mit Warteschlangen oder sowas? MSMQ faellt mir da so ein, will ich aber nicht. WSDL ist doch die Sprache mit denen diese XML-Proxies generiert werden koennen, oder?
Gruss,
Ludger