Google Chrome Operating System

by community-syndication | Nov 24, 2009 | BizTalk Community Blogs via Syndication

I know this is VERY off subject, but I wanted to see what all of the hubub was about with the new OS that is going to be hitting the market in late 2010.

I installed it and ran it. Not terribly interesting. Here are two of the main shots:

and the really interesting screen

My take on it:

I guess it will be good for those who love to browse the internet and that is it. I am a big fan of Android, but an OS that is centered simply around the web? I guess the time is coming “welcome to cloud computing.”

AppFabric and BizTalk

by community-syndication | Nov 23, 2009 | BizTalk Community Blogs via Syndication

There have been lots of questions lately about AppFabric (code named Dublin). These questions have centered around why Microsoft needs another middle tier solution and will AppFabric replace BizTalk.

Lets take a look at these questions as well as two additional questions; What is AppFabric and why does Microsoft need another middle tier solution? First, AppFabric is a distributed application server. To answer the other questions, we need to go in a little more depth.

Before .NET was released, developers working with the Microsoft technologies used COM+ to host their middle tier objects. Back then, when we needed to scale out our object oriented and object based applications we created middle tier code libraries and ’hosted’ them in COM+. The COM+ host provided instance management (just-in-time activation), role-based security, automated transaction management as well as better memory and processor management, distributed transactions and a number of other services. 

When .NET was introduced, we moved away from COM components and also moved away from using COM+ as a hosting model. This left a vacuum that so far had gone unfilled.

In attempts to fill this vacuum, individual developers had to create their own hosts. These hosts typically were Windows Services. However, these services usually didn’t include multi threading, scale out capabilities, tracking, monitoring, etc. – the types of functionality that has been in BizTalk for years. As Microsoft looked at BizTalk, as well as the .NET Framework, it was determined that there are many great features in BizTalk that if a scaled down version was available it would address gaps in the framework. Thus AppFabric was born.

For .NET developers writing applications using WCF and WF, AppFabric will fill the middle tier hosting vacuum. AppFabric will provide the host and will provide scalability and support for building out your middle tier application components. It also will simplify deployment, configuration, management and scalability of composite applications. The goal of AppFabric is to provide a server infrastructure, on which business logic developed in WF can be executed and exposed via WCF endpoints, without the need to design, develop, and support the infrastructural code.

The next question I hear is will AppFabric replace BizTalk? The answer is very clearly no.

AppFabric should be used when your architecture calls for an application level code-first object based approach. This is the same approach that is used by WF and WCF programming models and is the one that can be hosted in AppFabric and the additional functionality that AppFabric provides. AppFabric will provide a number of management and scalability features through IIS and WAS to provide the server infrastructure without the need to write the plumbing as you did before. This is a different approach than that of the XML Schema first approach that is used in BizTalk.

Use BizTalk when your architecture calls for an enterprise level message based approach. Use BizTalk when you need to isolate disparate systems that need to be connected. In point-to-point integrations, changes made to the provider system can have a profound impact on the consuming application. BizTalk natively provides a hub-based integration model which eases this burden and allows organizations to provide business services that are isolated from the impact of changes made to the systems and processes on which these services are based. This is achieved through the use of separate schemas, and the associated ability to easily develop message transformation logic using BizTalk’s Mapper tool. Use BizTalk if you have business-to-business requirements and need to integrate using technologies such as EDI, SWIFT, RosettaNet, AS2 or HL7.

The reality is that businesses will utilize both of these technologies in their different application architectures. This is not an either or decision but instead a decision of where and when to use each. 

Keep in mind, however, that many of the same terms are used to describe the functionality provided with both BizTalk and AppFabric. These terms are things like Content Based Routing, Correlation, long running transactions, etc. Although the terms are the same the implementation and functionality is different. With all decisions, make sure that you take a couple of minutes to look under the hood and ensure that you understand the differences.

BizTalk Server 2009 Standard and 64-bit processing

by community-syndication | Nov 23, 2009 | BizTalk Community Blogs via Syndication

I was kind of suprised when I saw this blog post. Saying that 64-bit processing wasn’t allowed with Standard Edition of BizTalk. Since I was at PDC at the time I asked the team who were (without me putting words in their mouths) equally suprised. At the time they couldn’t see either a licensing or technical reason as to why that would be so. And to add to that it made little sense that Branch was allowed while Standard was not.

