Future Evolution of Portal Platform to Jupiter and Beyond

There is no constant in the technology business except for change, and the Microsoft portal platform is no exception. While 2003 marked a turning point for .NET with the shipment of a new server operating system and the completion of the first generation of .NET server products, the evolution is never-ending .

A Microsoft project code-named Jupiter is reportedly planned to integrate several of the popular server offerings more completely than the former "glue code" that is available for download under such offerings as the Microsoft Solution for Internet Business (MSIB). The purpose of Jupiter is to stress the integration of portal elements from the perspective of developers and information workers through tighter integration with Visual Studio .NET and Office, integrated security, deployment, management and monitoring across the technologies, and XML web services support.

Paul Flessner, senior vice president of Microsoft .NET Enterprise Servers, and David Kiker, general manager of E-Business Servers, presented Jupiter at the October 2002 Microsoft Exchange Conference. They defined the design goals of Jupiter as:

• Business process management. Portal business rules cut across traditional Microsoft product lines. Jupiter will make it easier to follow improved business processes rather than tailoring processes to meet product constraints.

• Integration. Developers can be more productive in a single integrated development environment (IDE) than in multiple environments and languages, one for each product or service. Jupiter tools and components will be integrated with one another, primarily through a common and seamless development, deployment, and management experience. Visual Studio .NET will be the common development environment, and server management will take advantage of common management consoles.

• Interoperability. Microsoft does not embrace the "rip-and-replace" philosophy of scrapping existing hardware and software investments to make way for a shiny new portal. Instead, the Jupiter vision aims to integrate existing CRM, ERP, and other line-of-business applications that represent serious investments through XML web services and application and technology adapters.

• Componentization. A portal requires a wide range of services, but not every organization needs the same services nor plans to deploy them on day one of the project. Offerings must be flexible, allowing architects to choose a tailored combination of components and incrementally add functionality as the portal evolves. Jupiter will deliver many off-the-shelf components, and XML web services standards will allow enterprises to add the key pieces from other vendors or custom-build them for a complete e-business solution.

An overarching business goal of Jupiter for Microsoft is to counter offerings from vendors such as IBM and Broadvision. Microsoft has not announced the specifics of Jupiter, but press accounts have cited the offering to contain Commerce Server, Content Management Server, Host Integration Server, and BizTalk. ^[2] The data repository for the portal is likely to change as the next version of SQL Server, codenamed Yukon, ships in 2004. Microsoft has announced that this product will not only replace SQL Server 2000 but will also be the store for future versions of Exchange Server and SharePoint Portal Server.

^[2] "Microsoft Details Vision for the Connected Business and Unveils 'Jupiter,'" October 8, 2002, at www.microsoft.com/presspass/press/2002/Oct02/10-08JupiterPR.asp.

The current portal platform does not require Active Directory, with the exception of Exchange 2000, which itself is optional for a portal deployment. This approach has the advantage of allowing those who have not taken the Active Directory plunge to embrace the .NET platform, but it also forsakes many of the potential benefits from tighter integration with Active Directory.

A likely direction for .NET portals is tighter integration with Active Directory. In particular, it would make sense for the portal to use Active Directory to store the profile used for personalization. This is the approach used by the Corechange product acquired by Open Text in February 2003.

Portal standards will continue to evolve in the next two years and reach a maturity that will make them more functional and less risky. The growth of interest in web services, and support for this standard from nearly all the major IT vendors, creates a tremendous opportunity for standards that cross both the Java and .NET worlds . Will Microsoft join the Web Services for Remote Portals (WSRP) standard? Will .NET be successfully ported to Linux? Either of these would be a major advance in interoperability.