none
ESB Szenario Question

    Allgemeine Diskussion

  • I watched all these exciting presentations (esp. from Brian Loesgen) and my thoughts are really positive and enthusiastic ... so far. We are BizTalk newbies and decided to move to BizTalk by using the ESB for all the reasons ESB has been developed for. We have an existing app but we need to modernize and need something alike ESB and BizTalk.

    Then we tried to install all that jazz to run the examples for getting a good feeling ... sadly we still stuck somewhere mainly due the nasty 64 bit szenario we have to cope with (target machine is 64 bit and we have a rule to develop on machines similar to the target machines). We still are in hope that the problems will disappear soon.

    BUT yesterday we had a live discussion with two consultants from Microsoft (there are not that many here in Germany ... esp. knowing ESB well ... and so they are mainly BizTalkers) about the theme and first of all they pretended that our approach is just fine (extremely fine). Later on after some hours of discussion they told us that we better should not use BizTalk (and ESB) but (after I asked) eventually move to WF or alike as they suspected extreme problems with performance. But they admitted that this is just a guess (from their BizTalk history and ESB is ontop of that BizTalk).

    So maybe you guys have another guess as I cannot believe what I have heard. Here is our approach:

    We learned that ESB has to do with creating a kind of "Bus Language" (vocab) where one can (!!!) formulate all (!!!) the business rules of the system (we have an online web shop system using Commerce Server). For example some component might ask the ESB "hey what kinds of payment methods do you support NOW" and the ESB shall answer by collecting the answers from all configured payment providers (dynamically of course). After displaying these to the user (web) and letting him select one the ESB is asked for the parameters this selected payment provider needs (like CC number and alike) which is send to the web frontend, filled out and delivered (by the ESB) to the respective provider as the user hit the "Pay Now" button. Of course this is kinda synchroneous call as the user is waiting for the action. To sum up: I'd like to see ESB as the "living environment" of my "business objects" like a object space fed by the attached providers.

    The consultants now told us that BizTalk is not really designed for this and shall mostly be seen as "extreme asynchrouneous polling" machine. They expect major problems with the performance but they seemed to be really unsure at all.

    Any expectations and thoughts of you guys are welcome ... or shall I bury by (weird) vision.

    --Jörn

     

    Donnerstag, 22. Juli 2010 06:44

