General

IMPORTANT: I have moved my blog to http://blog.brianloesgen.com

Brian Loesgen — Mon, 06 Jul 2009 07:19:40 GMT

=======================================================================

IMPORTANT: this is my old blog and is not being updated anymore.

For my new site/blog/RSS, please visit http://blog.brianloesgen.com

=======================================================================

ESB Toolkit 2.0 Ships (YEAH!!!), I’m presenting it tonight at the San Diego .NET user group Connected Systems SIG

Brian Loesgen — Tue, 09 Jun 2009 22:36:25 GMT

I’m REALLY happy to say the the ESB Toolkit 2.0 has been released. As part of the current launch tour I’m doing, I’m telling people that in my opinion the best part of BizTalk Server 2009 is the ESB Toolkit. If you’re a BizTalk dev, you really want it check it out. And, if you’re one of those unfortunates that had installation issues, it’s OK to come back now and try again. I installed a build a couple of weeks ago, took me about 15 minutes total. The team invested a LOT of effort in this area, and it shows.

By sheer coincidence (OK, so I knew rough timeframe, but not to the day :)), I’m doing an overview presentation of it, and showing some really cool dynamic messaging demos, at a user group meeting in San Diego tonight. Meeting will be at 6:30 (pizza at 6:00) at the Microsoft office in La Jolla.

The official team blog announcement is available here.

You can get the bits here.

I’ll be posting more info about this within the next few days, and, if you’re in San Diego tonight, come on by!!

Speaking in San Diego tonight (Feb 17 2009) – Microsoft’s SOA offerings

Brian Loesgen — Tue, 17 Feb 2009 21:08:06 GMT

I’ll be speaking at the ASP.NET SIG of the San Diego .NET User Group tonight. Abstract is below. Meeting starts at 6:00 at the Microsoft La Jolla office.

This is basically the same presentation Allan Naim and I did recently at the SOA BP conference in Redmond and at an internal Microsoft conference.

If the demo gods are willing (as I expect them to be), I’m planning to do my shinny new demo that ties together work I’ve been doing around Dublin, Azure, WF, WCF, BizTalk 2009 and ESB Guidance 2.0.

Session Abstract:

With so many technologies to choose from, Solution Architects often find themselves unsure of what the right technologies are to address their solution needs. With the recent announcement of Microsoft's new "Dublin" application server capabilities, architects and developers have more choices than ever and the challenge is selecting and integrating the right technologies in order to ensure that IT is agile, and that business needs are met. The goal of this session is to provide you with a holistic view of Microsoft SOA technologies focusing on building the right architecture to address specific SOA capabilities around integration, messaging, security and management using technologies such as BizTalk Server 2009, ESB Guidance v2, Managed Services Engine, .NET 4.0 and Dublin. We will look at the value each piece adds to the overall picture, and how they can be integrated in a holistic solution.

Technorati Tags: SOA,ESB,Dublin,BizTalk,.NET,WF,WCF

New year, new role…. I have joined Microsoft.

Brian Loesgen — Thu, 15 Jan 2009 16:21:49 GMT

This has been a while coming, and is a big change for me personally, so I can be verbose in my post about it.

When I joined Neudesic (wow, I’ve been blogging a long time) more than 5 years ago, I was employee #12. The company has grown rapidly to somewhere over 250 people now, offices across the US and offshore. During my tenure with Neudesic, I had the opportunity to be involved in some very advanced, high-profile and challenging projects. It was a fun ride, and I like to think that my efforts contributed to the growth of the company and its reputation.

However, all that changes this week, as I have joined Microsoft. My title is Principal SOA Architect, and my territory is the US SouthWest.

Some things will change:

I’m not an MVP anymore as I’m no longer “independent”
I resigned as President of the San Diego .NET user group (after something like 7 years) although I continue to lead the Connected Systems SIG, and remain a Director (they wouldn’t let me leave)

Other things will not change:

I will continue helping customers use technology to improve processes, realizing operational cost savings and increased efficiencies
I will continue to immerse myself in new technologies, and evangelize them
I keep living in San Diego, although I may continue playing a role in supporting various airlines :)
This blog lives on: it is my intention to continue blogging here (remember the new URL: blog.BrianLoesgen.com). This may change, but I don’t think so at this time.

The reaction I’ve gotten from everyone (inside and outside Microsoft) has been phenomenal. Everyone thinks this role is ideal for me, and I think so too. I get to harness my passion for technology to help customers, and to do so on a greater scale than before, what’s not to like? If you’ve been following my posts or seen me speak about Oslo/Dublin/BizTalk/Azure/.NET 4, you’ll know that I’m really excited about this whole wave of technologies coming towards us. This time around, I’ll surf the wave from inside.

So, I’m excited, and looking forward to the road ahead…

New URI for my blog

Brian Loesgen — Fri, 19 Dec 2008 23:12:48 GMT

This blog has a new URI. Please re-point your feed readers or bookmarks to http://blog.BrianLoesgen.com

Nothing else changes. I am still hosted with my buddies at GeekWithBlogs, and I will of course continue to blog about BizTalk, Dublin, SOA, Oslo, Azure, WF/WCF et al. The new link is easier to remember and provides a layer of indirection should I decide to change where the blog is at some point in the future.

More Cool Tricks with Live Mesh

Brian Loesgen — Mon, 13 Oct 2008 14:17:16 GMT

We're now just a few short weeks away from PDC, which promises to yield a bumper crop of announcements. Aside from the Oslo/Dublin stuff that regular readers of my blog know I follow closely, there will also be cloud-related announcements. One thing I would expect is that Live Mesh will either get more features/capabilities, or that it may become part of something larger. Either way, I'm a big fan of the existing offering, and am eagerly waiting to see where this leads.

Here's a few things I've done lately that I think are pretty cool use-cases for Live Mesh:

Share, REALLY share

I started a new project recently, and I was given a client machine to work with (for security reasons, we cannot plug our laptops in to the network). The first thing I did was set up a folder on my desktop that I would use as a place to archive documents. Then, I synched it with my Live Mesh desktop. Next, I shared it locally (inside the network, a conventional folder share) with my fellow team members so they could also access it, so a colleague could drop a file in there, and it would propagate to my Live Mesh desktop-in-the-cloud. Lastly, from my Live Mesh desktop, I invited my colleagues and gave them rights to the folder so that they could also access the content from remote locations. Now,you may be wondering.... we already have MOSS and a project portal set up for collaboration. In addition, we also run Groove, so I could have used that to replicate content. So, why did I do this? Because it was a geeky way to test the functionality. I could also share the Live Mesh folder with anyone, even people who may not have Groove, or may not have rights to our MOSS portal. All in all, it was really cool, and quick to set up.

Almost like being there...

I have been in pretty intense travel mode for most of the year (when I go home now I call it a "visit"). This poses some interesting life logistic challenges, such as something arrives in the postal mail at home when I'm on the other side of the planet. So... using Live Mesh, I took my "public scans" folder and synched it with my Live Mesh desktop. I then synched that to a folder on my notebook. Now when something comes in the mail, I can tell my wife to put it on the scanner, and then using Live Mesh's remote desktop functionality, take control of my machine at home and scan the document. Once it has been scanned, it replicates up to my desktop and then to my notebook. Very cool!

And now, mobile....

Lastly, I discovered that there's a mobile Live Mesh experience (http://m.mesh.com). So, using my Windows Mobile phone, I can get to my Live Mesh desktop, navigate to my "public scans" folder (or, of course, any other folder in my Live Mesh desktop), and see the PDF that was scanned and replicated above.

Clearly, I'm having far too much fun with Live Mesh, and I am eagerly awaiting whatever comes out of PDC around this...

Technorati Tags: Live Mesh,Cloud Computing

