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.

image

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.