Agile Development en ESB

stemmen
1

Ik ben bezig met het verschuiven van onze corporate technologische paradigma om Agile Development. Het is een harde proces, maar we zijn er bijna! :)

We hebben legacy-systemen voor onze database management (gebruikt om toegang te zijn, nu geport naar .NET en MS SQL) en we zijn het ontwikkelen van een kader voor onze toekomstvisie. We willen zo veel mogelijk te migreren naar het web. Maar we willen het huidige systeem te integreren met de komende één. We zullen niet overlappende taken en functies.

Mijn visie is om alle contact informatie over onze gebruikers te verplaatsen naar een andere database, het koppelen van de profielen terug naar de MS SQL voor hun geschiedenis en boekhoudkundige informatie. We zullen allemaal boekhoudsystemen houden op de desktop-app, maar er is nog veel meer functionaliteiten die we op het punt om toe te voegen dat zal sterk afhankelijk zijn van het internet, met name Ruby on Rails.

Ik denk dat de vraag is: waarom ESB? Is er een manier om een ​​SOA te maken zonder in te gaan gung-ho met complexe ESB-systemen. Het hele idee is om in ieder geval KISS. Kan een SOA worden gemaakt op een manier die het mogelijk maakt de desktop / web / mobiele telefoon om interfaces, het bijhouden van de functionaliteiten op de business logica (natuurlijk een aantal functionaliteiten zouden moeten worden uitgevoerd op de interface, maar houden dat tot een absoluut minimum). En vergeet ESBs zelfs past een Agile filosofie? Hoe meer ik lezen en bestuderen, hoe minder ik denk het wel! : /

Dank voor uw input mensen! Als je me nodig hebt om duidelijk te maken, gewoon een paar vragen en ik zal mijn best doen om dit te doen! :)

De vraag is gesteld op 09/12/2008 om 23:51
bron van user
In andere talen...                            


3 antwoorden

stemmen
3

ESB's sluiten goed aan bij agile wanneer het kader / infrastructuur is op zijn plaats. U zult merken dat je een nieuw systeem in stukken kunt maken, voert u de nieuwe stukken in parallel met het oude systeem voor een tijdje, en geleidelijk uitschakelen van de oude delen van het systeem tot alleen het nieuwe systeem wordt overgelaten, en niemand zal ooit weten het verschil

een basis SOA net definieert diensten in plaats van applicaties; een ESB beheert de diensten in kanalen om de eindpunten te verbergen, waardoor upgrades en vervangingen nog veel meer "agile"

antwoordde op 10/12/2008 om 00:24
bron van user

stemmen
1

Ik heb vrij snel geleerd om uit de buurt van de term "ESB" verlegen als itis zeer overbelast en dat betekent verschillende dingen voor verschillende mensen (en soms verschillende dingen aan dezelfde persoon :-))

Het belangrijkste ding, natuurlijk, is om je af te vragen wat je eigenlijk nodig.

Verpakking uw database (s) als een service is waarschijnlijk een verstandige keuze zijn, vooral als je meerdere client voor deze data; moet je een goede hoeveelheid tijd na te denken over uw contracten en scoping uitgeven, maar behendig kan hier enorm helpen.

De vraag is nu hoe deze dienst gecalled, en ik denk dat je nodig hebt om de waarschijnlijkheid van de cliënten en diensten veranderen en hoe het systeem zich zal ontwikkelen wegen.

Een service bus helpt maskeren van de diensten van hun cliënt (die kan ook andere diensten) en dit "maskeren" kan relayte naar locatie, protocol, formats, codes, enz. Sommige vormen van een service bus ook handhaven van de route (wat er moet worden genoemd, en wanneer), maar ik houd niet van over het algemeen het idee.

dus - de vraag die u nodig hebt om jezelf eerst vragen, denk ik, is wat je nodig hebt om mee te beginnen en hoeveel aan de voorkant investering die u wenst te maken (en kan rechtvaardigen)

Bijvoorbeeld, als aanvankelijk u tevreden bent met een point-to-point aanpak zijn, uw klanten kunnen de dienst rechtstreeks bellen; in een later stadium, als de service zich ontwikkelt, kunt u de "middle man" op het verzoek en reactie makelaar te introduceren (ja - kunt u bellen ESB als je wilt).

Als alternatief kun je beginnen met een basis "middle man", zodat de klanten nooit bellen met de dienst rechtstreeks, maar hoeft alleen de functies die u nodig hebt om te beginnen en uit te breiden het is capaciteiten als de wensen van vorm; het kan goed gaan als een eenvoudig doorsturen machine.

Idealiter zou je bouwen op de top van een product dat veel mogelijkheden ingebouwd heeft; BizTalk Server is een goede matchif je op MS stack (maar heeft it's learning curve)

dus - excuses als dit is niet een heel concreet antwoord - maar ik denk dat mijn belangrijkste punt is dat "ESB" hoeft niet een overkill zijn, het komt gewoon neer op wat je wilt op dag één te hebben, en behendige (en SOA ) zeker helpt doordat u zich geleidelijk ontwikkelen in plaats van iets big-bang dergelijke.

(Als boven alles is compleet onzin of gewoon een beetje onduidelijk is het gevolg van gebrek aan slaap met een nieuwe geboren in het huis! Excuses :-))

antwoordde op 10/12/2008 om 11:40
bron van user

stemmen
0

De hele migratie is wat kreeg me aan het ESB's ... Maar het hele idee van een ESB lijkt manier om te complex om een ​​probleem dat ongeveer 30.000 profielen impliceert op te lossen! We staan ​​aan de vooravond van een aantal exponencial groei (tot een paar miljoen profielen) en misschien beginnen op een nieuwe weg zou het beste zijn. Hoe gemakkelijk is om een ​​vermelding die zit te koppelen op een MySQL database om gegevens die zijn opgeslagen op MS SQL DB? Ik heb geen dubbele invoer wilt natuurlijk, maar er kan een meer flexibele manier dan een "geheel" ESB zijn ... Ik begrijp dat een SOA met een ESB vrij behendig in termen van upgrades en vervangingen kunnen zijn, maar het zou zijn een overkill? :)

antwoordde op 10/12/2008 om 00:41
bron van user

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more