Backpacking in the Sierra's 08: Brian and Steven do Forester Lake

Brian Loesgen — Tue, 26 Aug 2008 15:59:22 GMT

I'm not sure when my blog turned into a travel blog, but I think I may have found what I'll do as my next career :)

I've been very fortunate that work has taken me to interesting places, and I am able to jump off and see other interesting places. A few weeks ago I went to Dubai on my way home from Amman Jordan (where I'm working on a country-scale ESB project for Microsoft and the Jordanian government). I'm writing this in a taxi as my wife and I head to Petra (Jordan) for the weekend, then I work for another week in Amman before we head off to Sharm El Sheikh (Egypt) where I'll be doing more scuba diving in the Red Sea, and we'll be doing a side trip to Cairo for a few days to see the Pyramids and Sphinx.

But those are all future posts, this one's about last week when I went backpacking in the Sierras with my son.

A few years back my daughter and I backpacked out of Mineral King up to Franklin Lake (I did a post for that one too, which is here). I was inexperienced so we had far too much stuff, and to make it worse, we had more food than would fit in our bear canisters, so we had no choice, we had to make it to the lake where there were bear boxes. In my naive inexperience, my stretch goal was that the following day we'd keep on going up over Franklin Pass and down to the lakes beyond. The trip up to Franklin Lake almost killed us. We needed a day to recover before we could even day hike up to the pass, and we never went over.

This year, armed with far more backcountry experience, better gear and an insatiable drive to finish what I started, I went back with my son, determined to make it to the other side. And we did.

Here's the route we took:

If you can't read a topographical map, this one basically say "ouch". Every time you cross one of the bold lines, it hurts :)

The Mineral King valley is just perfect, very picturesque. If I set out to design "the prefect mountain valley", this would be it. Here's a picture of me as we're just starting out:

Then we began the climb up, this is the valley as seen from above (which gives you a great sense of the altitude gain):

We made it up to Franklin Lake in pretty good time, we had lots of daylight left.

People mean different things when they say "camping". To some it's "load up the RV", to others, "roughing it" means a state or national park where they have to line up for showers. For me, it means being as far from other humans as you can, being totally self-reliant, knowing that if you get in trouble you have to also get yourself out. Doing it my way takes you to much more interesting places! Here's our campsite overlooking Franklin Lake. There was another group (3 people) there that night, but they were far away and we never heard them.

And here's a view we had from our site. You can see we are almost above the tree line, and notice there's still snow around (in mid-August)

So, can you drink the water? Sure, but first you have to filter it, which is the hardest part of backpacking. I share the load with my kids though, here's Steven getting us our supply for the night:

Sometimes there are little surprises in the backcountry. Like a toilet. This one was probably built circa-1900, and has one and half walls still (barely) standing, but.... talk about a throne with a view!

The next day we hiked up to Franklin pass, given us a total altitude gain of some 5,000ft, taking us to 11,700ft, which means hiking with a backpack gets a whole lot more strenuous as the air is quite thin (particularly if you live at sea level like we do). Here's a view looking back at Franklin Lake, this again, gives you a great sense of the climb we did.

Then, looking over the other side of Franklin pass (roughly east-wards), we see where we're heading:

For two nights, this was our campsite at Forester. We had the whole lake to ourselves for those 2 days. I saw another group of people in the distance once, but they were just passing through on their way somewhere else. What really struck me about this lake was the silence. It was so absolutely quiet.

Here's another view of "our private lake":

Here's a shot of my "little boy" as we were chilling and enjoying our time at Forester:

And me taking a break on the way home:

