B2B scenario : Partner Environment

Steve SFARTZ — Thu, 31 Jul 2008 13:10:00 GMT

The B2B scenario corresponds to Enterprise Web Services exposed to a partner through a Rich Client application, traditionnaly built with some dynamic HTML/AJAX technology running on the server side, that have been elected to leverage the Silverlight capabilities (enriched user experience, vector based contents, scaling, rich media…).

As listed in Silverlight scenarios for Rich Internet Applications, the following constraints apply to the Partner Environment scenario :

Infrastructure security is mandatory : it includes a DMZ to protect the Web Server and access to the Web Services and SSL/HTTPS communications to protect the confidential data owned by your enterprise and shared with your partner.
Protocol adaptation is required if the application is interfaced with pre-existing Web Services that cannot be immediatly consumed by Silverlight. This extract work is performed by a mediation layer, materialized in the schema below by the Services Gateway. Moreover, the Services Gateway in the Customer scenario can enforce the alignement of the incoming messages with the entreprise governance policies.
Authentication & authorization is required to secure read and write access to Entreprise Data. Claim based authentication would be the preferred way in this scenario. If you want wish to use Form based authentication, have a look at the B2C scenario.
A cross domain security file is required to access the Services Gateway if not host on the Site of Origin.

We plan to document this scenario by extending the “B2E with mediation” scenario with a Services Gateway (such as Managed Services Engine) and SSL/HTTPS.

Silverlight scenarios for Rich Internet Applications

Steve SFARTZ — Mon, 28 Jul 2008 15:56:00 GMT

From the architecture described in the previous post a cup of Silverlight, a drop of Architecture, you may experience several technical requirements :

Infrastructure Security
- DMZ (if the application is internet facing),
- Secured transport (HTTPS) if private communication has to be enforced (Mandatory in B2B and B2C environments)
Application Security
- Authentication may be Form, Windows or Claim based depending on the consumer (employees, subcontractors, partners or customers)
- Authorization may be role based from various repositories (Active Directory, Claims, SQL Database)
Application Topology
- The consumed Web Services are likely to be hosted on a distinct node in case of re-use or interop scenario.
- In new project development scenario, the Site of Origin may also host the Web Services.
Services Gateway and Protocols Adaptation
- The consumed Web Services may not be directly accessible due to security topology (ie, requires some kind of Gateway, Reverse Proxy)
- In case of Web Services re-use, they are likely to be exposed through protocols and/or formats incompatible with the Silverlight WCF client capabilities (ie, requires some kind of Mediation, Adaptation)

To comply with these Real World variants, we propose to categorize Silverlight Rich Client Applications into scenarios that you 'll may mix to conform to your requirements.

D2D (Developer To Developer) - Development Env

B2E (Business To Employee) - Silverlight App on an Intranet, eventually consuming pre-existing Web Services

B2B (Business to Business) - Silverlight App delivered to partners, consuming pre-existing Web Services with federated security enforcement

B2C (Business to Consumer) - Silverlight App delivered to customers, eventually consuming pre-existing Web Services with form based security enforcement

In future posts, we discuss the architecture and an implementation sample with interoperability in mind.

A Cup of Silverlight, RIA & Interoperability : B2B

B2B scenario : Partner Environment

Silverlight scenarios for Rich Internet Applications