Marty Wasznicky - The "Event Driven Business"

Leaving Microsoft and Joining Neudesic's "Neuron ESB" team

martywaz — Sun, 16 Dec 2007 23:24:00 GMT

Well....I guess it was time. My last day at Microsoft was November 30th. Over 6 years working with the BizTalk team.....I'm a little sad to go. I really loved the BizTalk development world so this was a hard decision for me. Between working on customer projects, creating the Virtual Technical Specialist program, driving the business, conducting my training classes, and building the Microsoft ESB Guidance......I guess I kept myself pretty busy. However, everyone has to think about growth.....and I'm no different I guess. I worked with a lot of really smart people, Jean-Emile, Lee Graber, David Stucki, Kartik, John Taylor….well the list goes on. I'm going to miss everyone. However, I'll continue to develop ESB technologies in my new role at Neudesic.

I've joined their Neuron team to lead up development. If you haven't heard, Neuron is a pure WCF based ESB, the brain child of David Pallman, also formally of Microsoft's WCF product team. I'm pretty excited about it. We really have an opportunity to solve a lot of real world problems in short order. I've worked with Neudesic for almost 6 years while at Microsoft. They really have an amazing talent pool. It was certainly one of the things that compelled me to accept the role. Lots of smart people to work with! I’m looking forward to that. They probably have more experience building and solving these integration problems then most SIs…considering they were one my go to partners for the last 6 years for BizTalk related work. We’ll tap into all that solution experience to develop Neuron into a world class ESB.

Who knows….maybe I’ll actually start blogging J

Cheers!

CTP3 Update of the Microsoft Enterprise Service Bus Guidance

martywaz — Thu, 09 Aug 2007 17:53:00 GMT

Well....the project is humming a long....more cool things we're doing. Here's an email I sent out to some folks in the community

Announcing - August 2007 Community Release (CTP3) of ESB Guidance – http://www.codeplex.com/esb

By Marty Wasznicky
Field Program Manager, Connected Systems Division

As a result of our ongoing partnership with Patterns & Practices, we’ve released a new August Community (CTP3) build of the ESB Guidance on ESB Guidance community site, where all future iterations will be released until our final release in October later this year.

The CTP3 build introduces some new and augmented features such as:

New Resolver and Adapter Provider Framework provides “messaging” level end point resolution support for

UDDI

WS-MetaDataExchange

Business Rules Engine

XPath

STATIC

Messaging level Transformation services (uses new Resolver Framework). Allows BizTalk Maps to be executed in pipelines based on the following resolution methods

UDDI

WS-MetaDataExchange

Business Rules Engine

XPath

STATIC

Request-Response support for on and off ramps (partial)

WCF Adapter integration

UDDI publishing and query service

BizTalk runtime query service

New Dynamic Resolution Sample

Third party SOA Management and Governance integration:

SOA Software Integration

ESB Guidance documentation in CHM format J

The August 2007 CTP3 release focuses on the incorporation of Windows Communication Foundation (WCF), Request-Response Messaging, and the introduction of the Resolver and Adapter Provider Framework. The latter provides the runtime resolution and transformation support to enable both one-way and request-response pure messaging scenarios. The former (specifically the BizTalk WCF adapter) makes it all possible. Hence, key to this release, is the continued refactoring and integration into BizTalk Server 2006 R2—scheduled for release in September 2007. Additionally, we are releasing several infrastructure-based services to support our ongoing development work for the ESB Management Portal, as well as for two key SOA Governance partners, Amberpoint and SOA Software.

Our first goal was simply to ship WCF Adapter versions of our existing On-Ramps and Services, so that—over time—we could retire the older ASMX versions. WCF offers many advantages over ASMX, with the separation of interface and implementation being just one. WCF, specifically the WCF Adapter within BizTalk, goes a long way towards providing full Web Service WS* support for customers, without the need to write significant code. The WCF adapter makes WS-Security and WS-AtomicTransactions as easy as enabling a checkbox. More importantly, its loosely typed nature enables the use of true dynamic-resolution Web Services with BizTalk. This removes the requirement for generating and referencing SOAP Proxies compiled into .NET assemblies for routing to every resolved end-point (as was the case prior to the introduction of the BizTalk WCF Adapter).

Our second goal was to develop a robust architecture for high performance yet flexible runtime resolution and transformation at the messaging level, without the need for the existing Orchestration-based services developed in previous releases of the ESB Guidance. This architecture is required to support full Request-Response pure messaging scenarios. It must also support customers who want to develop their own resolution methods and plug them into our architecture, without having to rewrite our existing code.

The result is the Resolver and Adapter Provider Framework, which supports dynamic loading, caching, and invocation of registered Resolvers. The Resolver determines the end-point configuration and URI, given certain facts. The Adapter Providers then set the specific properties of a BizTalk Adapter. Adapter Providers leverage the same dynamic loading, caching and invocation mechanisms as Resolvers. This framework goes a long way towards enabling us to provide simple messaging scenarios, such as “transform-validate-route”, with all the configuration and information externally driven by policy from a registry or custom repository. Our primary goal with the framework was to develop an architecture that could separate the consumer from the service, enabling us to move towards more policy-driven messaging scenarios.

Our third goal was to develop and introduce some comprehensive, Web-based infrastructure services that both our ESB Management Portal and other third parties can query and leverage. The first of these services, the BizTalk Query Service, exposes BizTalk application, service, messaging, and health information. This service provides users with the ability to ask questions such as:

"What applications are deployed?"

"Where are they deployed?"

"What servers are they running on?"

"Which services are running and which are stopped?"

"Which host is the service running under?"

"What server is the host running on?"

"Is the host started on server B or server A?"

"Give me a list of the services deployed since 1/1/2007."

The second of the new services, the UDDI Service, supports querying and modifying the registration information stored in UDDI based registries.

Finally, we pursued the development of tighter integration with key SOA Governance vendors such as Amberpoint and SOA Software. Customers should not be forced to regard these, as well as our, technologies as isolated "black boxes" with one not able to leverage the features and functions of the other. A seamless integration experience, where one leverage the assets of the other, provides greater synergy, reduces complexity, and will lower the total operational cost of the solution. This can provide immediate benefits to our customers. For example:

SOA Governance tools and analytics can extend, and provide end-to-end visibility and tracking for the BizTalk native messaging subsystem and solutions; providing customers with a “one management view” of the solution.

BizTalk can enable SOA Governance vendors to become “transport-agnostic”; providing a functional transport bridge, rules, and orchestration technologies for customer solutions.

Integration of these technologies can provide centralized enforcement and management of end-points and policy across the entire solution, regardless of the transport or technology (such as WS*, FTP, FILE, MQSeries, JMS, SAP, Tibco, Peoplesoft, or Siebel) it uses.

We have been working with Amberpoint and SOA Software for several months and are now starting to see the results of our efforts. In fact, SOA Software has almost completed development of their integration code that demonstrates end-to-end SOA governance monitoring and policy enforcement within BizTalk. In this release, we include some of the documentation regarding the new SOA Software Management Point for BizTalk, as well as some screenshots and the URL of their web site where you can obtain more information.

Ultimately, I believe that the team accomplished the goals we set out for this release. We look forward to active feedback from all our users.

A more thorough description and screen shots of the SOA Software integration with BizTalk can be found below.

Cheers!

SOA Governance Integration

Enterprise-level applications must support robust and reliable management features in order to comply with business requirements, Government legislation, service level agreements (SLAs), and customer and trading partner expectations.

The SOA Software Management Point for BizTalk Server 2006 is an extension to SOA Software’s Web Services Management Point, applied specifically to the BizTalk Server 2006 environment, providing run-time governance for any BizTalk application regardless of transport.

The Management Point integrates natively with SOA Software Service Manager and Workbench products. Unlike the typical Web Services Management Point, this implementation is associated with services provided by BizTalk environment, expressed in terms of BizTalk server Receive Locations and Send Ports. Due to the arbitrary nature of Receive and Send Ports (configured against a variety of BizTalk Adapters) these services are not necessarily associated with Web Services, but can be treated as such in terms of the SOA Service Manager and SOA Workbench.

Figure 1 shows the SOA Service Manager Web application displaying the Workbench page for an example application. The left-hand tree view allows users to navigate through the applications and services installed within BizTalk, while the right-hand pane allows users to view application details, operations, access ports, categories, rules, and monitoring information.

Figure 1

The SOA Service Manager showing the monitoring features available in the Workbench page

You can monitor all the operations within an application (all Send Ports and Receive Locations), or specific operations, and the Workbench shows a list of the messages passing through the selected Send Ports and Receive Locations. When you double-click on a message in the list, the Workbench displays details of the message, and its context properties (provided that recording is enabled). Alternatively, you can select a specific service and monitor in real time messages passing through that service.

BizTalk Integration

The SOA Service Manager provides Wizards that help you set up the SOA Service Manager for use with BizTalk Server. For example, Figure 2 shows Wizard that helps you install and configure the BizTalk Integration Point that links BizTalk Send Ports and Receive Locations to the SOA Service Manager.

Figure 2

The SOA BizTalk Integration Point installation and configuration Wizard

After installation, the Service Manager can display details of the Send Ports and Receive locations configured by the Wizard. Figure 3 shows the Operations page displaying the name, interface, policy, and number of virtual operations for three Receive Locations and a Send Port.

Figure 3

A list of BizTalk Send Ports and Receive Locations displayed by the SOA Service Manager

Monitoring Policies and Usage Information

The SOA Service Manager provides a mechanism that allows you to create and edit monitoring policies. For example, Figure 4 shows the screen for applying a policy template and activating monitoring for an application.

Figure 4

The SOA Service Manager showing the monitoring features available in the Workbench page

The SOA Service Manager also provides usage information for applications, services, and individual Send Ports and Receive Locations. This information includes charts displaying the relative usage of each operation and usage over time, service usage, and response time information. Figure 5 shows some example.

Figure 5

A selection of the charts that the SOA Service Manager can generate to assist in monitoring server and application behavior and performance

In addition, SOA Service Manager includes features that allow you to view details of individual messages, including the size, response time, operation name, and the associated SOAP messages, as well as any exceptions that may occur in the BizTalk runtime environment, as shown in Figure 6.

Figure 6

The SOA Service Manager showing details of an individual message

SOA Software Service Manager and Workbench products are products from SOA Software, Inc. that integrate with BizTalk Server 2006. For more details of SOA Software and their products, and to download the latest installation and operational instructions, see http://www.soa.com/

Microsoft Enterprise Service Bus Guidance - Community Email

martywaz — Thu, 28 Jun 2007 18:37:00 GMT

Announcing - June 2007 Community Release of ESB Guidance – http://www.codeplex.com/esb

By Marty Wasznicky
Field Program Manager, Connected Systems Division

In October of 2006, we announced the preview of the Microsoft ESB Guidance at Microsoft SOA Conference in Redmond. This consisted of the following which enabled Microsoft partners and customers to build large and small-scale ESB solutions:

Sample code built on BizTalk Server 2006

Architectural guidance, patterns and practices

Reusable BizTalk Server ESB and .NET components:

Dynamic Transformation Service

Dynamic End Point/Configuration Service

Itinerary based Routing & Service Invocation

ESB Portal

Exception Management framework

Namespace Resolution Service

JMS (Java Message Service) pipeline component (IBM JMS over WMQ)

Since that time we’ve achieved significant momentum:

Several hundred requests for the ESB Guidance

Several dozen customers incorporating the guidance into their projects

Dedicated Microsoft ESB web site: http://www.microsoft.com/biztalk/solutions/soa/esb.mspx

Dedicated Partner site for delivering the ESB Guidance: http://www.microsoft.com/biztalk/solutions/soa/esbpartners.mspx

Press on the ESB Guidance from the SOA conference

http://www.cio.com/blog_view.html?CID=25511

http://www.crn.com/sections/breakingnews/dailyarchives.jhtml?articleId=193104205

http://www.infoworld.com/article/06/10/04/HNmsesbsoa_1.html

http://www.networkworld.com/news/2006/100406-microsoft-offers-esb-guidelines-for.html

http://www.pcwelt.de/mobile/pda/news20061005/582163/ (German)

http://www.programmazione.it/index.php?entity=eitem&idItem=34953 (Italian)

Due to the overwhelming demand and popularity of the ESB Guidance, we (the Connected Systems Division) and the Patterns and Practices group have agreed to jointly develop the ESB Guidance moving forward.

As a result of the iteration of this partnership, we’ve released a new June Community Release build of the ESB Guidance on the new ESB Guidance community site, where all future iterations will be released here until our final release in October later this year.

Although this June Community Release focused on bug fixes and refactoring the ESB Guidance for BizTalk 2006 R2, future releases will incorporate many new and augmented features such as:

UDDI publishing and richer resolution options

WS-MetadataExchange

Enhanced ESB Portal and Exception Mediation

Request-Response support for on and off ramps

WCF Adapter integration

New Samples and Guidance

Third party SOA Management and Governance integration:

Amberpoint Integration

SOA Software Integration

Through our partnership with Patterns and Practices, we hope to raise the bar of quality and build an extended community to support our customers as they move forward with the ESB Guidance.

With the Patterns and Practices partnership, we incur the benefit of having Don Smith (Product Manager for Patterns & Practices – don.smith@microsoft.com ) take an active role in owning the ESB Guidance Community. I will be coordinating feature development and community release schedules with Don, ensuring community feedback is incorporated into the ESB Guidance.

Please download the latest Community Release and provide us feedback. We will be monitoring the discussion forums on the site.

A more thorough description of the June Community Release can be found below.

Cheers!

About the June 2007 Community Release

This release focuses on refactoring the CTP build to accommodate the augmentation of existing features, as well as the addition of new features to be included within the final release targeted for October 2007.

Some of the changes for this release are:

· The project namespace changes from Microsoft.BizTalk.ESB to Microsoft.Practices.ESB

· All schemas follow W3C schema conventions for namespace, such as http://schemas.microsoft.biztalk.practices.esb.com/jms/system-properties

· Installation scripts and instructions for manual installation are provided

· All samples now install into the GlobalBank.ESB BizTalk application instead of their own individual applications

· The following components have been rebuilt to work with the BizTalk Server 2006 R2 Beta 2 and Release Candidate builds:

◦ JMS Pipeline Component

◦ Namespace Pipeline Component

◦ Exception Management API, InfoPath form and Pipeline component

◦ Transformation Service, Helper and Agent

◦ JMS Samples

◦ Exception Management Samples

◦ Namespace Samples

· This release contains several updates to integrate with .NET version 3.0:

◦ The Transformation Service is exposed as both an ASMX and a WCF service

◦ The Exception Management Fault Service is exposed as both an ASMX and a WCF service

◦ The UDDI helper class now uses native WCF calls and the features of .NET version 3.0. There is no longer a dependency on the Microsoft UDDI service (Microsoft.Uddi.dll)

· There are a number of fixes for components and services included in this release. For more details, see:

◦ Fixes for the Exception Management API

◦ Fixes for the Transformation Service

◦ Fixes for the JMS Component

◦ Fixes for the Namespace Component

◦ Fixes for the SetContext Component

Note: Although all other components in this release will compile and work with BizTalk Server R2, they still require some re-work. In addition, the ESB Exception Portal does not change in this release, and therefore the Exception Management Framework has not been tested with the older portal. The next community release will contain a prototype of the new portal.

Fixes for the Exception Management API

· The Exception Management API now supports exceptions that occur in child orchestrations executed using the CALL shape. For example:

◦ Orchestration A calls Orchestration B

◦ Orchestration B contains exception handling code that invokes the CreateFaultMessage method and assigns a fault message

◦ An exception occurs in Orchestration B and the ESB Exception Framework should publish the message

◦ The execution path no longer fails and causes an error within the CreateFaultMessage method

· InfoPath form rendering exceptions from the ESB Fault Processor pipeline no longer cause an error when scrolling through context properties

· The ESB processor pipeline now includes whitespace support in the reader

· The properties for the fault schema change in this release. There is no promotion of FaultDescription, and the description now accepts more than 255 characters

· Extension of the existing property schema supports additional internal error information

· The schema namespace changes, and the InfoPath template has been renamed

· Class references replace the string references for the context property name and namespace used when accessing context properties

· This release supports MIME-type detection for the body of a message

· Failed Message Routing scenarios now support flat files and binaries

· Streaming is implemented for large files

· Correct identification of the send port now occurs in one way messaging scenarios

· There is support for two-way messaging scenarios, such as the typical SOAP request-response cycle

· All project versions are now 1.0.0.1

· The native BTS stream libraries replace all custom streaming classes

· A new ContextProperties class allows pipeline components to access property information

· The orchestration time stamp in now expressed in UTC

· A new WCF-based Web Service exposes fault information

· All references to http://org.kp.esb.engine and the "bootcamp" namespaces in InfoPath schemas are removed

· New scripts update the Resources folder in the BizTalk Server application, and generate an MSI based on the resource artifact files

· Minor modifications to the code catch more exceptions, in particular by checking for null references

· The component detects non-HTML and non-text content, and encodes these as base-64 strings

· The reporting schema and InfoPath template now contain a MIME-type property

· There is support for rendering the content of XML CDATA sections

· The schema type for the content block within the reporting template changes from Any to CDATA

Fixes for the Transformation Service

· The Transformation Service now throws a null exception if the mapName parameter is null.

· The Transformation Service now has no dependency on the Microsoft UDDI service (Microsoft.Uddi.dll).

Fixes for the JMS Component

· The strong name key file binding now occurs during the linking phase so that the Manifest phase does not invalidate the signature of the assemblies.

· The component now uses the Microsoft.Practices.ESB.snk key file included with the source.

· The JMS Sample uses a new Queue Manager name, and only four queues.

Fixes for the Namespace Component

· The NamespaceException now inherits from ApplicationException, which corrects the issue where exceptions appear in the Event Log as "Reason: Unknown"

· Corrections to processing of the ExtractionXPath property solve previous extraction issues

· A new validation routine introduced prior to pipeline processing ensures that required properties are set at runtime

· Regular expressions now check that separator property value is valid (or is empty), that namespaces are not in the reserved range (ns0 to ns6), and that the specified namespace prefix is alphanumeric

· The component now checks that either the XPath or NamespaceBase property is set

· The component now compares the existing and the new namespaces, and just returns the original message to the pipeline if they are the same

· The component no longer raises an exception if the XPaths property is null, which allow the use of a static namespace if required

· Various string comparisons carried out within the component have been corrected

Fixes for the SetContext Component

· The component uses an updated namespaces for property schemas

· The component now exposes EndpointUddiServer and MapUddiServer properties

· The component now contains logic that ensures the value of a SOAP header is not overwritten by a property value provided in the pipeline instance rather than in the SOAP header

· There are several new trace statements that output the resolved endpoint

Marty Wasznicky
Regional Program Manager – BizTalk Server
Connected Systems Division
Microsoft Corporation

MCSE, MCSD, MCDBA, CNE, MCTS in BizTalk 2004

http://blogs.msdn.com/martywaz

333 S. Grand Ave., Suite 3300, Los Angeles, CA 90071

É213.806.7484È310.980.5495 martin.wasznicky@microsoft.com

BizTalk Server Webcasts:

http://msdn.microsoft.com/biztalk/Community/webcasts/default.aspx

BizTalk Server 2006 Virtual Labs:

http://www.microsoft.com/technet/prodtechnol/biztalk/virtual-labs.mspx

BizTalk Server 2006 Trial Download:

http://www.microsoft.com/biztalk/evaluation/trial/default.mspx

BizTalk Server 2006 Home Page:

http://www.microsoft.com/biztalk

Microsoft Enterprise Service Bus Guidance - Intro

martywaz — Thu, 28 Jun 2007 18:02:00 GMT

Wow......I can't even remember the last time I blogged. I've been living on an airplane; it seems like for years now. I guess an update is in order. I'm still working for Microsoft....in the Connected Systems Division. That's the place in Redmond where we build things like BizTalk, Host Integration Server and WCF. I still cover the West Region for Microsoft in Regards to BizTalk....as well as a bit of the Northeast Region. I still run the BizTalk Virtual TS program....a program I designed in SoCal back in 2004....but I've been able grow it across the nation where it now contributes to almost a third of the US BizTalk business. We've even got seeds of it growing in Canada and EMEA...pretty cool.

Most recently though I've been heads down on building the Microsoft ESB Guidance for BizTalk....a project I started about a year ago from the work that Lukas Cudrigh (Microsoft NorCal), Brian Loesgen (Neudesic) and I started at a major healthcare company (Kaiser). You can read all about it on Brian's blog (http://geekswithblogs.net/bloesgen/archive/2006/11/03/96062.aspx).

We released the first build of this last October at our Microsoft Redmond SOA event. As you can imagine....it took off like wild fire! We set up a Microsoft email alias for those interested in it. I got inundated with several hundred requests for it in a matter of months!

Short story, we were able to convince the powers that be that this was the way to go. I got the green light to move forward and we are now partnering with the Patterns and Practices team to revise and complete the Guidance to work BizTalk Server 2006 R2 (which we expect to release in September). The Guidance itself, we expect to ship shortly after R2, probably at the beginning of October this year. The ESB Guidance will be an official branded release by the Patterns and Practices team.

On the Patterns and Practices side, Don, Dmitri, Rajat, Alex and the team are keeping us honest and the quality bar high (I think Rajat spent his entire weekend just testing our latest drop). On the development side, I'm the architect and development lead for a small pack of Partner based resources (Sogeti, Magenic, CTS and Neudesic). We're a small but passionate group and, together, I think we're going to deliver one of heck of a package to the community.

As we continue to develop the features and dream of new things on the horizon, I'll try to keep my ideas posted here. In the meanwhile, I’ve posted below the latest email I sent to the community at large regarding our latest CTP release of the ESB Guidance on codeplex (www.codeplex.com/esb ). If you’re interested, you can also peruse through the current documentation on Alex’s site, http://www.daveandal.net/articles/esbdocs/

Cheers!

BizTalk 2004 "Commando" Training course - BizTalk Assembly Replication and Viewer

martywaz — Wed, 15 Jun 2005 01:20:00 GMT

BizTalk Server 2004 has a very cool architecture that allows it to balance the processing of a workload across many BizTalk Servers when they are configured to function as a group. When we use this "Group", or "Farm" configuration, all the BizTalk Servers share the same configuration and message box database. As workload increases or, for high availablity, we can push "BizTalk" applications (in the form of .Net assemblies) out to additional servers in the farm. In most cases, "pushing out" really just means "GAC'ing" the custom BizTalk application assemblies on the target BizTalk Servers within the farm.

What does this architecture give us? If the Orchestrations fail on one server, they can easily start up where they left off on the other server as all the state is managed in the database (not local machine queues). All we need to do is make sure that the application assemblies are GAC'd on all the servers we want to fail over to.

Today, people either have to do that manually or or use a third party tool to GAC assemblies.

But lets dream for a moment....wouldn't it be cool if we had a tool that would allow us to manage all the assemblies deployed within the BizTalk group? Imagine, that we could use this tool to list out all the assemblies registered in the BizTalk Management database, then check to see if they've been deployed to other servers within the BizTalk group. Then, when we find one that wasn't GAC'd on a specific server, we could press a button and wholla (did I spell that right :) ), the assemblies get deployed and GAC'd on the remote server and we didn't even have to leave our desks.

Well...this is possible now because of a BizTalk Escalation Engineer that works for Microsoft Premier Services, Rick Caudle. He wrote the BizTalk Assembly Checker, which does exactly what I described above.

When we launch the tool, we'll see a view that allows us to specify the SQL Server that the Management database is located on and connect to it. Once we connect, it will list all the BizTalk Servers and deployed application assemblies registered in the BizTalk Group. The tool allows us to select each server and check to see the assemblies are deployed.

If we need to copy and GAC the assemblies on one of the servers, we just click the GAC Tool button which brings up the dialog box below:

Check whether we want to copy the assemblies locally and GAC them and click the OK button.....the tool does the rest:

You can download the tool as well as the latest build source code from here.

BizTalk 2004 "Commando" Training course - Installing Windows Sharepoint Servcies Batch File

martywaz — Tue, 14 Jun 2005 23:57:00 GMT

Installing BizTalk Server 2004 sometimes entails installing Windows Sharepoint Services, specifically if you want to use Business Activity Services (Trading Party Mgmt, BAM portal, etc..). However, I see more and more folks configuring it improperly, hence the BizTalk Server installation fails when trying to install our BAS site or updating the infopath templates.

The product group is pretty good about updating the Installation Guide for BizTalk Server 2004. In fact, you can find the latest published guide (February 05) at http://www.microsoft.com/technet/prodtechnol/biztalk/biztalk2004/deploy/install_guide.mspx.

In the guide it reads:

To configure Windows SharePoint Services

If it is not already open, open SharePoint Central Administration. On the Start menu, point to Programs, point to Administrative Tools and then click SharePoint Central Administration.
On the SharePoint Central Administration page, under Server Configuration, select Configure virtual server for central administration.
On the Configure Administrative Virtual Server page, select Use an existing application pool if one already exists. If this is your first Windows SharePoint Services configuration, select Create a new application pool. Enter an application pool name. For example, SpsAdminAppPool.
Select a Configurable security account and use a local administrator. Click OK. You will be prompted to restart IIS at this point. Click OK.
After IIS restarts, open SharePoint Central Administration. On the SharePoint Central Administration page, under Server Configuration, select Set configuration database server.
On the Set Configuration Database Server page, enter values for Database server name and SQL Server database name. Next, specify your database connection type. Click OK.
On the SharePoint Central Administration page, under Virtual Server Configuration, select Extend or upgrade virtual server. The Windows SharePoint Services Virtual Server List page appears.
On the Windows SharePoint Services Virtual Server List page, if there are no servers in the list, click the Go to the complete list link. The complete list appears.
Select the server you want to extend.
Click Extend and create a content database.
On the Extend and Create Content Database page, under Application Pool enter an Application pool name. For example, SpsWebSiteAppPool.
Select a Configurable security account and use a local administrator.
Click OK.

By default, Windows SharePoint Services includes the root of the IIS default Web site as a managed path. To create a virtual directory on a Windows SharePoint Services-extended virtual server for your own use (for example, for a BizTalk Server receive location or for a Web service application), you must exclude the URL for your virtual directory from the Windows SharePoint Services managed paths. Alternatively, if you have not configured a top-level Windows SharePoint Services site on the root of the IIS Web site, you may remove the root as a managed path.

To configure Managed Paths in Windows SharePoint Services

If it is not already open, open SharePoint Central Administration. On the Start menu, point to Programs, point to Administrative Tools and then click SharePoint Central Administration.
Click the Configure virtual server settings link.
Click on the server that you extended.
Under Virtual Server Management, click on Define managed paths.
Under Included Paths select the (root) checkbox and click the Remove selected paths link.
Click the Windows SharePoint Services link to return to the SharePoint Central Administration site.

For information about how to configure managed paths from the command line, see the topic "Managing Paths" in Microsoft Windows SharePoint Services Administrator's Guide at http://go.microsoft.com/fwlink/?LinkId=18110.

So, you can see, there's a few things you have to do to configure it properly. In the past, I've taken all this and just put it in a batch file to simplify the process. You'll find the text of the batch file below. I literally just run this instead of running the setup independently and doing all the configuration manually. I avoid common mistakes this way.

You'll see I declare some variables at the top of the batch file. These set the path of the WSS installation executable, the server and port which WSS is being installed on, the user id, password and email address that the WSS service will run under (make sure they are members of the local IIS_WPG group), the database server in which to create the content and configuration database, ports and the name of the configuration database to create.

Next, I basically execute the following steps:

1. Install WSS using the remote Sql option

2. Remove front page extensions from the web site I'm installing WSS on

3. Configure the WSS admin site and the application pool for it, including the credentials it runs under

4. Create the WSS configuration database

5. Extend the virtual server on the default site and set credentials

6. Lastly, I delete the root as a managed path under WSS.

Cheers!

@SET WSSEXE          = C:\WUTemp\Platform\WSSV2\STS2Setup_1033
@SET WSSSERVER   = bts04dev01:80
@SET WSSUSERID    = waz-msft\WSSAdminSvc
@SET WSSPWD         = pass@word1
@SET WSSEMAIL      = WSSAdminSvc@waz.msft.com
@SET DBSERVER      = BTS2004sql01
@SET FPPORT           = 80
@SET ADMINPORT   = 8080
@SET WSSCONFIGDB = WSSConfig

%WSSEXE%\SETUPSTS.EXE remotesql=yes /qb

"c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\50\BIN\owsadm.exe" -o fulluninstall -p %FPPORT%

"c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\BIN\stsadm" -o setadminport -p %ADMINPORT% -admapcreatenew -admapidname adminvs -admapidtype configurableid -admapidlogin %WSSUSERID% -admapidpwd %WSSPWD%

"c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\BIN\stsadm" -o setconfigdb -ds %DBSERVER% -dn %WSSCONFIGDB%

"c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\BIN\stsadm" -o extendvs -url http://%WSSSERVER% -ownerlogin %WSSUSERID% -owneremail %WSSEMAIL% -apcreatenew -apidname defaultvs -apidtype configurableid -apidlogin %WSSUSERID% -apidpwd %WSSPWD%

"c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\BIN\stsadm" -o deletepath -url http://%WSSSERVER%

New White Papers...

martywaz — Fri, 10 Jun 2005 03:30:00 GMT

We've been at it again. If you haven't seen these, check out these new white papers:

BizTalk Server 2004: A Messaging Engine Overview. This document describes the architecture and internal workings of BizTalk Server 2004 as a messaging engine.
BizTalk Server 2004 and Web Services. This paper discusses how BizTalk Server 2004 supports the use of Web services in building solutions.
Transactions Across BizTalk Server 2004. This document details transactional characteristics of BizTalk Server 2004 and how they apply across components, such as messaging, pipeline, and orchestration. It also describes how to construct business processes to guarantee message delivery.
Working With BizTalk Adapter for SQL Server. This document provides general knowledge about the BizTalk Adapter for SQL Server. It gives suggestions about when to use the SQL transport and how to retrieve, insert, update, and delete data. It also includes code samples

Tech-Ed Announcements - BizTalk 2006 Launch

martywaz — Fri, 10 Jun 2005 02:26:00 GMT

A lot of folks heard at the Tech-Ed Keynote address on June 7 that we will have a joint launch of Visual Studio 2005, SQL Server 2005 and BizTalk Server 2006 on November 7, 2005.

Please do NOT confuse this with the RTM (Release to Manufacturing) date of BizTalk Server 2006. BizTalk Server 2006 is still scheduled to RTM during the 1st Quarter of 2006. November is just when the Joint Launch "Party" will take place

BizTalk 2004 "Commando" Training course - BETTER Dynamic Mapping

martywaz — Wed, 08 Jun 2005 14:18:00 GMT

I just posted a pretty cool sample of how you could call a map dynmically in C#. Very nice. However, it has a drawback (besides being officially unsupported).

Specifically, the way I used TransformBase in the sample will result in regenerating a dynamic assembly for the xslt every time the code is executed. We'd run out of memory very quickly.

Here's the solution. One of our engineers, Yossi Levanoni, created the Metadata classes that basically cache everything there is to cache for any of the XLANG artifacts, including maps.

By replacing these lines of code:

    Assembly mapAssembly = Assembly.LoadWithPartialName("EAISchemas");
    Type mapTypeClass = mapAssembly.GetType("EAISchemas.MapToReqDenied");

    TransformBase map = (TransformBase)System.Activator.CreateInstance(mapTypeClass);
    XslTransform transform = map.Transform;
    XsltArgumentList argList = map.TransformArgs;

With this :

using Microsoft.XLANGs.RuntimeTypes;

XslTransform transform = TransformMetaData.For(typeof(EAISchemas.MapToReqDenied)).Transform;
XsltArgumentList argList = TransformMetaData.For(typeof(EAISchemas.MapToReqDenied)).ArgumentList;

Will result in the maps being pulled from our Cache rather than from the Assembly each and every time....

Pretty cool stuff!

BizTalk 2004 "Commando" Training course - Dynamic Mapping

martywaz — Wed, 08 Jun 2005 06:44:00 GMT

Every wonder how you could possibly reuse the XSLT that we store in BizTalk maps? Every wonder how you could pick and chose which map to execute in your code from the compiled BizTalk Assembly. Well there is a way! The type containing the map xslt is devired from TransformBase contained in Microsoft.XLANGs.BaseTypes. We can use that object to extract the xslTransform and the xslArgumentList objects from the BizTalk Map Type residing in the assembly and pass them to TransformMessage. Pretty cool. This allows you to resuse BizTalk maps and call them dynamically as you see fit. For example, imagine the case of dynamic send ports where you also need to determine the map execution model dynamically or through a set of rules. Remember though, this is completely Unsupported by Microsoft.

I put together a simple project from the shipped EAISolutions tutorial. I added the EAIUtilies project to it which has the code for this. This code is then called within a message assignment shape within the EAIOrchestration project to create a new message from the executed map. Thanks Ashwani for helping me troubleshoot.

Download the project ..Check it out..

sing System;
using System.Xml;
using System.Xml.Xsl;
using Microsoft.XLANGs.BaseTypes;
using System.Reflection;
using System.IO;
using System.Text;
using System.Xml.XPath;

namespace EAI.Utilities
{
/// <summary>
/// Summary description for Class1.
/// </summary>
[Serializable()]
public class MapHelper
{
  public MapHelper()
  {
  }
  public static XmlDocument GetMappedDoc(Microsoft.XLANGs.BaseTypes.XLANGMessage msg)
  {

   XmlDocument xmlDocOutputMsg = new XmlDocument();
   XmlDocument xmlDocInputMsg = null;

   try
   {
    xmlDocInputMsg = (XmlDocument)msg[0].RetrieveAs(typeof(XmlDocument));

Assembly mapAssembly = Assembly.LoadWithPartialName("EAISchemas");
Type mapTypeClass = mapAssembly.GetType("EAISchemas.MapToReqDenied");

    TransformBase map = (TransformBase)System.Activator.CreateInstance(mapTypeClass);
    XslTransform transform = map.Transform;
    XsltArgumentList argList = map.TransformArgs;

    xmlDocOutputMsg = TransformMessage(transform,argList,xmlDocInputMsg);

   }
   catch (Exception exc)
   {
    System.Diagnostics.EventLog.WriteEntry("mapHelper",exc.InnerException.ToString());

}
return xmlDocOutputMsg;

  }
  private static XmlDocument TransformMessage(XslTransform xslt,XsltArgumentList args,XmlDocument sourceDoc)
  {
   XmlNodeReader sourceRoot=new XmlNodeReader(sourceDoc);
   XPathDocument srcXPath=new XPathDocument(sourceRoot);
   MemoryStream stm = new MemoryStream();

XmlTextWriter writer = new XmlTextWriter(stm,System.Text.Encoding.Unicode);

xslt.Transform(srcXPath,args,writer,null);

   stm.Flush();
   stm.Seek(0,SeekOrigin.Begin);

   XmlTextReader destReader;
   XmlDocument destDoc;

try
{

    destReader= new XmlTextReader(stm);
    destDoc = new XmlDocument();
    destDoc.Load(destReader);
    return destDoc;

   }
   finally
   {
   }
  }
}
}

BizTalk 2004 "Commando" Training course - More posts to come...

martywaz — Tue, 07 Jun 2005 07:19:00 GMT

Done for the night....I'll post a lot more later this week...

BizTalk 2004 "Commando" Training course - App Domains

martywaz — Tue, 07 Jun 2005 06:52:00 GMT

Remember, during the course we went over App Domain configuration for BizTalk. The key to creating App Domains with BizTalk, and hence being able to use configuration files with your project is to edit the BTSNTSvc.exe.config file located in the BizTalk program directory. The next key is to make sure you put the right sections in the right spot within the config file, else the BizTalk service will never start again (I ran into this myself once).

Why would you use them? Well, here's a couple of reasons:

1) It gives you the ability to configure them separately. This is useful for orchestrations that use 3rd party component that read their configuration for the config file and you have different requirements for these 3rd party components when they are used from different orchestrations. You can also specify an assembly search-path on a per-app-domain basis.

2) The unit of code-unloading in .Net is app-domain. If you put separate orchestrations into app-domains there is an opportunity to unload some of them while the rest are still in use. For example, you can put you frequently used orchestrations into a "hot" app-domain and the less-used orchestrations into a "cold" app-domain. The hot app-domain will be continually used. The cold app-domain will get recycled after 25 minutes of idle time. You can control the unloading times with app-domain configuration (see MSDN).

3) It gives you some level of isolation. For example, if you have a singleton object---you'll actually get one per app-domain---so one orchestration cannot mess the other orchestration's singleton.

4) Internally, XLANG can use app-domains to host different versions of the XLANG runtime (e.g., Voyager vs. Pathfinder)

Here's a sample of the edits to the BizTalk config file. Remember, the configSections comes first, and the sections it defines comes last....all the new additions are in RED.

<?xml version="1.0" ?>
<configuration>
<configSections>
  <section
  name="xlangs"
  type="Microsoft.XLANGs.BizTalk.CrossProcess.XmlSerializationConfigurationSectionHandler, Microsoft.XLANGs.BizTalk.CrossProcess" />
</configSections>

    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <probing privatePath="BizTalk Assemblies;Developer Tools;Tracking;Tracking\interop" />
        </assemblyBinding>
    </runtime>

    <system.runtime.remoting>

        <channelSinkProviders>
            <serverProviders>
                <provider id="sspi" type="Microsoft.BizTalk.XLANGs.BTXEngine.SecurityServerChannelSinkProvider,Microsoft.XLANGs.BizTalk.Engine" securityPackage="ntlm" authenticationLevel="packetPrivacy" />
            </serverProviders>
        </channelSinkProviders>

        <application>
            <channels>
                <channel ref="tcp" port="0" name="">
                 <serverProviders>
                     <provider ref="sspi" />
                        <formatter ref="binary" typeFilterLevel="Full"/>
                    </serverProviders>
                </channel>
            </channels>
        </application>
    </system.runtime.remoting>
    <xlangs>
  <Configuration>
   <AppDomains AssembliesPerDomain="10">
    <DefaultSpec SecondsIdleBeforeShutdown="5" SecondsEmptyBeforeShutdown="5">
    </DefaultSpec>
    <AppDomainSpecs>
        <AppDomainSpec Name="MyAppDomain">
            <BaseSetup>
                <ConfigurationFile>C:\Projects\Projects\AppDomainConfig\MyAppDomainConfiguration.config</ConfigurationFile>
            </BaseSetup>
        </AppDomainSpec>
    </AppDomainSpecs>
    <PatternAssignmentRules>
     <PatternAssignmentRule AssemblyNamePattern="AppDomainConfig.*" AppDomainName="MyAppDomain" />
    </PatternAssignmentRules>
   </AppDomains>
  </Configuration>
     </xlangs>
</configuration>

Lastly, here's the sample we walked through in class. Yossi Levanoni put this together back in September of 03'.

The sample demonstrates how to instruct the orchestration engine to execute top-level (i.e., not-called) orchestrations from a particular assembly in a particular app domain; then how to specify configuration for this domain. In this sample, a configuration file is associated with the domain. The config file contains a custom configuration section. The test orchestration calls into user code and consumes this custom configuration section. The data is inserted into a flat-file-like XLANG message which is sent to an output folder.

To test it:

1) Compile.

2) Gac/deploy/modify binding.

3) Copy the BTSNTSvc.exe.config to your program files dir. You might want to edit this file so that it points to the correct location for MyAppDomainConfiguration.Config on your machine.

4) Drop any file (it's just used to start the orchestration) with .xml extension into DataFolders\in.

5) You should see a file with a name like ConfigOut_<guid>.txt generated in DataFolders\out.

6) The contents of the file are:

key="setting1" val="Value1"

key="setting2" val="value two"

key="setting3" val="third value"

Which corresponds to the contents of MyAppDomainConfiguration.config:

<?xml version="1.0"?>

<section name="sampleSection"

type="System.Configuration.SingleTagSectionHandler" />

</configSections>

<sampleSection setting1="Value1" setting2="value two"

setting3="third value" /> </configuration>

Compiled BizTalk 2004 Help File (.chm)

martywaz — Tue, 07 Jun 2005 06:36:00 GMT

I find this very handy for my laptop that does NOT have BizTalk Server 2004 installed on it. Its a compiled version of the online docs....a

convenient chm file. Its updated to SP1. Enjoy.

BizTalk Server 2004 SP1 should be MANDATORY for production environments

martywaz — Tue, 07 Jun 2005 06:22:00 GMT

I can't believe I see more and more recent BizTalk implemenations in production WITHOUT SP1. With all the issues that we fixed in SP1, any new BizTalk Server 2004 project should simply never go into production without SP1. I can't stress that enough. The product team did phenomenal work raising the bar on the quality of this service pack. It can be downloaded here.

Additionally, I would also recommend that you contact premier support and ask for the following POST SP1 fixes, if you encounter any of the issues described below...which you undoubtedly will.

lDatabase Functoid Caching - you'll see this if you're using our database functoid...just get it if you are trying to use our database functoids.

lDelivery Notification forcing dehydration of orchestration - you'll see this if using DN in orchestration....another "just get it" if you are using DN.

lSide by Side Deployment

lPerformance degradation with Singleton Orchestration - under certain conditions, using transactions is one of them, you'll run into this.

lLeak in WMI provider

lBody Tracking before receive

lOOM Errors with MQSeries Adapter ****

lPipeline versions Side by Side

lEDI adapter update (KB894785) - Fixes a lot of things...

lMicrosoft.XLANGs.Core.PersistenceException - I've seen this almost every time....I would say just get it as well.

File Adapter losing files if SQL shuts down - this is a bad one.....another "just get it" fix.

BizTalk 2004 "Commando" Training course - Decks and Samples

martywaz — Tue, 07 Jun 2005 05:40:00 GMT

Here's the powerpoint decks we used for some of the extended sessions. Some of these have added sections on all the perf tuning recommendations we layed out. There's quite a bit that you have to consider when working in a farm scenario. Also, you'll find some best practice around flat file, and the Flat File project I walked you through building. In all you'll find the following:

1. Advanced Orchestration

2. Rules Engine

3. Building Pipelines

4. Messaging and Flat File best practice

5. Installation of farms and best practice and tuning parameters

Here are the decks, and here is the project we walked through to demonstrate parsing Flat Files...