We had planned to do the trip out in 2 days, but when the sky turned black and the hail started, we thought it would be best to do it all in one shot. That means we had an elevation gain of approx 2,000 feet (topping out at 11,700 feet, where the air is thin), followed by a drop of 5,000 feet (yes, almost a mile of elevation loss, which is really hard on the toes and feet). And all that was over 12 miles, with lightening in the next valley over. At the end of that, we had a 1.5 hour trip (about 25 miles) down a mountain road with 1.5 or so lanes, sometimes dirt road, lots of blind curves and multi-hundred-foot drops. It's a nerve-wracking drive, which acts as a natural filter as it keeps a lot of people out of the valley :) Then, thanks to various energy drinks and greasy food (pizza tastes incredible after a few nights of dehydrated backpacking food), we made the 6 hour drive home.

It seems I say this after almost every backpacking trip, but, this was the most physically challenging and demanding thing I've done in my life. And, I wouldn't have it any other way. The aches and pains have faded, but the memories we made will last our lifetimes.

Technorati Tags: backpacking,sierras,serra nevada,california,mineral king

Here it is: the answer to all SOA and ESB questions....

Brian Loesgen — Tue, 22 Jul 2008 18:43:32 GMT

[[ OK, I am writing this with tongue-in-cheek, which for anyone not familiar with that term, means "not really serious"!!! ]]

Funny thing happened today on the ESB project that I'm on....

After a day of hard work, solving some really tough technical challenges (the kind that makes your head throb, your eyes glaze over and make you think that becoming a carpenter could be a smart career move), I leaned back in my chair and surveyed the landscape (my desk). A piece of tattered paper caught my eye, the piece of paper the team had been using all day long to describe concepts, flow and "you are here" type information to ourselves. But, I saw it as if I was seeing it for the first time, and I was struck by what it had evolved into. Then I noticed that it was actually just the latest diagram in a series (we had no white board in that room). The first one was crisp, and not marked up, and on a relatively small piece of paper (could have been a cocktail napkin). All the others in the series (there were three more leading up to the final one) were progressively more marked-up, scribbled on, and tattered, and all on A4 size paper. So, I though I would share with you that vital piece of paper that some very bright people spent the day with. And, I'm not sure what happened to that bottom-left corner.

This my friends, is actually the architecture of a very cool world-class, country-scale ESB. It solves ALL problems associated with ESB and SOA architecture. It is a comprehensive solution that also even layers on end-to-end governance. We have intermediaries, bus services, generic on-ramps, SLA enforcement, itinerary repository... we have it all. In fact, if you have ANY questions about how all these things fit together, it's probably clearly explained in this diagram. This, in all its blazing glory, is real-world goodness I just had to share, for the benefit of the community.

Although this could be confidential in nature, I felt I was pretty safe posting it on my blog as the intellectual property is pretty much naturally protected. To the untrained eye, this looks like, well, I'm not sure what it would look like, probably just an unintelligible mess. But to us, it's pure gold, and the roadmap to success. Enjoy!!!

And no, I will NOT do a webcast to explain it. Tomorrow is a whole new day, and, who knows, maybe even worthy of a fresh piece of paper. This, however, is perhaps one of the finest pieces of "software architecture art" in existance :)

Technorati Tags: esb,soa,biztalk,architecture

Adventures with Live Mesh (CTP)

Brian Loesgen — Sat, 05 Jul 2008 17:15:41 GMT

I have been playing around with the Live Mesh Community Techology Preview, and have been doing what I think is some pretty cool stuff with it (as a consumer), so I thought I'd post something about it.

First off, and let's get this out of the way up front, this is NOT "another Ray Ozzie Notes/Groove". What's available today looks and feels like Groove (or FolderShare), but that's only because this is the first implementation of something written on top of the Mesh Operating Environment (MOE). Today it gives you a way to synchronize files between machines and a "virtual desktop in the cloud", but this is just the start. There will be a developer SDK available down the road that will open up this distributed environment to what I think could be a very interesting new class of applications (all SOA course!).

It is not my intention to go into detail about what it is, see the link below to Paul's write-ups for that. It is my intention to share my experiences, good and not-so-good, and explain how I am using it.

Configuration

My configuration is:

My MediaCenter PC (at home) is a Live Mesh "device"
My notebook (also known as "my office" :)) is another Live Mesh device
I have created some folders on my virtual Live Mesh desktop-in-the-cloud that are synched with my devices