Alle Antworten

  • Hi Jörn,

    we didn't use ESB here, but we have some experience with synchronous interfaces realizes with BizTalk.

    In general there is no performance problem when making massive use of synchronous interfaces. If you have a look at the BizTalk internals it's quite obvious that there is no reason they could force some kind of performance issue. Sure you'll need a bit more memory (open connections) and BizTalk makes internally a lot of use of correlations etc., but this souldn't be a reason for any upcoming problems.

    Although there are a few design descisions to consider when starting with BizTalk. But this is more BizTalk specfic and not really up to the ESB.

     

    BUT - you describe more or less services (what payments are available), so that's in my mind not the real purpose of BizTalk. For this I would use self written services hosted in Windows Server AppFabric. BizTalk is more or less used for just communication and not for offering such services by its own. If you need to communicate with external companies (for the payment to be done), this is what BizTalk is used for.

    As I'm from Germany as well, you can contact me via Email or Phone so that I might answer you a few questions. From a more practical point of view than the Microsoft guys normally do. Use the data on my Blog / About page or XING to contact me if you like.


    If you like my post or consider it as a valid answer, please use the buttons to show me - Oliver

    http://biztalk.hauth.me

    Donnerstag, 22. Juli 2010 07:21
  • Hallo Jörn,

    Hallo Oliver,

    wir sind hier bei MSDN Deutschland. Die Sprache für Postings ist Deutsch.

    Jörn,

    ich werde nicht ganz schlau, was wollt Ihr mit dem BizTalk bzw. ESB Toolkit machen? Bitte etwas detaillierter.

    >>and decided to move to BizTalk by using the ESB for all the reasons ESB has been developed for.

    Das ESB Toolkit ist ein Baukasten, es gibt wenig was man nicht damit machen kann. Allerdings hab ich noch nicht gehört, das sich jemand für den BizTalk Server entschieden hat, nur wegen dem Toolkit. Dafür ist die Angelegenheit dann auch viel zu teuer.

    Schöne Grüße

    Oliver

    Donnerstag, 22. Juli 2010 13:44
  • Tja, wenn wir denn hier in Deutschland sind (ich habe es gar nicht gemerkt, oder besser ich wollte eigentlich über den Teich rüber, weil die Microsofties sagten, dass hier bei uns keiner da im Thema ist), dann versuche ich nochmal ein paar Details.

    Warum BizTalk? Unser App ist schon zusehens in einem Konzert von diesen typischen Enterprise-"Komponenten" wie SAP und CRM und derartigem unterwegs und wir könnten das sicher noch viel weiter expandieren, wenn es denn möglich wäre (allein vom Aufwand gesehen). Entsprechend sind die Kosten, derartige Systeme anzusprechen oder zu orchestrieren (je wie man es sieht) nicht ganz vernachlässigbar. Rechnet man dagegen einen BizTalk, der faktisch dann auch von allen Partnern einzusetzen wäre (würde) bekommt man strategische Dimensionen für den Kunden und die Kosten/Nutzenfrage kippt mit den ganzen fertigen Adaptoren sowieso. Bleibt quasi nur noch das aus meiner Sicht recht resourcenhungrige Auftreten des Systems. Fragt man doch eher: warum NICHT BizTalk?

    Warum ESB? Ich habe verstanden, dass Biztalk für sich ein Stück weg wie eine Art "Assembler" darstellt (etwas schief das Bild), wo man viel machen kann, aber dann auch damit leben darf, dass sich das ganze konzeptionell zerfasert - jedem Entwickler sein Höckchen und Stöckchen (weil es geht ja auch so). ESB ist für mich die Schicht abstrakter (schade dass einige Pattern noch erfordern wieder in die "Niederungen" zu gehen) die auch das Deployment betrifft und vermeindlich Fachanwender-Näher. Insbesondere wenn man versucht eine unternehmensspezifische Bussprache zu definieren, könnte man viel erschlagen, was sonst keiner zu denken wagt. Ja geht in Richtung WF. Fragt man wiederum: Warum denn NICHT ESB?

    Mag sein, dass genau aus dieser meiner Biztalk-Distanz (Unerfahrenheit) ich die "übliche Art" (Paradigmen) wie man das Teil wohl verwendet schlichtweg ignoriert habe und meine Vision in die oben (erstes Posting) Richtung zu "denken". Wie ich schon schrieb: eher sowas wie eine Art "object space" oder vielleicht besser eine Art "rule based expert system" mit blackboard, dem man in der "Bussprache" Anforderungen formuliert und welches sich dann dynamisch je nach angeschlossenen Experten (und natürlich vorgegebener BL) reagiert. Für mich aber PubSub pur oder besser genau das wie ich die Essenz von BizTalk verstanden habe ... bisher ... nicht als "nur" transaktionales Datenschaufeln mit eingebautem Monitoring garniert mit wenig BL. Das wurde dann auch von den Microsoft-Consultants verstanden.

    Mir geht es nun darum, wie oder besser ob ich meine Vision umsetzen kann. Muss ich z.B. gar zusätzlich auf die AppFabric umschwenken (@Oliver: hab ich mir auf deinen Hinweis genauer angeschaut ... nett) und BizTalk zum Adaptor-Orchestrierer "degradieren", weil eben BizTalk für sowas zu träge ist (skaliert nicht so pralle) oder noch schimmer einfach ungeeignet. Drum dieser Thread um die Erwartungshaltung zu schärfen.

    Genug?

    Schöne Grüße

    Jörn

    Donnerstag, 22. Juli 2010 19:59
  • Also das Thema Skalierung würde ich erstmal vernachlässigen, da solltest du eigentlich in keine großen Probleme laufen. Es gibt einige sehr große Installationen in den Staaten oder in Holland (DocMorris z.B. >600.000 Transaktionen pro Tag) die da keine Problem haben. Sicherlich nicht mit einem Server sondern mit einer BizTalk Farm + SQL Cluster, aber machbar ist es.

    Ob sich BizTalk bzw. ESB eignet ist eine andere Frage. Der ESB nutzt unter anderem das UDDI für den Lookup der einzelnen Services. Diese werden innerhalb des UDDI klassifiziert (wie ist völlig frei). Darüber kannst du dir problemlos einen Lookup Dienst generieren. Dann hast du "vorne" einen Dispatcher der die Nachricht erkennt, den Lookup macht und die Nachricht routet. Aber selbst innerhalb des ESB nutzt du XSDs, Maps, Orchestration etc. die dann jeder wieder machen kann wie er will. Meiner Meinung nach gewinnst du da nicht viel.

    Ich würde erstmal mit BizTalk "normal" starten und sehen, wohin es gehen soll. Eine Art Prototyp Phase. Es gibt mit BizTalk schon einige Eigenheiten, die man erstmal kennen sollte, bevor man sich auf Stufe 2 begibt. Beispiele hier sind: SAP Anbindung oder auch die Lösung einiger Problemlösungen wie Convoys, eigene Pipeline Komponenten etc.

    Weil: Einen generischen Dispatcher kannst du auch mit klassischem BizTalk schreiben und den UDDI Lookup kannst du über WCF realisieren. Dafür alleine brauchst du noch kein ESB.

    Wenn dir dann Dinge fehlen wie Internarari.. (wie auch immer, du weißt schon) oder das Portal, dann kann man das immer noch installieren.

    Ein Punkt ist das globale Exceptionhandling. Darüber ließe sich diskutieren. Aber auch da gibt es gute "Out of the box" Lösungen.

    Was du niemals unterschätzen darfst. BizTalk ansich ist sehr mächtig und komplex. Mit ESB wird es um einiges komplexer. Ich habe immer die Erfahrung gemacht, dass man BizTalk Fehler noch sehr gut finden und ausmerzen kann (auch Systemfehler). Ich bin mir nicht sicher, ob das ganze Datenmodell usw. mit ESB nicht so komplex wird, dass es dich - gerade als Anfänger - überfordert.

    Klar ist ein ESB ein Messaging Bus und BizTalk ansich erstmal nur ein EAI / SOA Routing / Workflow Tool. Trotzdem würde ich nicht direkt auf den ESB gehen.

     

    Wie gesagt, mit mehr Hintergrundwissen, wie deine eigentlichen Prozesse aussehen, lässt sich da sicher mehr sagen.

    PS: Keine Sorge, ich bin kein Berater :)

     

    Und lass dir nicht sagen, es gibt in Deutschland keinen, der sich mit dem Thema auskennt.

    Aber wenn du in die US Forum willst, stell oben rechts im MSDN auf EN-US um.

     

     


    If you like my post or consider it as a valid answer, please use the buttons to show me - Oliver

    http://biztalk.hauth.me

    Freitag, 23. Juli 2010 04:52
  • Hallo zusammen,
     
    Kann mich meinem Kollegen anschliessen, ich würde bei Eintritt in die neue Technologie Biztalk das ESB Framework eher mal aussen vor lassen - das ist m. E. nach von der Komplexität her schon deutlich zu heftig...
     
    Wir haben schon Lösungen im Einsatz, bei denen BizTalk Online Services in Backend Systeme (SAP) für SharePoint Portale bereitstellt. Dabei ist etwas zu feilen, um so ein "Low-Latency Szenario" abzudecken (siehe auch http://msdn.microsoft.com/en-us/library/cc594552%28BTS.10%29.aspx , dabei Low-Latency Scenarios).
     
    Grundsätzlich ist durch die Architektur des Biztalk Servers immer eine höhere Latenz gegeben, man hat aber dafür ggf. andere Vorteile (z. B. Einbringen von Sicherheitsschichten durch Hosts in die Lösung, Tracking / BAM).
     
    Interessant wird es sicherlich, wenn der BizTalk Server eine einheitliche WebService Sicht für unterschiedliche Backend Systeme anbietet und intern das Routing / Consolidieren der Services vornimmt. Auch da haben wir schon erfolgreiche Projekte gemacht.
     
    Grüße
     
    Jörg
     
    "SharePoint is the Future" schrieb im Newsbeitrag news:f255c100-0b3a-4fe2-b6c8-b0652df21e69...

    Tja, wenn wir denn hier in Deutschland sind (ich habe es gar nicht gemerkt, oder besser ich wollte eigentlich über den Teich rüber, weil die Microsofties sagten, dass hier bei uns keiner da im Thema ist), dann versuche ich nochmal ein paar Details.

    Warum BizTalk? Unser App ist schon zusehens in einem Konzert von diesen typischen Enterprise-"Komponenten" wie SAP und CRM und derartigem unterwegs und wir könnten das sicher noch viel weiter expandieren, wenn es denn möglich wäre (allein vom Aufwand gesehen). Entsprechend sind die Kosten, derartige Systeme anzusprechen oder zu orchestrieren (je wie man es sieht) nicht ganz vernachlässigbar. Rechnet man dagegen einen BizTalk, der faktisch dann auch von allen Partnern einzusetzen wäre (würde) bekommt man strategische Dimensionen für den Kunden und die Kosten/Nutzenfrage kippt mit den ganzen fertigen Adaptoren sowieso. Bleibt quasi nur noch das aus meiner Sicht recht resourcenhungrige Auftreten des Systems. Fragt man doch eher: warum NICHT BizTalk?

    Warum ESB? Ich habe verstanden, dass Biztalk für sich ein Stück weg wie eine Art "Assembler" darstellt (etwas schief das Bild), wo man viel machen kann, aber dann auch damit leben darf, dass sich das ganze konzeptionell zerfasert - jedem Entwickler sein Höckchen und Stöckchen (weil es geht ja auch so). ESB ist für mich die Schicht abstrakter (schade dass einige Pattern noch erfordern wieder in die "Niederungen" zu gehen) die auch das Deployment betrifft und vermeindlich Fachanwender-Näher. Insbesondere wenn man versucht eine unternehmensspezifische Bussprache zu definieren, könnte man viel erschlagen, was sonst keiner zu denken wagt. Ja geht in Richtung WF. Fragt man wiederum: Warum denn NICHT ESB?

    Mag sein, dass genau aus dieser meiner Biztalk-Distanz (Unerfahrenheit) ich die "übliche Art" (Paradigmen) wie man das Teil wohl verwendet schlichtweg ignoriert habe und meine Vision in die oben (erstes Posting) Richtung zu "denken". Wie ich schon schrieb: eher sowas wie eine Art "object space" oder vielleicht besser eine Art "rule based expert system" mit blackboard, dem man in der "Bussprache" Anforderungen formuliert und welches sich dann dynamisch je nach angeschlossenen Experten (und natürlich vorgegebener BL) reagiert. Für mich aber PubSub pur oder besser genau das wie ich die Essenz von BizTalk verstanden habe ... bisher ... nicht als "nur" transaktionales Datenschaufeln mit eingebautem Monitoring garniert mit wenig BL. Das wurde dann auch von den Microsoft-Consultants verstanden.

    Mir geht es nun darum, wie oder besser ob ich meine Vision umsetzen kann. Muss ich z.B. gar zusätzlich auf die AppFabric umschwenken (@Oliver: hab ich mir auf deinen Hinweis genauer angeschaut ... nett) und BizTalk zum Adaptor-Orchestrierer "degradieren", weil eben BizTalk für sowas zu träge ist (skaliert nicht so pralle) oder noch schimmer einfach ungeeignet. Drum dieser Thread um die Erwartungshaltung zu schärfen.

    Genug?

    Schöne Grüße

    Jörn


    Jörg Fischer
    Dienstag, 3. August 2010 12:18
    Moderator
  • Ich wollte mal nachfragen, ob sich das Thema bei dir nun geklärt hat oder ob noch Fragen offen sind.

    Falls ihr euch entschieden habt, darf man fragen, welchen Weg ihr nun geht?


    If you like my post or consider it as a valid answer, please use the buttons to show me - Oliver

    http://biztalk.hauth.me

    Mittwoch, 4. August 2010 19:41