I didn’t have access to machines (or time) to test right then, but after getting back I tested and true enough you are not allowed to create a 32-bit host. The UI stops you. As you can see, this doesn’t stop BizTalk Server Standard from being installed on a 64-bit machine – it just doesn’t get the benefits of 64-bit processing.

I also found an “official” explanation to this here, which I’ve pasted below:

"We consider 64-bit support an Enterprise Edition level feature that a customer would only select if they require faster messaging/orchestration processing or the larger addressable virtual memory of 64-bit mode for large BizTalk message mapping or other memory intensive operations. Because the Standard Edition is designed for small-to-medium environments, it is licensed to only run on a single BizTalk server with a maximum of two CPUs, maximum of five "BizTalk Applications", and a single message box. 64-bit support for the Standard Edition seemed counter-intuitive from a technical and licensing perspective. If the deployment scenario requires 64-bit hardware then it certainly requires BizTalk Enterprise as well. Standard edition is for single box only installations. Enterprise is also required for multi box installs and for clustering."

Judging from the teams initial reaction and the fact that 64-bit is now very much mainstream, especially on servers, I would expect to see this change in the upcoming releases of BizTalk Server.

Webcast – Integration Concerns for Healthcare Organizations

by community-syndication | Nov 23, 2009 | BizTalk Community Blogs via Syndication

In the next few weeks, Microsoft Canada will be hosting a number of webcasts focused on integration solutions for specific industries. On November 26th, we will be focusing on solutions for Healthcare organizations. I will stress that these events are being run by the Canadian team with a focus on Canadian organizations. If you can’t make it to this event, we will be recording it, so you can watch it on demand. The registration link and session abstract is below.

November 26^th 2:00 PM EST, Register now for the Webcast

A better way to connect your distributed systems.

Today’s healthcare organizations face many challenges in implementing, managing and maintaining HL7 integration solutions. Integration solutions must be able to support mission-critical healthcare systems, and meet the requirements of the current regional and provincial initiatives while at the same time ensuring future EHR initiatives can be accommodated within the solution’s framework.
This event will focus on tools, methodologies and best practices to help simplify and accelerate Healthcare Integration solutions. Attend and learn from real-world success stories on how Microsoft-based technologies were applied to deliver healthcare solutions.

Register now for this webcast co-presented by Microsoft and Dapasoft.
Dapasoft is a technology partner which specializes in Healthcare solutions. They will introduce Corolar, a new Healthcare solution based on Microsoft%u00ae BizTalk%u00ae Server, that helps simplify and accelerate HL7 Integration solutions.

Cheers and keep on BizTalking

Peter

Technology Updates from PDC 2009 and BizTalk 2009-R2

by community-syndication | Nov 23, 2009 | BizTalk Community Blogs via Syndication

So PDC is over and boy did we get a lot of announcements with regards to our Connected System’s Technologies. We learned that the upcoming “Dublin” application server for WCF and WF components will formally be named Windows AppFabric. We also learned that Azure.NET Server has been renamed to Azure AppFabric. We also learned about the roadmap for BizTalk. You can expect BizTalk 2009-R2 will be arriving sometime at the end of next year. It will deliver enhancements in the follow areas:

• Platform Alignment – We will be supporting the latest servers and tools
• VS 2010
• Windows Server 2008-R2
• SQL Server 2008-R2
• Productivity Improvements
• A new dashboard to apply and manage performance parameters (today, tuning a BizTalk server is tricky to do as you have to be aware of a number of registry keys, database based parameters etc)
• PowerShell based capabilities for management tasks
• Updated SCOM object model to better reflect BizTalk artifacts
• B2B
• New Mapper enhancements to make it easier to work with and understand complex maps
• An FTPS adapter will be provided right out of the box.
• RFID
• Support for event filtering right out of the box

During the session, the team demo’d the new Mapper enhancements and got a great reaction from the crowd. For any of you who have ever struggled to keep your sanity when working with a large map, you’ll likely love these simple enhancements.