Project documents and artifacts

I do all of my development work inside virtual machines. Plus, I'm very mobile, and am often working in a disconnected state. How I use Live Mesh for this is:

from inside my virtual machine, I map a drive to a folder on my host
I have Live Mesh running in the host
When I drag project documents from inside the VM into the shared folder, they appear on the host
Live Mesh detects the new documents, and synchronizes them to the cloud
Live Mesh running on my MediaCenter PC detects the new files in the cloud and brings them down.

Presto... everything's in synch! Pretty cool that I can do something inside my VM and it just shows up at home on my MediaCenter (complete with an RSS news feed for the folder saying who added/deleted what).

Photos

Basically the same as above, except when I plug my camera into my notebook I drag the photos in a folder that's synched with my Live Mesh desktop. From there, they replicate down to my MediaCenter PC. I have my MediaCenter machine configure to automatically do backups to an external drive. Here Live Mesh gives me instant distributed backups, without having to think about it.

My not-so-great experiences

My not-so-great experiences were my own fault, nothing wrong with Live Mesh.

I didn't understand the concept of a "device". It is a combination of machine+login. I have 2 logins on my MediaCenter, a low-privilege one for everyone in the family, and my admin login. I had set Live Mesh up, under both those logins, to synchronize the same folder to my virtual desktop folder. Perhaps it could be a bit smarter and detect that scenario, but it didn't, and the net effect was that I started getting duplicate file conflicts as the same files were being uploaded from different devices (even though from the same physical location) to the same virtual location. It turned into a real "Live Mess" :) Solution was to set the MediaCenter machine to login automatically on boot, so Live Mesh would always be running, and remove the admin "device" from my mesh.
this one's kind of funny, and shows what can happen when you forget what happens when you drag things. I was in Jordan, and had spent a weekend taking a bazillion pictures with my 10 megapixel camera. I pulled the pictures off, and it took all of a second to drag them to my synchronized photo folder. The upload to my mesh completed 5 days later :)

Learning more

Live Mesh is really cool, and useful technology. My biggest gripe right now, and a constraint on my usage, is the 5 gig limit. As was said on CNET's Buzz Out Loud podcast, and I love this quote, "we're going to need a bigger cloud".

I would encourage everyone to get the CTP, or get on the list, and start using it for real.

Last I saw there was a waiting list to get in to the tech preview. That may or may not still be the case when you read this.

If you search around, you'll find lots of info about Live Mesh, as a lot of people are (rightfully so) pretty excited about this. Some good starting points would be:

The Live Mesh preview site is https://www.mesh.com/Welcome/Welcome.aspx
The Live Mesh team blog is http://blogs.msdn.com/livemesh/
Paul Thurrott did an excellent write-up, which you can find at http://www.winsupersite.com/reviews/live_mesh_preview.asp and http://www.winsupersite.com/reviews/live_mesh_preview_02.asp

Technorati Tags: LiveMesh,Live Mesh

Why do SOA projects succeed? Why do some fail?

Brian Loesgen — Mon, 19 May 2008 20:59:51 GMT

I'm part of a curriculum advisory panel for California State University for an upcoming SOA program. As part of that, I spoke with someone there recently, relating real-world experiences, in a rather wide-ranging conversation. I started thinking "gee, I should write some of this down, it could be a good blog post". So, here it is!

I'll start off by saying that I could probably write a book about this, and there's likely a bazillion of my peers that could co-author. Many have already written books about this. However, instead, I'm going to distill selected thoughts down into a soap box-ish ranting blog post. I have boiled down some key points into just a few phrases. Maybe it works, maybe the value gets lost in a haze of over-simplification. Maybe I should do a series of posts (but I have NO plans to do so!).

Think big, do small

