|
Ron: |
Let's begin, we're going to talk about patterns and anti-patterns. But before we do, let me tell you a little bit about myself. Ron Jacobs, I am an architect evangelist for Microsoft, I've been there almost seven years now, that's very cool because I'm this close to three weeks of vacation a year. Not that I could take it, but I'm very close.
And one of the things I started doing little more than a years, when kind of I first heard about podcast, I said "Those are really cool, I like this podcast thing. Maybe I could do that as a job" So I started doing some podcasts kind of on my own, and it went really well. So eventually Microsoft just said "Hey, why don't you just do that podcast thing like all the time?"
So I did, and now I have the ARCast show. It's been on channel nine for a long time, it still is, but we created a new site for it just a few weeks ago, still kind of getting it populated at ARCast.net.
But basically what I do, is I just talk to people about architecture and what they learned, and some of the people who are speakers here this week I've been talking to, sometimes it's Microsoft product people, sometimes it's just customers and other experts in the field.
There are over 85 episodes of ARCast now, over 50 hours of listening pleasure if you want to go download these.
I always tell people "Download it on your favorite MP3 device and listen in your car, while you're spending all that time stuck in traffic you could learn something."
Anyway, so that's what I do. Yeah, that's kind of funny, that's the reverse button that goes forward.
Anyway, did you ever notice that architecture keeps changing? I remember when I first started in this business, people had this idea that we would build stuff and use it for like ten or fifteen years, back in the mainframe days, do you remember those days? We were kind of like "Hey, we're going to build this app, it's got a life-cycle of fifteen years, and we're going to really get the return on investment on this" But things are changing now, and they are changing at a dizzying pace. And in fact these changes are happening so rapidly it's just hard to keep up.
Which is one of the reasons why I did ARCast, because people are always telling me "Man, I don't feel like I have enough time to read and to study these things, so I need to learn"
And in fact, what happens is that if you're an architect you're sort of expected to understand these changes, right? Like your boss goes off to a conference like this and he comes back and he's like "Hey, I heard about this service oriented architecture thing, they say it's going to save us a ton of money, you understand this right?" And you're like "Yeah, yeah, I got that"
If that makes you nervous, think about this. Using service oriented technologies alone does not mean that we're going to be successful. You see, some people have thought "Hey, we're going to use web services, that's service oriented technology, right? Then we're going to be there, right?"
But actually the answer is "Wrong" Maybe, maybe not. You see, I think the most important thing we need to understand to get the success we're after, is the goal.
Every architectural style has a goal, what is the goal of service oriented architecture, have you ever thought about that? I mean, if we're doing this, there must be a reason why we're doing it, what is the goal?
As I thought about, I read a book recently called "The World is Flat" It's a fascinating book about globalization, and in there Thomas Friedman talks about "The friction-free interaction".
I thought about this, how today if you go to any of the major ports around the country you see huge container ships coming in loaded with goods from china and other places, and all this commerce going on globally, and I'm thinking "Why did this happen?"
Well, you know, it happened because a lot of the barriers, a lot of the things that caused friction in international trade have been doing away with.
Technologies have improved, and tariffs have been reduced, and trading is happening, and the friction is going away. And actually, as I thought about this I thought "That's kind of like the goal of what we're trying to accomplish".
If that system and system were like separate countries, and getting messages between them were like global commerce, if we could reduce the barriers that cause friction between these things, that's kind of like the goal.
See really I think that every architectural style has defining characteristics. So if you look at the Chrysler building there, it's kind of an art-deco building, and we say that because it has like those sun-bursts on the top, it has a certain style and people who understand look at buildings and they say "Oh, that's an art-deco building" Because they recognize the style.
What's the defining characteristic of service oriented architecture? To me it is a style that emphasizes standards-based integration. Like this electrical outlet that you see in the picture there, it's very cool, right?
I mean, I can take a device that was built by any company around the world, I can take that device, I can walk up to an outlet in this building, which I've never been in before, plug it in and it's going to work, isn't that cool?
It's the result of a standards-based integration. It wasn't always so, in 1887 when electricity was first coming around, Thomas Edison, the guy who invented the light-bulb, he had this idea that we ought to have DC current. He really believed that DC current was a great thing, and he kind of got the jump, so he was the first one to put together electrical power plants.
And he pushing this, but then this other guy Nicola Tesla came along and he said "You know, there is this other kind of style of AC current which is better, it has characteristics that allows to transform it, and the power goes a lot further on the line, you don't need power stations all over the place."
And they had this big fight going on. What was funny about this was that Edison thought that he would enlist public opinion to show how dangerous AC current was, so you know what he did? He got a team together and they build the first electric chair. [laughter]
Using AC current, OK? And they said "Look how dangerous that AC current is, it kills people" It's true. Eventually though Tesla won out, and the world developed AC current and it's kind of the standard, although it's not as standard as you might hope.
In fact I discovered that recently when I went to a conference in the UK. I was over in Wales. I took my nice little US power strip. I put an adapter on it, plugged it in and blew out the power for half the hotel. It was great. [laughter] Don't do that.
OK. So there is a lot of hype though around service-oriented architecture. Once we started getting this and these service-oriented technologies, people began saying well loose coupling, that's what we want.
Loose coupling should be everywhere. Everything should be loosely coupled all the time. When they started building systems like that they say wow these are kind of slow. So really I believe that loose coupling everywhere is a myth. There are places in the architecture where tight coupling is OK and more than OK if necessary. We ought to just say tight coupling has its place.
Secondly, we ought to prefer explicit behavior over implicit behavior. Now this is a really important thing for achieving our goal of friction free interaction between systems. As we look at some of the anti-patterns you are going to see why this is true and third, really what is going on here is we are shifting the way we think about distributed systems.
So for the last ten, twelve years we've been building up a model, a kind of a mental model about distributed systems and how they work and what they should look like. We really need to change the way we have been thinking about them. I am going to suggest that services are really nothing more than an interface to business processes and that's how we ought to think about them.
So there are four tenets of service orientation that Microsoft has been talking about for a long time. I'm sure a lot of you have heard these, right? You probably have been to a talk and heard somebody talk about them.
Way back when, when we first came up with these, when was that, in the Spring of 2004 or 2003, anyway, I was on the indigo team at the time and we were talking about these ideas as a philosophy.
So I think this is an important philosophy for you to understand because it underpins the architectural thinking of where Microsoft is taking its products and technologies for how we intend to support service oriented architecture.
The first one says that boundaries are explicit. You might say well what does that mean? Well let's think about kind of applications where boundaries are not explicit. For example let's say you built a client server system in the past, right?
I built a lot of these. In fact in the 90s I used to work for a tool vendor that made a programming tool for builder client service systems. It was great. We had a form and a button and you would look behind that button and there would be 10, 000 lines of code and that would call over to a stored procedure which would have another thousand lines of code.
It kind of had half the business logic in the client and half over in that database. It was great. We were loving it. Then one day the Web came along and somebody said wouldn't it be great if we could take that form and put that on the Internet? We said "can't be done" and they said "Why not?"
We said "Well because all the business logic is behind that button there and you have to have the whole project to move that around." So we did it. We built n-tier architecture now so we have a middle tier and maybe the Web thing can call that and get it done.
Really then we began distributing these middle tiers out and this thing called that server and that server. When I was on the COM+ team, we had this idea that wouldn't it be great if you can create an object and not even know where it is?
We thought that would be pretty cool. On COM+ it's absolutely possible to create an object and not know whether it is in the same process, on the same server or in Tokyo. We thought that would make life easy, right? We found it matters a lot of the server is in Tokyo.
So when we were developing Windows communications foundation we said you know what, we ought to make the boundaries explicit because it matters to the architecture. So when you are saying here's a boundary you ought to know where it is. Now that seems kind of obvious.
I was thinking about how the first time I moved to Washington, I had never been to Canada before and so I am thinking, I'm so close I just got to go to Canada. This is going to be cool. On a Saturday morning, my daughter was a brand new baby and our in-laws were visiting us and I said let's just go to Vancouver today.
What do you say? We loaded everyone in the van. By the time we got everyone loaded up and drove up to the border it was almost noon when we got there. When you cross this border there were guards there and people would ask you what you were doing. So we pulled up and this guy says "So where are you going in Canada?"
I said "We are going to Vancouver." He said "OK great. How many nights are you going to stay?" I said, "Not staying any nights. We are just going for the day." He said "OK it is almost noon and you are not even there yet. What are you going to see in Vancouver?" I said "Well I don't know. I have never been there. Just want to see it. I'm going to Vancouver." "OK great why don't you pull over here." So I pulled over and they had us all get out of the van and searched every last thing for 45 minutes because they are thinking what kind of idiot comes to the border with no plan at noon on a Saturday to go to Vancouver. He must have drugs or guns or something. So they searched everything and let us go finally.
Now as I was standing there I am thinking, you know if I had driven south I would cross another border. Like when I get to Oregon, the Columbia River is right there. There's a sign that says Welcome to Oregon.
Nobody stops me. Nobody says "Where are you going? How long are you going to stay? What are you doing?" I can go right by that at 60 miles an hour. I can go to Portland with no plan whatsoever and nobody cares. So that's great but this is like architecture, right?
You see sometimes in our systems there are borders that are like that Columbia River crossing, right? In there when I cross between Oregon and Washington things don't really change that much right? I mean there's a different state government but the federal government of the United States uses the same money, same federal laws generally apply.
Most of the laws are generally the same but when I cross in British Columbia everything changes. The government is now in Ottawa instead of in Washington, DC. They use money that's called dollars but it is Canadian dollars, right? They even say words like about differently. OK. So everything changes when I cross that border.
Now the reason I bring this up is because when people start thinking about this principle of boundaries are explicit, they say where are the boundaries in my architecture? I usually try to get them to think about their country. Where's your country? They say, "What do you mean by that?"
I mean the region of the system that's under your control where you can roll out a patch if you want to. You can bring it up, start it up and shut it down. You don't have to ask the world about it. When you start talking about their system and our system you can probably at some point in between there draw a line and say that's the boundary. It's an international boundary, right?
Crossing it is not easy. If you are going into Canada, by the way, you should allow at least 35 to 45 minutes to get across that border because you are going to have to wait. So you think really hard how often you are going to cross the border and you are watching out for this. The same thing is true in the architecture. We'll see more about that as we go along.
Secondly, services are autonomous. Autonomy just really means that services like to control their own destiny. They can be deployed independently, versioned independently, started, stopped. They run and they do things.
When I first joined the COM+ team one of my jobs was to help the product support services people deal with critical problems. So when you call in and you got a real critical problem and the product support needed the help of the product team, they would come to me and we would talk about it.
We got so many calls from people who basically built like a COM+ object. They'd have a website call a COM+ object which called the mainframe and got some data back. Then one day the website starts to returning server busy errors and they look at their web server and they see the utilization is only 20%.
So then they look at the COM+ server and they see utilization there is only 20%. Then they see that the mainframe is running kind of slow today and we would get stack dumps and we would see that the whole system was backed up because everything was waiting on the mainframe.
This little COM+ object in here didn't really do anything that was very autonomous. It really couldn't do anything unless the mainframe was doing its job.
There are degrees of autonomy. We could have built that COM+ object so that if the mainframe was too busy maybe it has a little database over here that it could call and get a result faster. Or maybe the mainframe is offline right now because it is doing its batch process at night and so it calls into the database to get some cached data.
As we build a service we like to think about this country being as autonomous as we can possibly get it. Full autonomy that it never depends on anything else is rarely possible. I would like to the point where the service can function and do something useful maybe something other than crash or cause other things to crash when it can't get its job done. If I don't have 100% service maybe I'd like to have degraded service but still something.
The third tenet originally was services, share, schema and contract only, not class. I reworded this a little bit because it seemed to me that schema and contract were pretty much the same thing.
What this is really about is saying -- when we want to have two systems interacting we ought to lower the bar about the things we need to agree on. For example, in COM+, if I had a COM+ object, and I said "Hey, you want to use my COM+ object?" You could use it, right?
In fact, when we built COM+ we imagined that people were going to start using objects from other people's systems all over the place. In practice, we found that did not happen. When we asked why, it turned out that really it was because there was so much we had to agree on.
See in COM+, in the whole COM and DCOM stack we have to agree, first off, that we are both running Windows. Which of course everybody runs Windows all the time everywhere for everything so that's usually not a problem, right? [laughs]
We also had to agree that the way the networks ports were going to interact didn't typically have a firewall between them. We had to get down to the point where you were using a programming language that supports COM as I was.
Even if we got into things like using custom proxies, we had to distribute proxies. There was a mountain of things that we had to agree on. Not only that, we had to agree operationally how we were going to deploy new versions of these things and patches and what not.
So with service oriented architecture we said, "Let's just lower the bar." Let's agree about two things. We are going to do an open standards based protocol like SOAP, XML, HTTP protocols and that sort of thing. Secondly we are going to have some standards where we can describe the way we want to have this conversation.
That means now that many different platforms can communicate with our service and that's a good thing. But here's the evil. Sometimes the way that we architect things, it requires people who want to use our service to know a lot more than those two things.
Remember I said we ought to prefer explicit behavior over implicit. That's where sometimes our implicit behavior sort of leaks out through our interfaces. We'll show you some examples of that.
The last one, I mentioned policy and policy is just a way of saying how we're going to have a conversation. For example, you came to this presentation today and there is two parts to the way we are communicating. First thing is the content, like the things on the slides and the message about what I'm saying. The second part is the way in which I'm saying it.
Anybody here speak Russian? Good for you, because I don't. If I could, I could speak Russian, and you might understand me but the rest of the room would not. So the policy about this session is that I'm going to speak English.
If I say we are going to have a web service between this system and that system, there's in that a policy, right? We are saying HTTP, port 80, SOAP protocol, XML, angle brackets. That's the unspoken policy that's kind of wrapped up - the default policy, right? We could say, I'm a little bit concerned about security, so we are going to use SSL.
So that's a policy statement. Now we are saying HTTPS, port 443, point to point transport level security. A policy statement says nothing about the messages or the kind of conversations you'll have but it says about the requirements for the way in which the conversation is going to be held.
If you have been hearing about WS security and you're like "Well, what is that all about?" WS security is a set of standards that describe the kind of policy statements you can make related to security with web services.
So you can say, "I'd like to have the message contents encrypted." Or maybe just the body or a particular header and I want them encrypted with a certain algorithm. Or I'd like to have a digital signature on the message.
The amount of things we can ask for with policy is becoming much richer every day. The good thing about it is it's standards based so that if you are using some other platform and you want to communicate with my service, we can describe, in a way that all of the vendors of the world agreed upon and we had a big group hug, and we said, "Yeah you ought to be able to do that." That's what we mean.
Let's talk about the first anti-pattern, which is what I call the CRUDy interface. Anti-patterns are fun because they represent the mistakes that people make, trouble that they get into, and we can think about ways to avoid this.
You might disagree with me about some of these. In fact, I always get people who come up to me afterwards and say "I like that CRUDy pattern. That's a good one!" Like I said earlier, IBM said on their website that point to point web services is an anti-pattern although a lot of people would disagree with that. So you know it's an opinion.
This happens usually when people start designing service interfaces. Let's take an example - maybe I've got a customer application, a CRM app, and it does typical things that you do. Maybe we need to update a customer address. I have a legacy app and its working and everybody is happy.
Then the boss comes in says, "By the way, we are going to outsource our whole customer service department because it's way too expensive." So now we have a vendor somewhere and we need to create a web service for them to update a customer address. It's a reasonable thing to do.
When I say a CRUDy interface, I'm speaking about the typical operations - create, read, update, and delete. A lot of people, the first thing they want to do is go make, oh we have a database that has customers in it, let's make the create customer, read customer, update customer, delete customer service - those four web services. We are service oriented.
This looks like an OK thing to do right? If I look at that interface, I might say, "Well, what's wrong with that? It seems like a reasonable thing to do. After all, we do have to update customers." Let's do a little mind shift here.
What I want to do is ask the question - is updating a customer, maybe we are just updating their address in the database, is that just a data update or is it a business process?
If we approach this from thinking about the database out, we just look at this is a simple data update. Could a partner, maybe this external partner, could they update an address? Maybe a customer wants to call the web service themselves. Maybe they are a programmer and they wrote a little.NET app and they want to update their address. Could they do that? What happens when a customer address changes?
For example, if a customer moves from one state to another, maybe they have different tax rates, maybe different legal requirements, maybe a whole different customer service team, maybe there are a dozen things that need to happen when somebody moves depending on where they go.
So if we just take an address and stuff it in the database, we kind of missed it, didn't we? Today that's all that needs to happen but a year from now there will be 10 things that need to happen.
I'm just suggesting that thinking about these things as simple data updates is the wrong way of thinking about it. We ought to think about that when a customer changes address, that is a business process.
Today it might be a very simple one - all we do is just update a database. Tomorrow there might be more things so we ought to get the business process thinking in place so that when we need to change this out in the future we can easily.
This kind of crud thinking happens when we just take what we have known about distributed systems for a long time and we just apply it to service oriented architecture.
Another example of this is enumeration. This is kind of a silly example but I've seen this done, believe it or not. Enumeration was a great idea in the world of COM when you had a set of objects in the same process space.
This object has a list of customers and this thing wants to enumerate the list. Enumeration is kind of a tricky thing because there are issues about resource ownership and what not.
So if you did this with a web service, what would be wrong with that? The first problem is - who owns this collection? Is it the system that is consuming it or the system that is serving up the customer data?
Either way, it gives you problems because it violates tenet two, remember I said that services are autonomous. That means that as an autonomous service, I like to control my own resources.
Let's say I did this enumeration interface and you call it and you ask for all of the customers in Boston. I return you a list of a million customers.
That would be a lot but maybe I did. Now I have to set aside in my memory of my service a million records and then I'm going to give you some kind of a virtual cursor so you can call current and move next and move next and all that.
I've now allowed you, somebody who I barely know and trust, to consume a whole bunch of memory on my service. I'm surrendering some autonomy and control over my memory to you.
I don't want to do that because maybe you'll take all day to enumerate over this list. If I've done that for you and somebody else wants a million records, I can't do it for them. So, it really violates that tenet.
The second problem you notice this contract uses an abstract type - an object. What can you do with an object? Anybody? What can you do? Come on, don't leave me up here. |
|
Ron: |
You could cast it. Right. You could see if it's null, You could call to String. But if you were going to cast it, what would you cast it to? In order to cast it to something useful you have to know something about the object hierarchy, don't you?
As soon as you know something about the object hierarchy of the service that you are calling, you know more than you should. Right? Now you know something about the internals of that system that are not explicitly called out in the contract.
So you say, "I know that's an object but it's really a customer so I can cast it to a customer and I happen to know what a customer looks like and so I can do that."
As soon as those guys on the other side change what a customer is or something about the object hierarchy of the thing they are returning you, the whole thing blows up, right? When it comes to these international boundaries, I don't want to know what to cast it to. I shouldn't know that.
There is a spec called WS Enumeration that's been submitted and it really defines a way to handle this kind of thorny problem between services.
I threw that in there because somebody came up to me after one of these and goes, "Yeah, what about WS Enumeration?" [laughs] So we are doing it; but we are doing it in a good service oriented way.
Another example, often I saw this in client server systems, if you just take that code and bring it forward, you might do something where you have kind of an application level lock - I check out a customer record maybe update name, address and so forth and then commit changes. So what's wrong with this interface? We could do something like that maybe make all those services.
The problem is I would never want to allow control to come into my service and leave with data in an inconsistent state.
Meaning kind of like temporary changes that aren't committed to the database or something that would require me to hold on to this state until you get back to me with another call to know what's the right thing to do. It's my opinion that logical operations that require multiple message exchanges to complete are dangerous.
I didn't say that they are wrong. For example, rock climbing - rock climbing isn't wrong, but it is dangerous. Actually I did this climb at half dome in Yosemite and it was great!
You can see in the second photo there I'm hanging my feet over a precipice that drops 4,000 feet but you notice I'm holding on with my hand. [laughter] I kept thinking the whole time I'm climbing up this thing, I'm thinking, you know if you just tripped, just one little trip, boom you're dead.
I'm saying this because you ought to get in the mindset that if you're designing an interface that requires multiple message exchanges to complete a logical operation, you have dramatically increased the number of ways in which things can go wrong.
Sometimes when I see an interface like this I ask people I say well why did you do it that way?
They say that's the way our old system used to do it.
I go OK, that's a wrong answer, OK.
Let's think about trying to get as much done in one message as possible. It's OK if the message is big. That's OK. Make it as big as it needs to be because it would be a lot safer...
Remember it's like that border crossing, you remember I said nobody gets across fast. So if I were going to send a load of stuff across I wouldn't put a couple things in my trunk, go up and come back.
I would get a great big truck, fill it up, and then take it across once if I possibly could.
All right, so that's the CRUDy interface pattern. The second interface pattern, Anti-pattern I should say is what I call loosey goosy.
This happens when people get really worried about terms like contract. You know you ever think about like when you're signing contracts; doesn't that kind of make you nervous?
They have page after page of fine print and at the bottom they have this little sentence saying "I have read and fully understand everything I'm about to agree to."
You're signing it thinking there's no way in the world I could really truly say that, but you do it anyway because you've just got to get things done.
So sometimes when people come to loosey goosy they worry that if they build a contract they're not sure they can stick with it. So then maybe they get to the point like this...The uber-service. I'm going to give you a service definition that will work for any situation, anywhere, and anytime. It absolutely works.
All you need to do is just take a document and return a document. You could do anything you want there. OK, now there are basically three questions though. I mean first of all, this violates the spirit of tenant tree. Remember I said tenant three is that we share contract and policy only.
OK. Technically you could say well yeah we're doing that, we have contract and a policy, OK. But it's sort of a meaningless contract. But anyway it's violating the spirit of that tenant, OK? There are three big questions that ought to be very clear in the contract. What does the service do?
This is actually a tricky one because it's hard to define what a service does except for that the name of the service ought to give you a clue OK?
So execute doesn't tell me a lot, OK? But secondly, then you can get very specific with what data will it accept and what data it will return. This ought to be very explicit. Now sometimes people like to make this loose.
So maybe they'll have part of the message being pretty explicit like we'll take a name, address, and a phone number. Then just incase you want to give us some other stuff we have this hunk of XML that you can just throw whatever you want in there.
To which I say...Well, what can I throw in there?
They say oh, well whatever you want. Well, what if I give you a gigabyte of data in there? Will that work? I'm not sure that it would OK. So we need to think about being as explicit as possible in the contracts because relying on implicit behavior is like a house of cards.
You ever build a house of cards? Anybody ever build one of those?
Do you still have it? There's a reason why you don't, OK? Now sometimes when I talk to people about their systems I get the feeling that they have built a house of cards. You know how I know that?
Because they say things like "Don't touch it." It works, leave it alone. The last time we touched that thing it took us six months, $10 million, and we can't get it back, OK?
When we rely on implicit behavior like...Oh there's a hunk of XML and if you put xyz in there this magic thing happens...OK that produces me relying on implicit behavior.
Or like the example of knowing that the object that you send me is really a customer so I'm going to cast it to that. I'm relying on implicit behavior.
One little slip and the whole thing breaks. This is ultimately why people have been reluctant to build links between systems, because it was painful.
They started saying you know if I have a link to that system I'm constantly baby-sitting this thing. It works for a couple weeks and then they make a change and the whole thing breaks and we have to try and troubleshoot that.
Then six months later it breaks again and it's just too painful, right?
So we're avoiding building the kind of links that might actually save us some time and money because it's been a painful process to keep them up and running.
Now one of the reasons why people do loosey goosy is because they're worried about versioning. Now in dot net 1-0 and 1-1, versioning was very strict. So if you changed anything about the contract, it tended to break everything.
So you had to produce a new endpoint and what not. Now.net 2-0 uses a new serializer and it allows for version tolerant serialization.
So I can add new things to the message for example and it's not going to break everything. I can put little attributes on it to describe how I'm changing and evolving a message over time.
I really like this because it supports a principle. See the principle for versioning and contracts in my view is that you ought to receive liberally. OK?
So if this guy sends me a version one message, this lady sends me a version two message, and this alien sends me a version three messages you know, whatever.
I can accept all versions of these messages because I'm receiving liberally. OK? But I want to send specifically. So if I'm changing something about the response that I'm going to return to you, I need to version my service.
I can receive liberally because that's under my control, but if I start altering the return type that I'm sending to you I don't know what I'm doing to you. I'm probably breaking your service if I do that.
So we need to make our contracts clear, set the expectations, version when necessary, and receive liberally.
There's a nice little article...The URL is like a mile long so I just made it a hyper-link in the slide deck. If you download the slides you can see there's a nice article there.
[music]
Oh we're out of time. I know you're disappointed by that but guess what we're coming back on the next episode with more from the patterns and anti-patterns for SOA talk from Tech-Ed US.
In fact I am here in Barcelona today preparing for giving the same talk this week here in Barcelona at the European Tech-Ed.
In fact I'm looking forward to meeting some of you. Here's a guy Paul who writes that he's attending the Tech-Ed developers' conference here in Barcelona. Maybe I'll run into you here Paul.
He says Ron I just wanted to drop an email to say I love the podcast. I've really enjoyed listening over the past couple of months.
Coming from a developer background I'm fairly new to enterprise architecture and to be honest so is my organization. You're insights have been very helpful.
Well thanks so much Paul, I am delighted to hear its helping.
If you want to send me a note, sent it to arcast@microsoft.com and we'll see you next time. |