Now, at the PDC session (which you can view online http://microsoftpdc.com/Sessions/SVR15. ) they did more than just speak about 2009-R2. They also demoed some very-very early bits from v.NEXT+1 (i.e. the one after 2009-R2).  There are a number of key features that will be shipping in that version, the first and foremost being Windows Workflow (WF) integration into BizTalk.  With this integration, you will be able to choose whether or not to use classic BizTalk orchestrations or WF based workflows.  By integrating these two technologies, you can now do things like use the BizTalk mapper from within WF.  I encourage you to check out the recording of the session to see the full roadmap and product demos.

Cheers and keep on BizTalking

Peter

LIDNUG: Online chat with me Monday Nov 23rd

by community-syndication | Nov 23, 2009 | BizTalk Community Blogs via Syndication

Removing an InfoPath template part from the controls section

by community-syndication | Nov 22, 2009 | BizTalk Community Blogs via Syndication

Hi all

The other day I was given the task of updating an InfoPath template part that was
in use on a laptop, because a newer version of this template part was available.

Upon opening the InfoPath client, I saw this:

There were two template parts, and in this case they are named “TemplateGroup1” and
“TemplateGroup2”. I had a new version for the “TemplateGroup1” template part. I clicked
on “Add or Remove Custom Controls” and got this screen:

As you can see, the “TemplateGroup1” does not show up, which I thought was weird.
So, I tried clicking on “Add” to just add the new version of the “TemplateGroup1”,
but that gave me this error:

The custom control, <TemplateGroup1> (urn:schemas-microsoft-com:office:infopath:templategroup1:-myxsd-2009-11-22t19-43-32),
is already installed. Remove the existing custom control, and then try installing
again.

So, I was at a loss I couldn’t remove the existing version, and I couldn’t upload
a new version.

Finally, I discovered what had happened. The user has an entry in the registry like
this:

The key “IPCustomControlsFolder” is placed in the “HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\InfoPath\Designer”
path of the registry. All template parts you put into this folder are automatically
added to the controls of InfoPath.

So I found that path, and deleted the “TemplateGroup1” template part, and everything
was fine.

So, what I now know is, that there are two ways of adding new template parts to be
used by InfoPath:

1. Add them manually inside the InfoPath client (or the toolbox in VS.NET)
2. Add the right registry key to the registry, so you have a repository of template parts.
   This is especially useful for a repository on a shared network folder that can be
   used for all employees.

So if you ever have trouble removing a template parts from the custom controls section,
look for the registry key.

—

eliasen

My recap of the PDC 2009 preview of the BizTalk V.Next prototype

by community-syndication | Nov 22, 2009 | BizTalk Community Blogs via Syndication

Prior to joining Microsoft, I can’t tell you how many times I heard “will there be a convergence between BizTalk orchestrations and Windows Workflow Foundation? When do I use what? Are BizTalk Orchestrations going away?”. Since joining Microsoft, I’ve heard it even more. In fact, it has got to be the number one question I hear, and I’m sure that’s also true for many of you.

Last week at PDC 2009, Sriram did two things, he announced BizTalk Server 2009 (as I blogged about here), but also, he demonstrated some early prototype work that was being done around bringing together BizTalk, Windows Workflow Foundation, and Windows Server AppFabric. That announcement of R2 and the sneak preview of V.Next are significant enough that I decided to do a separate blog post about each.

Before we start though, let’s set expectations. What was shown in terms of WF/BizTalk integration was a very early prototype. This is NOT something you’ll be able to download next week, and put into production next month. This is early-stage code showing the direction the team is heading in. Have said that, if you follow my blog, you know that’s exactly the stage I like to get involved at :), and I feel it’s very important to keep an eye on the horizon and know what direction you’re heading in.

There are actually a few aspects to what was shown.

First and foremost, was WF integration into BizTalk. Let’s consider some of the motivations behind this:

• a common ask from customers is a low-latency solution (not all integrations require it, but in some cases, it can be a must-have). BizTalk is a reliable messaging platform, once a message is received, it is never, ever, lost. That reliability has a cost, as it means that there has to be durable storage (in our case SQL Server), and no matter how well tuned, persisting a message in durable storage has a latency cost associated with it
• sometimes people aren’t sure which way to go as there are four ways to compose services on the Microsoft stack (usually capabilities lead to a decision, but there can be overlap), with no easy migration path between them:
  1. using BizTalk orchestration
  2. using Windows Workflow Foundation
  3. using BizTalk ESB itineraries
  4. using custom code

Of those four, custom code is an option, but it puts a lot of responsibility on the developer to do “plumbing”. If or example you compose 3 services, and service #2 is unavailable, what do you do? You need to code protectively to respond to that. Or, service #2 returns a fault, what does that mean in terms of the overall composition and flow? Personally, I think a more efficient way to go about this is to let something else worry about the minutiae of the plumbing, which is what we get with the integration server capabilities of BizTalk Server.  So, although there will always be times where it is the right way to go, let’s leave custom code off the list for the rest of this post.

That leaves us with three options, two of which are  BizTalk options, and then WF which is currently completely outside BizTalk. As you probably know, with WF 3.5, if you wanted to host a workflow, you had two choices: use the hosting capabilities in SharePoint, or write your own host (which can be a daunting task depending on far you go towards being a fully featured enterprise-grade host). With .NET 4, that changes with the announcement of Windows Server AppFabric (which I blogged about here). What Sriram showed was a preview of what it make look like if WF were integrated into BizTalk.

From a BizTalker and SOA perspective, I really like the idea of having WF integrated into BizTalk, as it makes it centralizes the service composition mechanisms, and to some degree, helps mitigate the “when to use what” question as that can be reduced to a set of “common” guidelines. However, what he showed goes well beyond just using BizTalk projects as a shell from which to get at the WF designer, the integration goes much deeper than that, even in this early prototype. Bringing WF into BizTalk doesn’t change BizTalk, it extends it.

Here’s look at this from a Visual Studio perspective, notice the XAMLX files in a BizTalk project. Notice also the workflow designer. This is the same workflow designer that people will be used to working with Visual Studio 2010.

Bringing WF into the BizTalk environment brings benefits to the WF developers too. One of those is mapping, the screen shot below shows how you can have either a data contract or a schema on both source and destination sides, and regardless of which you pick, the experience is the same. That also means you get all of the new BizTalk Server 2009 R2 mapper goodness that I blogged about here. From there, as Sriram shows at about the 45 minute mark of his presentation, it’s a one-click operation to generate a workflow custom activity to invoke that map, and you can then work with in the WF designer by just dragging it from the palette onto the design surface.

From a deployment perspective, there was a crude prototype shown, this is obviously not what it would look like in final release. The thing to notice here is the fact that the workflow is being hosted in the BizTalkServerApplication host. So, if you follow that logic a step further (rampant speculation on my part!), then that means you could use the standard BizTalk host instance model to have certain workflows running in certain hosts, and then you have instances of those hosts on selected machines.

There’s a lot of cool stuff in this video, and it points to an interesting convergence of technologies in a future release of BizTalk. It also raises a bunch of questions for me, and adds to a long wish list (which I’ve communicated to the team :)). The bottom line though is that WF integration will give BizTalk developers the ability to handle low latency scenarios in a standard framework supported way, and it also add value for WF developers, as it provides them with the possibility of migrating their workflows into BizTalk and gaining additional capabilities as they do so.

What about Windows Server AppFabric and Windows Azure AppFabric?

What remains to be seen is how this fits into AppFabric, something the team is exploring now. An obvious one to me (rampant speculation!) is that AppFabric is just another host for the workflow (as it could be if the workflow were not part of a BizTalk project), be it Windows Server AppFabric or Windows Azure AppFabric, however perhaps getting there through the BizTalk deployment model and taking things like transformation activities with it. Even today, with BizTalk Server 2009, we have integration from BizTalk into Windows Server AppFabric (and also in the other direction) by going through WCF. So, the integration exists, and will only get deeper in future releases.

Finally.

The last point I want to make is something that may or may not be clear from these two BizTalk announcements. The announcements show Microsoft’s firm commitment to the 10,000+ current BizTalk customers, as well as to the product itself. The capabilities planned for BizTalk Server 2009 R2 and the capabilities shown last week for the release beyond that show the level of commitment and investment that Microsoft is making in the platform. As an insider who’s been involved with BizTalk since before the first release, I can tell you that the degree of enthusiasm and excitement in the product team is very, very real. They have great vision, and the resources they need to execute on that vision. The future keeps getting brighter, this has been a fun ride, and it looks like we have even more fun ahead.

The video of all of this is at http://microsoftpdc.com/Sessions/SVR15. The things I’ve talked about in this post are in the second half of the video.

Interview Webcasts from PDC09

by community-syndication | Nov 22, 2009 | BizTalk Community Blogs via Syndication

Video, Slides and Code Available from A Practical Exploration of the BizTalk BRE ACSUG Meeting

by community-syndication | Nov 21, 2009 | BizTalk Community Blogs via Syndication

If you are interested in the BizTalk Business Rules Engine here’s one for you: we have recorded the Auckland Connected Systems User Group meeting from last Thursday by Jeffrey Chilberto on ’A Practical Exploration of the BizTalk Business Rules Engine’. It’s a very hands on presentation that goes over basic and advanced topics – exposing […]