![]() On the other hand, that's not to say that you can't leverage BizTalk if you already have already forked out the cash for licenses. Don't be fooled into purchasing more licenses than are absolutely necessary. It's based upon a fundamentally different paradigm. Despite Microsoft's attempts to rebrand BizTalk as a "bus", it definitely ain't. If you are using it as an integration point between multiple business services then that's bad. A broker is a single point of failure and a bottleneck in your system. Yes, we do want to centralize our business logic, but we want to do it at the "business service" level, rather than at an infrastructure and technical level. But wait, I thought we wanted to centralize business logic, right? Wrong. The only problem is that all of our business logic is centralized. Now, at least we're headed down the road toward messaging. This one is almost the same as web services, except that we're headed in the right direction. The MSMQ binding helps, but not if you use it in a synchronous blocking manner with an RPC-type interaction. Your servers are at 0% CPU, but you have no threads left to serve because they're all blocked waiting for remote services to respond. Could you imagine a world in which you called someone on the phone and waited on hold until you received the information you needed? RPC is just like that. Essentially, it's all about blocking communication. The problem is that all of these technologies, with the exception of MSMQ, were built upon the paradigm of RPC-remote procedure call. Furthermore, a "web service" AJAX call from a browser into a service may also be appropriate.Įssentially WCF is just a way of wrapping all of Microsoft's myriad of integration and communication technologies under one API. They've worked great in that arena and will continue to work well into the foreseeable future. So where do web services fit in? As integration points with 3rd parties that connect across the web. The biggest problem with with web services is that they run afoul of practically all of the fallacies. If you want an eye opener and sample of what Udi brings to the table, take a look at his Reliability, Availability, and Scalability webcast. I've read all of the best practices of the vendors and so forth, but the thing that always bugged me was how everything related to these "best practices" (if it's even appropriate to call them that), always pointed us back to purchasing more licenses-such as database licenses, OS licenses, etc. ![]() Previous to going to his class I had already done a decade of web services using SOAP and REST and I kept running into the same types of problems over and over again. Once you take the "red pill" you'll never see the world the same again. This one almost doesn't deserve the effort it takes to type. ![]() In a nutshell, all of the learning and hard lessons discovered through the school of hard knocks and best thinking of distributed systems (rather than whimsical, so-called vendor best practices) are baked into the heart and core of NServiceBus. It's not just about plugging in the WCF MSMQ binding and somehow magically request/response will bring scalability. This is one the foundational principle of NServiceBus. It is only by acknowledging and addressing these fallacies that our systems become truly and effectively distributed. NServiceBus was designed around the fallacies of distributed computing and faces each fallacies head-on rather than trying to sweep the them under the rug and hide from them while pretending that they don't exist. They are real, fundamental solutions that cut straight to the heart of the problem and treat it at the root rather than the traditional hacking at the leaves that you find by throwing technology at the problem, e.g. Further, the methodical way in which he discusses, understands, and then helps bring out the solution show that these are definitely not the quick-fix, aspirin and band-aid solutions. We both showed up to breakfast at the hotel at the same time each morning.įrom the face time that you have with Udi, you can literally see and feel the breadth and wealth of knowledge being brought to bear on the problems and issues at hand. It wasn't a planned event, it just kinda happened. I had the opportunity to eat breakfast with Udi every morning that week. It beats any technical or programmer conference hands down. If you are deciding where to spend your training budget, this is the one. I had the opportunity to attend his week-long course on Advanced Distributed System Design with SOA & DDD. Since that same time I have been wanting to post my thoughts on NServiceBus…and here they are:įor anyone that has had the privilege of listening to Udi Dahan it becomes immediately apparent that he knows what he's talking about. It ranks # 1 in Google for the term CQRS and # 2 in Bing. Little did I realize how far that post would go. Almost a year ago I wrote a post called Why I Love CQRS.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |