Real World Architecture from the front lines - GISV Architecture Team Blog

Silverlight and Java Interoperability: Providing the Next Generation Web User Experience

2008-07-01T07:26:00Z

Posted by Robert Bell, Senior Solutions Architect

One of the areas that team our assists GISVs (Global Independent Software Vendors) is with interoperability between .NET and Java. A particular area of interest of both .NET and Java developers is using Silverlight to implement rich, cross-browser, cross-platform, multi-media experiences. At this years’ JavaOne2008 conference Robert Bell and Laurence Moroney presented a session on “Next Gen Web UX Interop with Java EE & Silverlight”; this post is a summarization of the technical approaches discussed.

The session covered some basic concepts of Silverlight, and focused on the various ways that Silverlight can interoperate with Java. Silverlight is a positioned for “reach” scenarios where rich internet applications can be quickly deployed to clients the internet. “Silverlight is designed for Web page content that is connected to its host (it will not work offline), that deeply engages the user, and that can render on any browser.” ( Scenarios for Using Silverlight)

For a great example of what is possible using Silverlight, has a look at the Silver Financials Demo – see screen shot below.

Figure 1 Silver Financials Demo

If the Silverlight plug-in is not installed, you will be prompted do download the Silverlight 2 plug-in, once the plug-in is installed the Silverlight application should run. The source code for the Silver Financials Demo is here.

This blog focuses on key approaches you can take to create a hybrid Silverlight-Java application. The current release of Silverlight is Silverlight 2 beta 2.

Silverlight-Java Interoperability Scenarios

There are a few key scenarios of using Silverlight in conjunction with Java applications. These scenarios as described below range from disconnected - where Silverlight content is embedded within a Java web artifact (e.g. JSP page, etc) and runs standalone within web browser - to connected, where a Silverlight application running in the browser communicates back to a Java server (e.g. using web services, etc). The Silverlight ‘content’ here is defined in a combination of markup language and code – specifically, EXtensible Application Markup Language (XAML) (XAML is an XML markup language that describes the User Interface elements, styling, behavior, etc) and code (JavaScript or managed language like C# or VB.NET). The Demo setup is required to be able to run the various interoperability scenarios that are patterned after a simple fortune telling (Magic 8 Ball) scenario.

Demo Setup

Java Environment

The Java SE Development Kit 6 update 5 (jdk-6u6-windows-i586-p-iftw.exe) was installed along with the Java Platform Enterprise Edition 5 Tools Bundle Update 5 (java-tools-bundle-update5-windows.exe). These files may be obtained from http://developers.sun.com/downloads/. There are two web application projects: Magic8Ball and Magic8BallSOAP. The SOAP scenario is run in the Magic8Ball SOAP project and all of the other scenarios are run in the Magic8Ball project. The file clientaccesspolicy.xml must be moved to the docroot directory in the Glassfish V2 server.

Silverlight .NET Environment

Visual Studio 2008 Express Edition may be downloaded here, then to setup the Silverlight 2 beta 2 environment follows the instructions on the Silverlight Get Started. There are three Visual Studio projects: POX, Syndication and SOAP2.2.

Scenario Overviews

1. Static Silverlight Content Embedded within a Java EE 5 JSP

This is the most basic Silverlight scenario where a Silverlight control is instantiated through JavaScript; then the Silverlight control renders XAML that is included in a JSP page. The presentation logic is on the Java server in this scenario.

2. Silverlight Content Dynamically Generated at Runtime within a Java EE 5 JSP

This scenario is the same as the “Silverlight-Java with Static XAML “except the XAML is dynamically modified by the XamlSource Servlet then included in a JSP. A parameter passed to the XamlSource Servlet is used to lookup a matching value that is then used to modify the XAML. Note that for there is a page refresh each time a new parameter is passed in and the value on the Silverlight control is updated. The presentation logic is on the Java server in this scenario.

3. Silverlight Client Application communicating with a Java Application Server

These scenarios all involve a Silverlight client application that is running in a browser, inside an HTML page, that communicates to a Java server POX, SOAP or Syndication service over HTTP (HTTP/SOAP with SOAP web services).

These scenarios require the use of Visual Studio 2008 to develop the Silverlight client application; they leverage the full potential of Silverlight through the creation of a Silverlight application in Visual Studio. In all of these scenarios the presentation logic is on the Silverlight client. There are variants of this scenario, dependent on wire level format and messaging approach:

a. Plain Old XML (POX) Service

The NetBeans Magic8Ball project and the Visual Studio POX project are used in this scenario. In this simple POX service scenario a parameter is passed into the PoxService servlet where a value is looked-up then put into a POX response. The Silverlight plug-in receives the XAML response parses it then renders the response in the Silverlight control. Note that Silverlight 2 beta 2 also supports a “POST” request. This same basic approach may be enhanced to build a REST (REpresentational State Transfer) service.

b. SOAP Web Service

The Magic8BallSOAP NetBeans project and the Visual Studio SOAP2.2 project are used in this scenario. The ability to create the proxy for the Java web service in Visual Studio makes connecting the “plumbing” of web services very straightforward and transparent. A basic SOAP web service endpoint is created in Java then a proxy is created in Visual Studio for the basic web service endpoint. The web service is call passes in a request parameter then receives the web service response. The web service response is bound to the XAML, which in turn is rendered on the Silverlight control.

c. Syndication (RSS) Feed Service

The Magic8Ball NetBeans project and the Visual Studio POX project are is used in this scenario. RSS syndication is most often used to “subscribe” to content such as a blog. RSS 2.0 is a light-weight publish/subscribe standard. There are pull scenarios where a client asynchronously accesses the RSS service feed to see the updated content of a blog for instance; an there are push like scenarios where a client will asynchronously poll an RSS service feed to effectively get real time data. The push-like scenarios more involved and will be discussed in a later blog. Note that both RSS 2.0 and Atom are supported by the Silverlight syndication. In the scenario below a simple RSS feed is created in Java then a Silverlight client accesses the feed through the feed URI.

Static Silverlight Content Embedded within a Java EE 5 JSP

Figure 2: Silverlight-Java with Static Silverlight Content Embedded within a Java EE 5 JSP

This scenario has everything necessary to deliver a Silverlight client on a single JSP page. In the JSP page the Silverlight control is instantiated, and the static XAML (user interface) content within the same JSP page, is associated to the Silverlight Control through the script tag (Id ="xamlContent").

This is the Silverlight Control.

</a>

</object>

</div>

Figure 3: Silverlight-Java with Static Silverlight Content Embedded within a Java EE 5 JSP.jsp Silverlight

This is the XAML.

<TextBlock Margin="0,0,0,0" VerticalAlignment="Top" Height="38"

Text="Magic 8 Ball" TextWrapping="Wrap" Opacity="0.8" FontSize="24"/>

…

</Grid>

</Canvas>

</script>

Figure 4: Silverlight-Java with Static Silverlight Content Embedded within a Java EE 5 JSP

Silverlight Content Dynamically Generated at Runtime within a Java EE 5 JSP

Figure 5: Silverlight-Java with Silverlight Content Dynamically Generated at Runtime within a Java EE 5 JSP

In this simple POX service scenario a parameter is passed into the PoxService servlet in a GET HTTP method from the POX project Silverlight client application. The parameter value is retrieved and the “look-up value” is placed in an XAML (POX) response. The Silverlight plug-in receives the XAML response, parses it, and then renders the response in the Silverlight control. Note that Silverlight 2 beta 2 also supports the POST HTTP method.

First, this inline code gets the request parameter in the JSP:

String strSeed="";

if (request.getParameter("seed") == null) {

strSeed = "5";

} else {

strSeed = request.getParameter("seed");

}

Figure 6: Silverlight-Java with Silverlight Content Dynamically Generated at Runtime within a Java EE 5 JSP.jsp

Then, this script includes the XAML from the XamlSource Servlet that has been passed the request parameter “seed”, and then the script is consumed by the Silverlight control:

<jsp:include page="/XamlSource" flush="false" >

<jsp:param name="seed" value="<%=strSeed%>" />

</jsp:include>

</script>

Figure 7: Silverlight-Java with Silverlight Content Dynamically Generated at Runtime within a Java EE 5 JSP.jsp

The XamlSource Servlet accepts the “seed” parameter:

String seed = request.getParameter("seed");

Figure 8: XamlSource.java

The Fortune String is obtained through the getFortune method which accepts the “seed” parameter:

String nodeValue = getFortune(new Integer(seed).intValue());

Figure 9: XamlSource.java

The elements of interest in the XAML.xml template file are the x:Name and Text elements:

Figure 10: XAML.xml

In the XamlSource Servlet, XPATH is used to define the XPATH address, find the node and then change the node value. The article How to Query XML using XPath gives an in depth explanation of querying XPath.

The XamlSource servlet is then included in the JSP:

<jsp:include page="/XamlSource" flush="false" >

<jsp:param name="seed" value="<%=strSeed%>" />

</jsp:include>

</script>

Figure 11: Silverlight-Java with Silverlight Content Dynamically Generated at Runtime within a Java EE 5 JSP.jsp

Here the seed “5” is placed on the Magic 8 Ball and the txtFortune value is "Don’t count on it":

Silverlight Client Application communicating with a Java Application Server Scenarios

To prevent cross-site request forgery, Silverlight only allows site-of-origin communication by default for all requests other than images and media. However, cross-domain services can explicitly opt-in, allowing the Silverlight control to access a service in another domain. This is supported through the use of a ‘clientaccesspolicy.xml’ file on the service endpoint.

Since domain boundaries are crossed in these scenarios, the Silverlight ‘clientaccesspolicy.xml’ file is placed in the document root directory of the Java web server to make the service available. For more information on domain boundaries see: Make a Service Available Across Domain Boundaries

Plain Old XML (POX) Service

A POX service is a very simple service where a query parameter is sent on the request to a servlet, the parameter is processed, and then an XML response is returned. This type of service is simple to implement, however the expected request and response format must be explicitly provided by the POX service creator.

Figure 12: POX Service

The request parameter passed to the Magic8Ball Servlet is used to lookup a matching value that is then used to create a POX response:

out.println("<xml>");

out.println("<value v='" + getFortune(nSeed) + "' />");

out.println("</xml>");

Figure 13: PoxService.java

Figure 14: Response from the PoxServlet

The XML response is consumed by the Silverlight application and rendered in the Silverlight control:

Figure 15: Page.xaml

WebClient is used to access the Magic8Ball URI. Then, in the DownloadStringCompleted event, the XML result is parsed with LINQ (Language Integrated Query). Language Integrated Query (LINQ) is general-purpose query facilities to the .NET Framework that apply to all sources of information; in this case the “SQL-like” LINQ-to-XML is used.

String strValue = "";

XDocument xReturn = XDocument.Parse(e.Result);

//Language Integrated Query (LINQ)

IEnumerable<XElement> list1 =

from element in xReturn.Descendants("value")

select element;

foreach (XElement element in list1)

strValue = element.Attribute("v").Value;

Figure 16: Page.xaml.cs

The Result value is bound to the XAML TextBlock in the “txtFortune.Text = strValue;” line in Page.xaml.cs.

//Bind the value to the XAML TextBlock

txtFortune.Text = strValue;

Figure 16: Page.xaml.cs

SOAP Web Service

The web services standards, defined by the Web Services Interoperability Organization (WS-I ), are based on Simple Object Access Protocol (SOAP); SOAP is an XML based protocol that allows messages to be passed over HTTP/HTTPS. W3C has a Web Services Architecture document that lays the foundation for SOAP web services. If a SOAP web service already exists, it is fairly straightforward to create a proxy for that web service, then utilize that web service in Visual Studio. One must caution that the use of complex data types in a web service can be problematic, especially in Java-.NET interoperability scenarios. Java SOAP web service data types should map to the .NET supported data types .

Debugging web services can also be problematic. Tools like the Fiddler web debugging proxy or the Web Development Helper can be useful in debugging web services.

Figure 17: SOAP web service

A proxy is created in Visual Studio for the Java SOAP web service endpoint. The web service call passes in a request parameter and then receives the web service response. The web service response (String) is bound to the XAML, which in turn is rendered on the Silverlight control.

Figure 18: JavaServiceReference proxy reference

Silverlight does not have WS-* support beyond WS-I Basic Profile, “but it is still possible to consume services that use these protocols by manually implementing the required protocol” (Accessing SOAP Services). WS-I Basic Profile 1.0 and SOAP 1.1 over HTTP are supported. Be aware that SOAP faults throw an exception on the client but do not specify information about the fault that occurred.

Syndication (RSS) Feed Service

Syndication is most often used to where a subscriber subscribes to syndicated feed content such as a podcast. This scenario shows how to bring syndicated content titles into a Silverlight client.

Figure 19: Syndication Feed Service

A simple RSS 2.0 syndication feed is created in the RssProducer Servlet. The Silverlight control reads the feed into and XmlReader and renders the results in three lines of code:

XmlReader r = XmlReader.Create(e.Result);

Construct the SyndicationFeed using the XmlReader (containing the RSS feed)

SyndicationFeed feed = SyndicationFeed.Load(r);

Bind the collection of RSS results to an ItemsControl (see Page.xaml)

_itemTitles.ItemsSource = feed.Items;

For a good Silverlight Quick Start overview of syndication refer to Accessing Syndication Feeds with Silverlight

Summary

The pdf for the TS-6373 JavaOne session is here and the updated “Silverlight 2 beta 2” source code will be made available in a future blog post.

In conclusion, there are a number of supported Silverlight-Java interoperability scenarios that are useful to consider. The most powerful of these involve the creation of a Silverlight application using Visual Studio .NET. The SOAP web service scenario represents the most useful scenario for multi-tier ‘hybrid’ solution scenarios that have a strong investment in a Java middle tier, but wish to leverage the great features of Silverlight as a rich, cross-browser, cross-platform user interface

Resources:

Community Site: http://Silverlight.net

Main Product Site: http://www.microsoft.com/Silverlight

MSDN Center: http://msdn.microsoft.com/Silverlight

Online Forums: http://Silverlight.net/forums

Online SDK: http://msdn2.microsoft.com/bb188266.aspx

Tim Sneath’s blog: http://blogs.msdn.com/tims

Mike Harsh’s blog: http://blogs.msdn.com/mharsh

Joe Stegman’s blog: http://blogs.msdn.com/jstegman

Laurence Moroney’s blog: http://blogs.msdn.com/webnext

Tim Heur’s blog: http://timheuer.com/blog/Default.aspx

Lessons learned migrating UNIX-Favored programming idioms to Windows

2008-06-14T00:13:00Z

Grzegorz shared one of his findings from an architecture review that he did some time ago for a global ISV for a product with components that originated on UNIX. You can read it on his blog here.

How To: ClickOnce deployment for unmanaged app with COM component in managed assembly

2008-06-14T00:10:00Z

Grzegorz, one of Senior Solutions Architects on our team, recently worked with a global ISV in Europe on re-architecting some of their products from competitive platforms to Microsoft platform and he plans to write some posts on solutions architecture related to this engagement. But first, he posted a sample that he developed for this ISV that demonstrates ClickOnce deployment of Delphi-based app with COM component implemented in managed assembly without using GAC or Registry, and without requiring admin rights. You can read about it on his blog here and about some gotchas here.

Biztalk Reference Architecture: Composite Application Engine

2008-06-13T18:50:00Z

Hello, I’m Charles (Charley) Fichter , a Snr. Solutions Architect on the GISV Architecture team. Thanks for dropping by our team blog.

We’ve seen an uptick in interest for Microsoft Biztalk Server in recent months. This may be due to the new Microsoft Biztalk Server 2006 R2 release last November, 07 and many of the feature enhancements, strong adoption from our medium and enterprise customer base driving demand for Biztalk-based solutions, as well as the new embedded Biztalk offerings on the ISV royalty licensing program (please contact your Microsoft account rep for more information). In most scenarios, the ISV is utilizing Biztalk for its most common implementation as a central integration server (commonly referred to as ‘EAI’ – Enterprise Application Integration), providing application integration via orchestrations and data transformations. There is one scenario that is very different, however, where Biztalk is used as a centralized data communication hub for disparate client applications, in a way more like a composite-application engine. This approach is worthy of examining deeper, as it solves many common problems ISVs run into when trying to unify communication between a broad suite of applications.

This ‘composite application’ scenario has many challenges. In one specific case, an ISV acquired a market-leader client application with its own isolated, client-side data store that needed to be folded into an existing legacy composite application suite with its own local data store. In the past, manual data integration using export data functions from both the new application and the composite application was how end customers merged vital business data. Several significant problems arose with this ‘sneaker-net’ approach, however. Volatility of the data was at risk as usually the data extracts were passed around via DVD burns from client laptops. Additionally, the different client applications had slightly differing business rules and calculation engines, requiring complex transformations to import the data properly. Worse yet, once the data was imported into either system, there was no effective way to know where specific business processes were on a timeline – in other words, they couldn’t accurately make decisions on the data for the next course of action. The result was an overly complex and frail data communication strategy that was largely dependent upon lengthy phone calls back and forth between data users, explaining the data and what the next course of action should be from result sets.

The over-arching goal was to bring all the applications into a ‘suite’, where consistent look and feel, behavior, and a centralized data store was achieved, while minimizing the amount of re-write needed in the client applications. In addition, they realized they needed some form of integration engine that would guarantee and coordinate data messages between the applications in a specific order, alert supervisory monitors when critical events occurred, notify all consuming applications at what stage each business process was at, and what the next steps would be. They also had diverse message formats to synchronize, as some data was exportable in relational format, but some production system data came in XML documents or web service calls. Taking all of these considerations into account, they quickly saw the value of Biztalk server in its ability to handle all of these requirements. Each application could originate a business operation, and other applications in the suite would be notified (or the subscribing applications check a central repository for any new business operations they care about, either by user action in the client or automated via time checks) and could enlist as a subscriber to the Biztalk orchestration. Thereby each application would receive the identical update of status, insuring consistency, and further, supervisory consoles, through use of Biztalk Server’s Business Activity Monitor, allow interrogation of operation status and provide the ability to initiate action to alter the process if necessary.

The illustration below shows a logical representation of workflow initiation and subscribe/publish behavior to consuming applications and supervisory monitoring:

(click here for a larger version of the image)

Choosing a communication strategy to hook all of the applications into the central Biztalk hub was solved by standardizing on Windows Communication Foundation (WCF) as the framework for service-boundary communication. Because an effort was needed to decouple the acquisition application and the composite applications from their stand-alone data sources, service layer boundaries were identified and data access components were modified to address WCF endpoints – both within and across machine boundaries for synchronous or asynchronous calls utilizing a custom WCF channel factory and a WCF channel listener. Using Biztalk 2006 R2 and the new WCF Adapters for Biztalk provided the opportunity to unify message patterns across applications and machine boundaries in-proc. In previous versions of Biztalk Server, the web-service implementation utilized an IIS host and ran out of process with the Biztalk server process. With the new adapter model in BTS2006R2 and the WCF Adapter, the exposed WCF adapter (receive port) runs in process with the Biztalk Server process, and avoids the overhead of excessive IIS service resource demands and marshalling across process boundaries. This provides obvious benefits for scaling when you consider the frequency of these operations with load. In addition, Biztalk server allows logical grouping of machine installations, so that end customers can simply deploy additional machines into a Biztalk group, and load balancing, guaranteed messaging and fault tolerance is automatically inherent and managed by the Biztalk group. If one machine node fails, any other machine can pick up an orchestration process directly where the last execution was handled and continue the processing. The infrastructure required by ISVs to deliver this quality of service within their own application suite is onerous, and combined with Biztalk’s ability to handle diverse message formats easily and the available pre-built adapters packs provided out-of-box and available through 3^rd party partners makes Biztalk an easy adoption choice.

Adopting Biztalk Server as a central hub in this way did pose a challenge for a small portion of the ISV customer base that either 1) only wanted client-only solutions, or 2) opposed Biztalk server because the customer already had some other integration product or different strategy. The ISV also was concerned about the sometimes complex configuration and deployment challenges that accompany a Biztalk server deployment. The ISV decided to leverage Microsoft’s new Hyper-V virtualization engine to virtualize the entire server-based Biztalk deployment. A challenge here was end customer requirements varied greatly for production support systems (ie; different anti-virus software, machine configuration requirements for security, etc). To solve this, the ISV will be providing pre-built answer files and full scripts for Windows Server 2008 parent Hyper-V machine build (when Hyper-V ships), Windows Server 2003 host VM (Biztalk Server does not support Win2008 until R3 release, http://blogs.msdn.com/stevemar/archive/2008/04/23/biztalk-server-platform-updates.aspx ) SQL Server, and Biztalk Server installation and deployment.

The ISV also needed to solve a requirement for providing offline storage for the entire suite, while preserving access to vital calculation engine rules. They achieved this by utilizing the Microsoft SQL Server 2005 Express Edition for storing data locally on each users workstation/laptop, and then designed a synchronization strategy using the Microsoft Sync Framework for ADO.NET.

Freel free post any questions/comments. Thanks for dropping in!

Interesting Exception with CRM 4.0 Custom Security Roles and Reporting

2008-06-03T00:33:00Z

Trent worked through an interesting issue with CRM 4.0 reporting throwing a "CRM_CalendarType parameter is missing a value" exception for users of a custom role. You can find more details on his BLOG entry here (http://www.trentswanson.com/post/2008/03/CRM-40-CRM_CalendarType-parameter-is-missing-a-value.aspx). Aparantly, reporting in CRM 4.0 works against iltered views that are security trimmed based on the priveleges and roles assinged to a CRM user. Some of the reports select user settings to be used in subsequent queries, such as "CRM_CalendarType" in this case the user does not have access to settings and the value is then missing.

Software + Services - Opportunities and Challenges for Global ISVs

2008-06-02T22:32:00Z

A number of the GISVs we work with have been listening to the ‘Software + Services (S+S)’ strategy that Microsoft has been spearheading, and have themselves embarked on creating hosted versions of their solutions. I have been assisting some of these GISVs on their S+S efforts, and I thought it would be useful to share some key ISV-specific learning and resources that may be helpful to you in your endeavors.

Today, most of our larger GISV partners produce products targeted to the enterprise space – that is, they are feature rich, highly customizable, and installed and deployed on-premise (e.g. within customer environments). However, there are various customer segments that are very interested in those products, but will not adopt a large, on-premise solution due to a variety of reasons - infrastructure cost and complexity, large long term licensing costs, and significant implementation times – to name just a few.

Microsoft has been at the forefront of advancing the notion of hosted or ‘cloud-based’ solutions with its ‘Software + Services (S+S)’ approach. This approach embodies a confluence of multiple industry phenomena including Software as a Service (SaaS), Service-Oriented Architecture (SOA), and Web 2.0. While different vendors are evolving their offerings from different starting points, the entire industry is converging on the S+S approach.

ISV Challenges with S+S

GISVs that are adopting an S+S approach are usually faced with an interesting dichotomy. On one hand, their solutions are typically the most capable, feature-rich software products available (because ‘global’ ISVs usually target medium to large enterprises), which would suggest they have a lot of great IP that many smaller enterprises would love, and could be leveraged into an S+S offering. But the dichotomy is that, because of this traditional customer base, the entire product architecture and deployment approach is usually fundamentally geared toward an on-premise model. As I’ll describe below, there are some key differences between on-premise and S+S solutions that GISVs need to be aware of when contemplating a move to S+S.

Key Differences between On-Premise and S+S Hosted Solutions

There are some key solution aspects which are markedly different between on-premise and S+S solution approaches. These are worth highlighting, in order to help you understand what may be involved in moving to an S+S offering.

Multi-Tenancy

S+S solutions are fundamentally based on the notion of supporting multiple customers (tenants) within a shared set of resources (e.g. multiple customers running on one hosted web server, database, code version, etc). On-premise solutions, however, have (by definition) one ‘tenant’, and typically allow significant customized code, DB schema, UI elements, etc. Support for multi-tenancy is typically one of the most significant aspects that must be considered and supported in GISV solutions moving to S+S. There are a number of different approaches to multi-tenancy at the data tier, application tier, etc.

Fundamentally, there are two key dimensions to multi-tenancy:

· Approach. Multi-tenancy can be fundamentally implemented in two ways:

o Within. Implementation within the solution can be changed to be made multi-tenant aware (e.g. DB tables may have a ‘tenant’ column added, or middle tier services may be modified to load tenant-specific meta-data to allow for tenant-specific processing). The advantage to this approach is efficiency and reuse of implementation and resources – the same code, DB tables, UI components, etc. are shared across all tenants. One disadvantage is that it may take considerable modifications to applications, DBs, etc. to incorporate multi-tenancy. Additionally, per-tenant customization approaches usually need to be changed. Code-based customization needs to be severely limited (shared code base across tenants), and per-tenant customization usually needs to be modified to be more meta-data (configuration) driven.

o Around. Implementation is isolated or ‘wrapped’ to be made multi-tenant supportive (e.g. virtualization used to create per-tenant images). The advantage to this approach is that it doesn’t require modification of existing single-tenant code – the multi-tenancy is managed by ‘wrapping’ it inside an isolation boundary (the virtualization image). The disadvantages to this approach are that virtualization may not provide the best performance for high # of concurrent tenants/users/processes, and virtualization introduces additional technologies around creation of images, deployment, tooling, monitoring, etc. The other thing to mention is that, while virtualization would allow for code-level customizations on a per-tenant basis, implementing and managing N-versions of custom applications in this case could lead to a maintenance nightmare… so it’s still ultimately better to try and reduce code-level customization and instead move to more a configuration/meta-data based approach.

· Tier. Different tiers can take different multi-tenancy approaches. For instance, the middle ‘business process’ tier can be multi-tenant aware (as above), while the data tier might have separate DB’s for each tenant (and not require any adjustment of DB table schemas).

Scale

For on-premise solutions, application performance and scaling is a function of the customers own hardware, resources, etc, and it impacts them only if/when issues arise. Dedicated hardware, DB servers, etc are usually the norm for enterprise solutions. Also, the # of concurrent users and processing is usually considerably less than in a hosted solution that is being accessed/used by 100’s or 1000’s of tenants and their users.

In an S+S scenario, there can be many tenants (100’s, 1000’s) sharing machine resources, which may take the GISV on-premise solution into a whole new realm of net new scale and perf considerations. Thus, S+S solutions have to be typically instrumented and monitored/managed better (to provide scale and perf details per tenant) and support per-tenant changes, throttling, etc).

Hosting

GISVs that today produce on-premise solutions are usually in brand new territory regarding hosting, and often initially suggest that they will ‘self host’. I guess this seems easier in a way (not having to select, and pay a hosting partner)… but, hosting is an entire discipline in itself, requiring specific skill sets, tooling, and of course, infrastructure to host on. There is a great white paper on ISVs and hosting – “ISVs are from Mars and Hosters are from Venus” which outlines SaaS-specific hosting, and ISV-specific considerations.

Configuration and Customization

On-premise software can usually be customized extensively, including modifying or extending source code, database schemas, user interface components, etc. In a multi-tenant hosting situation, all tenants usually run on the same implementation (code base), thus limiting the kinds of customization possible. In the move to an S+S offering, a GISV usually needs to modify their solution to reduce/eliminate code-level customizations, and instead support this via meta-data or configuration. ‘Customization’ by a particular tenant then means modifying or extending their metadata (e.g. extended DB schema, new workflows in XAML, etc). Of course this usually means severely constraining customization capabilities (there are some requirements which will not be supported by the configurability options)

These are just a few of the key areas to consider. There are of course lots of other considerations, and details to follow in future posts. But this is probably a good start.

Microsoft provides some great technical resources to assist in understanding about these aspects in detail:

· ‘Architecture Strategies for Catching the Long Tail’ – a core white paper on many aspects of S+S architecture and design

· MSDN Software + Services Architecture center – this location has a lot of great content/guidance on architecting and building S+S solutions.

· ‘LitwareHR’ - Microsoft architects in the Platform Adoption Team have produced a great sample S+S application –with lots of great content/guidance around it.

· Multi-tenant Data Architecture – a great white paper on different approaches to multi-tenancy at the data tier, and how those approaches affect performance and scalablility

· Key S+S bloggers:

o Gianpaolo Carraro – Director, Platform Adoption Team

o Eugenio Pace – Senior Architect, Platform Adoption Team

Welcome to the GISV Architecture Team blog!

2008-05-29T03:36:00Z

Welcome to the blog of the Global ISV Architecture Team. We are a team of Solutions Architects within the Developer and Platform Evangelism (DPE) team that provide architecture/design assistance to the largest of our Global Independent Software Vendor (GISV) partners. We do deep dive architecture design and review engagements with GISVs to help them to define their solution architecture and design. We work with them through their unique and often complex solution goals, requirements, and constraints, to advise on applicable Microsoft or partner technology choices, make recommendations, and collaboratively define the architecture and design of GISV solutions.

This blog is intended to share with you some of the interesting learning and results from our engagements, distilled into a form that (hopefully) you can apply in your own situations. Since our focus is on ‘Solutions’ (and not just specific technologies), much of our work (and contributions here) rest on how various Microsoft technologies and products work together, communicate, etc. within an overall solution. Additionally, since our space is large global ISVs, we often advise/assist on heterogeneous solutions (e.g. Java and .NET, portal integration, security interoperability, etc) so those are areas we cover as well.

We hope that this blog will provide you with some useful info, guidance, examples, etc. for your own solutions work.

Regards, the GISV Architecture Team