Skip to main content
Jump to: navigation, search

Difference between revisions of "Higgins/Solutions"

(RPPS Web Application)
(RPPS Web Application)
Line 156: Line 156:
 
|WS endpoint
 
|WS endpoint
 
|[mailto:sergey@parityinc.net SergeiY]
 
|[mailto:sergey@parityinc.net SergeiY]
|-
+
|}
 +
.
 +
===RSS-SSE RP Test Application===
 +
{| class="wikitable" style="text-align:left; border="1" cellpadding="5" cellspacing="0"
 
|-style="background:#d6dee9; color:black"
 
|-style="background:#d6dee9; color:black"
 +
! width="30%" border="1" align="left" valign="top" | Deployment Scenario
 +
! width="10%" border="1" align="left" valign="top" | OS
 +
! width="10%" border="1" align="left" valign="top" | Runtime
 +
! width="15%" border="1" align="left" valign="top" | Assemble & Deploy
 +
! width="10%" border="1" align="left" valign="top" | Binding
 +
! width="10%" border="1" align="left" valign="top" | Open
 +
! width="10%" border="1" align="left" valign="top" | URL
 +
! width="10%" border="1" align="left" valign="top" | Owner
 +
|-
 
|[[RSS-SSE RP Test Application]] (WAR)  
 
|[[RSS-SSE RP Test Application]] (WAR)  
 
|Fedora 5
 
|Fedora 5

Revision as of 03:17, 10 February 2007

Overview

A Deployment Scenario is a specific combination of Components that, when assembled and deployed result in an application or service that is identifiable to an end-user as a "whole" app or service. This page is intended to explain how to assemble building block Components into running apps and services. The indended audience is technical, but more about assembling, building and deploying, as opposed to "developing."

Some of the Deployment Scenarios are web services or webapps that have been deployed on Eclipse servers and can be used for testing and and development-related purposes. Examples would include a CardSpace-compatible IdP service (what Microsoft would call a "Managed Card Provider" (not to be confused with our use of the term provider)), or a MediaWiki app that supports OpenID sign-in, etc.

Each Deployment Scenario should be desribed in its own section on this page, and should include a table with rows that describe the Components involved. This table should include build scripts and other 3rd party libraries.

Deployment Scenarios

CardSpace-interoperable Identity Provider/STS

Deployment Scenario OS Runtime Assemble & Deploy Binding Open URL Owner
CardSpace-interoperable IdP/STS n/a n/a n/a n/a TBD Wag (IdP)
Woof (RP)
DSanders
Token Service Open SUSE 10.2 JVM 5.0, Tomcat X.X here WS-Trust, WS-Transfer open n/a MikeM
Identity Attribute Service Open SUSE 10.2 JVM 5.0 here Java Interfaces open n/a JimS
LDAP Context Provider Open SUSE 10.2 JVM 5.0 viewsvn, ide, cli, downloads Java Interfaces n/a n/a TomD
Open LDAP Server
(or other LDAP server)
Open SUSE 10.2 OS Open LDAP downloads LDAP n/a n/a n/a

.

Paul's Sandbox (alternate table design for discussion purposes)

Deployment Scenario OS Runtime Binding Open URL Owner
CardSpace-interoperable IdP/STS Open SUSE 10.2 JVM 5.0
Tomcat 5.0
WS-Trust
WS-Transfer
TBD Wag (IdP) DSanders

1) In this proposal a deployment scenario consists of one row per machine. Each row describes ONE computer's configuration (OS, runtime, link URL (e.g. WAG)). If a second computer is required, then a second row (e.g. for WOOF) is added.

2) We agree to a convention that CardSpace-interoperable IdP/STS contains these two sections:

  • Overview (as you already have, except only for ONE machine (other machines would be on other rows))
  • Assembly and Build instructions (new)

The Assembly and Build instructions section would start off with a bulleted list of components and other external stuff that you'll need. We can include links to the various required rows on the Components page tables as we've started doing.

Notice that "Assembly & Build" has been removed as a Column from the table.

The rows I've deleted (and moved into the above wiki page) were almost entirely redundant. .

Identity Agent (in-browser selector, hosted IdA)

Identity Agent (rich client selector, hosted IdA)

  • Requires the user to install the Higgins Browser Extension (HBX) and the ISS Client UI rich client card selector. ISS Client UI relies on a hosted Identity Agent service

Identity Agent (rich client selector, local IdA)

  • Requires the user to install the Higgins Browser Extension (HBX) and the ISS Client UI rich client card selector. ISS Client UI relies on a local Identity Agent service.

I-Card Manager Enterprise Application

Deployment Scenario OS Runtime Assemble & Deploy Binding Open URL Owner
I-Card Manager Enterprise Application (EAR) Fedora 5 JVM 5.0, SJSAS 9.0 viewcvs, ide, cli WS open site SergeiY

.

RPPS Web Application

Deployment Scenario OS Runtime Assemble & Deploy Binding Open URL Owner
RPPS Web Application (WAR) Fedora 5 JVM 5.0, Tomcat 5.x viewcvs, ide, cli WS, RSS-SSE open WS endpoint SergeiY

.

RSS-SSE RP Test Application

Deployment Scenario OS Runtime Assemble & Deploy Binding Open URL Owner
RSS-SSE RP Test Application (WAR) Fedora 5 JVM 5.0, Tomcat 5.x viewcvs, ide, cli HTTP, RSS-SSE site SergeiY

.

Nightly Builds

Though certainly not a "deployment" in the usual sense, the Higgins project automatically builds some of the Components every night.

Deployment Scenario OS Runtime Assemble & Deploy Binding Open URL Owner
Nightly Component Builds SUSE Ant psf n/a TBD build.eclipse.org EvgeniyV

.

Conventions Used

The tables on this wiki page have the following column structure:

  1. Deployment Scenario - link to wiki page describing deployment scenario
  2. OS - OS that this deployment either (a) runs on (see URL column) or (b) has been tested on. Put in parens the OS number if more than OS instance is involved
  3. Runtime - Runtime environment for component (e.g. JVM & version, Tomcat & version, etc.)
  4. Assemble & Deploy
    • Links to documentation
  5. Binding - how will externally consumed services of deployment scenario be consumed
  6. Open - open enhancements and bugs (Bugzilla) for this deployment scenario (Note: none are currently defined)
  7. URL - endpoint that hosts a test service (hosted by Eclipse Foundation)
  8. Owner - person with overall responsibility for this deployment scenario (not individual components)

See Also

Back to the top