I'd say the single most important factor is planning. And by that, I don't mean lock a bunch of smart people in a room for a year and have them emerge with a detailed waterfall Gantt chart. I mean realizing that you're embarking on a path that will transform the way you create, deploy and manage your business-critical applications. Done right, your enterprise becomes more agile, cost and time to deploy new functionality decreases, and you achieve the nirvana of code re-use we as an industry have been seeking for decades. Done wrong, and you'll squander precious people resources and budget on an initiative with little or no return.

Mitigation: "boil the ocean" approaches fail. Think it all through, and then select some small services, then gradually pilot/deploy/build-up from there.

Think across the enterprise

In a large company with multiple IT sub-organizations, you need to have enterprise-level vision. Create a governing body. Identify a services portfolio. Without this, you could be doomed to costly inefficiencies such as duplication of efforts where multiple departments create different variants on a service, inconsistent naming, and eventually, a maintenance nightmare.

Mitigation: If you don't already have an enterprise architecture group chartered with setting enterprise-wide standards and policies, form one.

Take a holistic view

A developer will write 12 lines of super elegant code and say "there, the service is done, you can deploy it now". It's no fault of the developer, in their opinion they are done. The problem of course is that you need a services management strategy, and that goes far beyond the realm of what the rank and file developer sees, or in most cases, beyond what they need to see, and certainly beyond what they usually think about.

Mitigation: Think about the entire lifecycle of a service. How will you deploy it? Is there an approvals process? How will you secure it? How will you manage it? How will you monitor it? How will you retire it?

Recognize the people challenges

SOA thinking moves people into the realm of message-oriented, or contract-first if you like, architectures. This requires a different mindset than traditional object-oriented or procedural architectures. You're in a realm where everything is loosely-coupled, and operations often become asynchronous. I have seen firsthand at challenged client sites just how horribly wrong things can go if you try to apply object-oriented thinking and functional decomposition in a message-oriented environment.

Mitigation: recognize this paradigm shift, and invest in your people (architects and developers) to help them make the transition. Get them training and mentoring.

Recognize the infrastructure challenges

Creating an efficient operations environment for services is something that will be new to many IT folks. Your SLA's will drive requirements such as high availability and response times. Policy-driven SLAs and policy-driven security add a layer of indirection that result in a more change-tolerant and resilient infrastructure.

Mitigation: Plan for the near-term future, but look to the long-term future to ensure the environment you are putting in place will be able to scale to meet future demands. Your tooling may be great when you have 6 services in production, but how will it be when you have 1,000?

Think beyond the technologies and into the processes

Today's fast-paced world and rapidly changing business requirements of course lead to rapidly changing needs from the applications we create. Back when applications were monolithic silos, change came slowly, and evolution and deployments occurred at the monolith level. In a services-oriented world where there are numerous services acting as cogs in the machine, the new unit of deployment is at the service or service-composition level. Change is assured, and solution subset deployments become normal. "cowboy deployments" although almost always bad, in this type of environment become disastrous.

Mitigation: recognize Application Lifecycle Management as a key part of your process, and invest in it. Put procedures in place to assure repeatable, reliable builds. Have a testing strategy. Have a versionning strategy. Code migration should not be something people are afraid of.

Plan for disasters

An interesting side effect in the reuse of code assets by implementing intelligent stratification is that you inevitably build dependencies. For example, if all your services use an exception management service to log and respond to exceptions, what happens if that service is unavailable? The impact of a single service outage could ripple through your entire environment.

Mitigation: Think carefully about the dependencies, and architect and build robust services that incorporate mechanisms to respond to outages.

Benefiting from a successful SOA strategy is possible, but it's something you (as an architect) need to think about. As technologists, we often naturally gravitate towards and get caught up in the technologies. However, there are many touch-points beyond just the technology decisions, what I've listed above are just some of the things I've observed out in the real world, out where people are actually implementing SOA-based initiatives. I'm hoping by posting this that I'll help ease the path for some of you....

Technorati Tags: SOA,BizTalk,Service Oriented,ESB