 Video streamVideo streamVideo stream |
 |
 |
|
|
|
| Question indexQuestion indexQuestion index |
|
|
|
|
|
| Interview transcriptInterview transcriptInterview transcript |  Discuss this interviewDiscuss this interviewDiscuss this interview |
|---|
|
Hey, Paul, welcome everybody on TheServerSide. I am a Group Product Manager these days, that's a big term, isn't it. I am working on the BizTalk Server team. I spend a lot of doing a number of things actually, in fact most of the time my team members do these, such things as worldwide technical readiness for the BizTalk Server products and then we also do competitive analysis and we also spend a lot of time taking customer feedback through our product planning function and back to the development team for new versions of the product. That sounds really overwhelming, doesn't it. The short version of that is that any piece of collateral, whether it be a white paper or a demo or something that helps you from a training perspective, or certification, really get up to speed with the with the product. Of course, the book that I wrote typically comes from my team and that's what we do all day. BizTalk Server was in development from about 1998 and the original version BizTalk Server was released in 2000 and became an amalgamation of messaging, dealing with heterogenous message formats and transports and acting as a broker that sits in the middle of those, so I can have an application, my Seibel application talking to my SAP application exchanging messages backwards and forwards. In addition to that, we added a very new technology, which we call business processes orchestration in BizTalk Server 2000 and of course, this had substantial enhancements over time.
A significant portion of customers BizTalk Server 2000, used actually just that messaging functionality and for many customers that orchestration functionality was not as performant as they required and the technology across the industry, not just Microsoft, was not as well defined as it is today, nearly five years later. And so these messaging based systems were good for getting customers started with connecting applications together, but they were really looking to add some more value into what they were doing by putting a business process on top of it. So, it's not just Seibel talking to SAP, but it's a conversation where Seibel and SAP talk because I receive a purchase order from trading partner that goes into my Seibel application, does a lookup on some employee information, comes back to my SAP system, does a lookup on some price and so on. So that business process functionality is something that everybody was really keen for us to improve on in BizTalk Server 2004. That was the number one investment we made in 2004. We completely rewrote the orchestration functionality. It posed some challenges because migration from prior versions of orchestration was not something we provided, it was technically impossible, otherwise we would have, but on the other hand, the functionality is much, much richer. You've got everything written on the .NET Framework, in fact, we are the largest server application in terms of .NET Framework code as part of that application and you have support for all types of cool features like correlation, web services, state management, scale-out and so on. There was a lot of work on the business process engine and then on the messaging side, we spent a lot of time really looking at customer use cases and understanding how we could make it more scalable, adopting an industry standard publish/subscribe notion, so I publish a message from my SAP application and I subscribe to it from multiple other applications and then really just making it more flexible and more easy to use. If you were an existing customer or if you've evaluated BizTalk Server 2000 before, BizTalk Server 2004 is just a brand new product and you really should go and look at the technology there. Performance is an interesting thing in the integration space just like it is in the application development space and it seems that my application has a set of properties that are very unique to what I am doing. Maybe I am doing a lot of business process or maybe I am doing big huge messages that I am passing through, that I catalogue messages and maybe I am sending lots of little messages, so it's just like measuring the performance of a .NET application and your scenario is a little challenging, it's kind of the same from a BizTalk Server's perspective. But having said that, of course, we spend a lot of time tuning the server before we ship it and what we've seen really is somewhere between 5 and 10 times increase in performance in the orchestration technologies from previous versions. A lot of this is because the previous version orchestration was an XML document that was interpreted and the BizTalk Server 2004 actually compiles orchestration down to MSIL, which of course is the same byte codes that VB and C# work with, so 5 or 10 times greater performance. In the messaging system, you are able to get up to thousands of messages a second, which covers a massive majority of customer scenarios in the integration space with BizTalk Server. Our model in messaging has always been never ever, ever lose a message and sometimes I guess if I want to talk a little bit about the competition and we compete very heavily with people like IBM and some of the pure space such as Tibco, WebMethods, and SeeBeyond and sometimes they offer options which are all in memory, it's kind of the standard-in memory, if the machine fails over, something goes down, you lose your message. The design point of BizTalk Server from Microsoft is always durable, never ever lose a message and to some extent you pay a little performance cost for the fact that you're writing a message to a disk, in our case the SQL Server, but on the other hand, the customers who are using BizTalk Server such as the Brazilian Banks to ship millions of dollars backwards and forwards between the central clearing house would far prefer that we had a 100% reliable system, than that extra little piece of performance you can get for those few messages per second. Let's do that in two pieces. I guess the first thing I want to make people aware of is Microsoft strategy for web services, internally inside Microsoft, how we are executing against strong support for web services. And the answer is there is a single group inside Microsoft, the team is the Indigo team these days, and those guys are building support for a number of the key web services specs, things like WS-TX, reliability, security and so on. The BizTalk Server team then takes advantage of the work that they've done in the web service particle layer and makes it available to integration customers. So, things we would do would enable you to in a publish and subscribe way receive a message from a web service send it out to another web service and configure that web service through a point and click UI rather than necessarily having to write code just that I need to call a web service. And then the other key one is of course, taking web services and aggregating them together because I could aggregate my multiple web services together in a service oriented architecture in code. I have my credit check web service and my payment web service and so on and so on and I could aggregate a dozen codes, so you would neither be able to understand if somebody reading my code, necessarily what was the process there, what happened. And so when I need to make a change and in service oriented architecture and I am doing that quite often. There is a lot of cost involved in the developer who has that IP in my hand, wondering through and figuring out as lines change, so as an alternative to that lots of customers take those aggregated web services scenarios and putting them into business processes. Business process has visual shapes that call out to web services and in BizTalk Server 2004 we support the ASMX web services, so SOAP, UDDI and WSDL and in an addition, we support the web services enhancement tool kit. You can actually do WS-Security on your web services Paul. Customers are commonly aggregating those services together inside of business process. The interesting thing here is it's kind of a fractal design pattern. I can take a set of services and I can aggregate them as a part of a business process and I might aggregate multiple business processes as part of the service and it sounds confusing, but what that really mean is, I take a business process in BizTalk Server and I can expose that business process, of course, the specific entry points I want in a secure way to the web services world. So, now what I am really creating is a stateful web service. On the front end, I am using whatever the latest web services protocols are, maybe I am again using WS-security to receive a purchase order message and then on the back end, what I have now is a stateful web service and it receives that response that is an asynchronous processing and continues on.
The second part of your question is a really interesting one and I guess, Enterprise Service Bus is a term that's really been surfacing probably in the last year or so and you haven't heard a lot of noise from Microsoft on enterprise service bus and so, one of the things we are doing here at TechEd is really being a little clearer on enterprise service bus. What is Microsoft's story there? And the first thing I want to say is, if you're a developer, architect or customer and you've been considering enterprise service bus because you have been talking to one of key analysts like Gartner or one of our competitors, then Microsoft can absolutely offer enterprise service bus capabilities. The combination of BizTalk Server and web services stack today offers that and then BizTalk Server and Indigo in 2006 timeframe really compete the web services stack. On the other hand, you're probably wondering so why have we not really gone out there and said, "We are in an ESB and so on." I actually considered it for BizTalk Server 2004 Partner Edition, which is low end SKU, it's only a thousand dollars, very affordable, you can use it in your first projects, why not call that an ESB edition. And when we did the analysis of ESB and certainly from my perspective and obviously this is from my perspective what we saw was a vendor, Sonic Software had invented ESB and congrats to the marketing that they did in doing that. I think they did a good job obviously in marketing and why were they successful in that? In the Java space there are whole hosts of very expensive integration service. They have a high price point with IBMs, the BEAs, Oracles, SAPs of this world and we compete with them all the time, but on the other hand, many customers just want to pass messages backwards and forwards for the first projects and at a price point that the Java guys were offering, that was not necessarily a compelling opportunity customers. They wanted something that was a little more affordable and the use case was only passing messages backwards and forwards. Sonic Software came from the queuing space where they just offered the queue, added a little bit more functionality to support routing in web services and created the term Enterprise Service Bus. So, when you translate that over into the Microsoft world, quite frankly the price point of BizTalk Server is very competitive with what somebody like Sonic offers and yet, you get all the business process, you get all the business rules, you get all the business activity monitoring. It is still true that in your first project you may just use the publishing subscribe messaging. We may just use the orchestration. It really didn't make sense for me to go ahead and create an ESB SKU that was a cut-down set of features when I could offer the whole set of features at the similar price point that the ESB guys were offering. So, it's kind of a long and involved story and the net out of it is if you're looking for an ESB yes, we offer all of those features, plus things you wouldn't typically find in an ESB like business process, business rules, business activity monitoring and while you might not think in your first project that you need those, I can tell you from five years experience in this business that customers keep coming back and you start developing and you build something that sends messages and then typically in your second project you understand you need business process, and then your third project and so on and so on. It's nice to have one product and one architecture that can kind of scale to your needs.
Yeah, that's an interesting one. In fact, on TheServerSide, we have some threads on that. The business rules engine has attracted a lot of interest. With this business rules engine, of course, you can take rules that you would typically have historically put in C# or VB code that would have been hard to change since you the developer, would have to fish through the code, find those rules, make those changes, and recompile the application. And now, you can put those inside a forward chaining RETE based rules engine and that rules engine then goes ahead and executes the rules and there is a user interface that you can use, or you can create your own as a developer to go ahead and make that easy for people to create rules out of your own web pages to ASP.NET or through a designer that we provide. It's a little more technical than what your business user requires. So, one of the interesting things with BizTalk Server is BizTalk Server really has a whole host of functionality. Some customers just use the messaging infrastructure. Most customers use the orchestration functionality. Some customers just use rules and many customers who use rules also use business process. So, for instance, Countrywide Bank is doing only the loan processing using the BizTalk Server rules engine and the interesting thing is that some of the machines that they are using actually just have the rules engine on that's all and then a number of the machines had the combination of the rules engine and the BizTalk Server infrastructure. So, it is a common question. I just want the business rules engine. Give me just the business rules engine. And we thought about that and we will consider to take that feedback continually and at this point, we decided not to do that. A couple of reasons are really adding additional SKUs makes things more confusing than less confusing because you could say the same thing about I just want BAM or I just want rules or I just want single sign on or I just want other parts of BizTalk Server and so, if we can make it a whole part in a single SKU it's easier and to understand from that perspective. Of course, it needs to be economical relative to other rules engines and I think our low-end edition, Partner Edition, which includes the rules engine and only costs a thousand US dollars is incredibly economical relative to competitive offering in the rules engine space. And really the third thing is you need to be able to deploy just the rules engine on your machine and as you do it. It's kind of like, I buy Windows, I don't know about you Paul, I only use a small percentage of the features in Windows, but I buy Windows and then I can have that option to use those or not use those as I choose. So the key thing there is deployment of the rules engine DLL, which is a single C# DLL is independent from the setup perspective, so you can just setup the rules engine DLL on your machine and actually in BizTalk Server 2004 it's a little tricky to set up just the designer and we need to do some work there and it's one of the things we fixed in BizTalk Server 2006. We have a lot of people who are interested in just using the rules engine. You should do that at a price point of a thousand dollars for the Partner Edition and of course, scaling up through Standard and Enterprise Edition and we think we offer value for money there in deployment and I agree we could be clearer by having a rules engine SKU, but I just wonder whether that would be more confusing than the other one.
Well, you have to put with some Microsoft jargon here while I address that question Paul, So BizTalk Server 2006, I would love to talk to you about the features later in a minute, and SQL Server 2005 and Visual Studio.NET 2005 are incredibly related products. With those three products, you can do a whole ton of things in the integration space. They are all built on the .NET framework 2.0. We support BizTalk supports SQL Server 2005, Visual Studio.NET 2005. So, these products, they are just meant to be together and this is really the first time in the history of the development cycle that all three products are lining up for a release in a similar timeframe. One of the challenges, however, as the BizTalk guy that builds on top of Visual Studio and SQL Server is for me to release I have to be waiting like everybody else, I am sure is on TheServerSide for SQL and Visual Studio to release. So once those products have RTMed, it will take me some time in terms of the development cycles to make sure that our product is on top of the RTM versions and released BizTalk Server. So, we want to be able to release the RTM on the same time. On the other hand, the SQL guys and the Visual Studio guys are doing some massive launch events around the world and it just makes so much sense for BizTalk Server to be in then. Just from a marketing perspective, lots of noise on BizTalk Server, you probably have been hearing more and more about BizTalk Server well you're going to hear it louder and louder through those. So, actually what Paul Flessner announced in his Tech-Ed keynote was that Visual Studio, SQL and BizTalk Server would launch on November 8, if I remember rightly and what launch means is a set of events where everybody has a party and I am sure that Visual Studio and SQL will be done by that point. On the other hand, BizTalk Server will not be done. We expect that BizTalk Server will ship in the first half of calendar year 2006, right now having just released the community technical preview, I would say I would be feeling pretty good about early in calendar year 2006. But I am going to leave it a little open to first half given that we haven't yet made it to a Beta one. The idea here is launching these products together from a marketing perspective builds to really work with each other and we will be delivering it shortly after them.
One of the things we did at Tech-Ed USA and actually I am really, really proud of the guys back home who are developing working weekends and all that stuff and I literally took the CTP build of BizTalk Server 2006 that was released to take it on plane to Orlando with me and its kind of a funny story Paul. I was sitting down and I took a red eye flight from Seattle to Florida and I didn't really want to take any bags like you've don't on American flights. So what I did was I took the whole boxes of CDs and I put them up in the luggage and it's a red eye flight, so I am starting to fall asleep and I get a little bit of wake up from the hostess and she is like "Are those your boxes up there?" and I am like "No! Please, please don't put it in the carry-on luggage, these things have to make it to Tech-Ed " but it turns out the only thing that she wanted to do was arrange them in a different order for another customer to put a bag in it. Whew! What we did here at Tech-Ed was create our first ever community technical preview build of BizTalk Server 2006. This is a pre-beta build. This is before Beta 1 and as such I have been telling customers who are using it, you need to be an adventurous customer to use this. There are some gotchas. For example, while it absolutely is built on top of Visual Studio.NET 2005, the code to support SQL Server 2005 doesn't quite work yet. It will by Beta1 but it doesn't quite work yet and so SQL Server 2000 is required. And there are a number of little gotchas as you would expect with the community technical preview build and at this point we are releasing it just to customers of Tech-Ed USA and Tech-Ed EMEA. Although we will reconsider whether we make it more broadly available when we get some more feedback from customers that they had good experiences with it. I've got to say, I don't know whether we can see in the camera, but we had what we called Load Fest, which is not what you think, for BizTalk Server 2006 where we had customers come on Monday night and sit down and actually load BizTalk Server 2006 on their machines and start playing with it. So, customers are already playing with it. So the community technical preview is really done and available to Tech-Ed customers in USA, Tech-Ed customer in EMEA, and the next milestone is Beta and we are going to have two Betas, that will be Beta 1, Beta 2 and then RTM and I would expect that first Beta to be in, I guess, the third quarter of this calendar year. If I was a betting man right now I would say it will be in August, but of course we need to make sure we have high quality there and we are working very aggressively to release that beta as quickly as possible and then there will be a second beta, which will be a production level beta for our early adopter customers and to make sure that we are very, very solid before we release in the first half of next year. Sure. BizTalk Server 2006, I have been with the team for five years and trying to count, 2000, 2002 and look, there is a consistency with which we release products and every even year these come out. 2006, we learned some things from releasing BizTalk Server 2004. First and foremost, you should be migrating customers. You should be migrating everything and so, what we are doing in 2006 is, if you are on BizTalk Server 2004, we will upgrade your installation. It will just work and as a part of the setup, the very first time you setup BizTalk Server 2006, we will point to your BizTalk Server 2004 management database, we will pick that information up and we will go ahead and take that all into the BizTalk Server 2006 database. The best way to prepare for this BizTalk Server 2006 is use BizTalk Server 2004 and many people who have asked me little intrepidly, what stuff is going away? Nothing is going away. Everything that you do in 2004 will be supported in 2006, which I think is really important because we need to keep moving customers ahead and they get to take advantage of Visual Studio.NET 2005 and so on. So, upgrade rather than migration is super important. I guess, we should talk about features. Really the first feature, my favorite feature out of everything, is setup is so much easier. We did a lot of work on the setup and installation of the product. If you're a developer and your setting this up for the first time on the box, we have what we call a default configuration and in the default configuration, what I do is I enter in my SQL Server address and I enter my user name and my password one time and we will go ahead and use that across all of the services on the installation. As a developer, I can get setup really quickly. It's like 10 clicks and a number of those are EULAs and next buttons and finish button, those types of things. The BizTalk Server 2004 setup experience is a little challenging. In 2006, we have just really addressed that. On the flip side, if you're an IT pro guy and you're working on a big scaled out farm and you've got 50 BizTalk Servers, as a number of our customers do all working together, then we have an advanced setting on our setup wizard, which is now not actually a wizard it's a list box view where you can set many of the advanced configuration settings and you can actually export them into XML so that you can setup multiple machines by simply importing a configuration and taking that trusted configuration and running on the machines. So, right from the beginning you've got work down in set up and I guess, given that TheServerSide.NET is very developer centric we will throw some developer features out there. The developer features in BizTalk Server 2006, are really about finding the things that people said, "Hey, Microsoft, you can do better at this". From the simple things like the file adapter now has a browse button, which just makes it so much easier to use to I've got a bunch of flat files that I deal with, sure XML is super important, but I am picking up flat files for an AS400 or a LINUX box or wherever its coming from, anyway I can get them in. Can you make it easy for me to design the flat file schema to import those flat files? What we did in BizTalk Server 2006 is kind of taking that Excel based paradigm for anybody who has used Excel before to import a CSV file and really putting it on steroids. What you get is a flat file wizard that you can point to at an instance of a flat file and it will go ahead and figure out the delimiters and the positions graphically and it's actually recursive so you can go through a really complex flat file and imports that and the time it takes to do that now is like a couple of seconds depending of course on the complexity of the file rather than a long period of time working through the wizard and so on. In addition, there are a bunch of other things just from usability perspective like the expression window is now much larger, so if you write in your .NET code to call your objects inside the orchestration editor you can probably see the end of the method. And then things like zoom are available in the orchestration designer. So if you have a really complex orchestration, you can zoom in and you can zoom out and actually what we will do is we will preserve if you collapse the shape surface feature in the orchestration designer, you have a whole set of shapes and you want to combine it into a group. We'll take that group and collapse it, so it becomes a single shape, make it easier for you to manage your orchestrations and we will go ahead and preserve that collection of shapes in between saves and so on. That's at the kind of user-interface level and at the runtime level, there are a bunch of things we did and in every release we improve on performance, but we are actually pretty happy with BizTalk Server 2004's performance, but we're really strictly working on that, it's kind of a core tenant. In addition to that, we support now messaging only web services and so, on BizTalk Server 2004, if I was working to send a message out to a web service, then I would be doing that from a business process exclusively and in many cases, that's what I wanted to do. I wanted to create a business process, send a message from that business process out to a web service but in BizTalk Server 2006 we support traditional publish and subscribe with no business process sending that out to a web service's as well. So, it just completes the story for the customers that are using the publish and subscribe messaging functionality and want to talk to web services just as I can talk to queues and so on. We also had much greater support for things like in order delivery. In order delivery was limited to the MSMQT adaptor. It's now available across a much wider range of adaptors, the one that supports order, obviously the file adapter doesn't support order, so you can't add an order to it but the queueing adapters do. Actually just a side bar on that one if you get a chance to use adapters we will ship the MQ series and MSMQ adaptors in the box, it's already part of the CTP installed and I recommend you use the MSMQ adapter before you use the MSMQT adapter it's a more generic MSMQ adapter. While I'm at that, there are a bunch of new adaptors, so some of the things that people really wanted to do was talk to SharePoint. In fact, we had a sample of .NET that was incredibly popular. Everybody was downloading it, using it, modifying it, all of that stuff. It's got a lot of usage and so, we recognized that and we now have a SharePoint adapter that is a production supported part of the product itself. And one of my other favorites is, I can finally pick up e-mail from an inbox using a POP3 adapter and so, you can have an inbox where you receive mail from training partners or otherwise, pick that mail up through POP3 and go ahead and put that through BizTalk Server and we've enhanced our SMTP adapter which is the send side of mail and to make it just so much easier to deal with e-mails. If you're integrating BizTalk Server in an e-mail style scenario, it is really just so much more pleasurable as an experience. I just keep going on Paul. As we go down into the guts of the engine, one of the more interesting features that we've provided is the notion to subscribe to suspended messages. So, here is the scenario. You put a flat file message into BizTalk Server and something goes wrong. And in the past something goes wrong means I need to go ahead and view it from an admin console, that's about as much as I can do. Now, I can literally have a subscription in the message box that will subscribe to a message in an error condition, so that message comes in, something goes wrong, a subscription is fired. That subscription may take that message and e-mail it to Scott to fix it and then put it back in the process, may put it on a SharePoint site where I can go and view on it and may know that my trading partner always messes up some particular field, run some business logic and send it back in. So being able to subscribe to suspended message is really important. And then there is a whole host of other engine features. I don't want to give you the impression that the developer is the really super key feature enhancements in BizTalk Server 2006. Yes, we made a lot of progress there and the really super important stuff is in admin and deployment. Admin and deployment is just a huge, huge set of new features here and so for example, we have a brand new MMC interface, absolutely brand new, that enables you to go ahead and do a number of things. First and foremost, it has this notion of a BizTalk application, which I probably should have talked about a little earlier, just like C# and VB have applications, BizTalk in the past didn't really have an application notion. You had a collection of schemas and maps and all of those stuff in one big pile and now you can segregate those into applications. So I can create Scott's application and Paul's application and we can have those running and then in the MMC environment, I can manage
Scott's application independently from Paul's application. So, what I mean by that? I can use the MMC to literally click on Scott's application and export all the orchestration, maps, schemas, pipeline, etc., and out an MSI file. So, now it's so much easier for me to move from my development environment to my staging environment. I just take my MSI file and run it in staging and then from staging to production, the same thing. So, deployment is just so much easier. In addition, in the MMC what I can now do is edit all of the trading partner information and URLs. BizTalk Server 2004, some customers had to put Visual Studio in a production environment if they wanted to go ahead and edit URLs, I'm sending to HTTP something or other or write scripts to do tha and then they didn't need Visual Studio. In BizTalk Server 2006, we provide the full features and more of the BizTalk Explorer, which is in Visual Studio for the admin guy. So, you can go ahead and make any of the changes on any of the adapters, add receive locations and so on without going inyo Visual Studio. In addition to that, there is a brand new monitoring infrastructure, so we had this notion called a group hub page, one of the things that customers asked us for is, I love the fact that I can actually see business processes that are running that's a big improvement over the last version, but I really wish it was more proactive. It gave me a view of what was wrong in my system and so, we have this notion of a group hub page by application, you can see, "Hey, Scott's application has two errors in it" and the error looks like X and it will proactively put that in your face so that you can more easily manage your system by just looking at the group hub page and saying, "Okay, everything is fine" or "the number of suspended instances is this, the number of running instances is that" and so there's a lot you can do with your group hub page, you can then drill down in that case where I suspended a message, add to this specific message and finally, which I think is just a fabulous feature, will give you the ability to view the contents of both messages as an administrator and all the context properties in a message viewer. So, it's just so much easier to manage when something goes wrong inside BizTalk Server 2006, just masses of features that are available in admin and deployment.
That's a really good question. Absolutely BizTalk Server service, the BTS, ETS service runs on the .NET framework 2.0 and of course gets any of the advantages that you get out of 2.0 including inline codes running, so my Indigo adapter that Morton Abramson has written for us on the .NET Framework 2.0, works just fine inside BizTalk Server 2006. So the interesting question is but what if I have as you just described an adapter that was written in BizTalk Server 2004 while I work in 2006 and in most cases, it will just work because what happens here is the adapter will now run on the Framework 2.0 in most cases unless it was an isolated or an out-of-process adapter and in fact the compatibility between the Framework 1.1 and 2.0 is generally pretty good and so that code should just run. So you shouldn't have any issues with that. Likewise, your components that you've created, your custom components in 1.1 should just run fine in process in most cases. |
