Re: [higgins-dev] H3 deployment configuration issues

[Michael McIntosh <mikemci@xxxxxxxxxx>]

higgins-dev-bounces@xxxxxxxxxxx wrote on 05/22/2007 08:53:58 PM:

> Two Higgins identity agents (as well as the Higgins IdP/STS, and a 
Higgins
> RP test site) will be involved in the Catalyst interop demo (approx 
25-27 of
> June). One of the agents uses the H3 configuration. And it has problems.
> 
> To help discuss the problems, I've created new & improved documentation 
here
> [1] for both agents. Notice the new deployment configuration summary 
table
> near the top. Please review the details of described [3](H3=java) and
> [4](H4=native). I have also updated the Architecture page [2] to split 
the
> RPPS into two separate components (this reflects reality). I have also
> annotated some interconnections with the H1, H2, etc. deployment
> configurations to which they belong. 
> 
> Andy and others at Novell have been focusing on the H4 configuration,
> whereas Mike and Abhi of IBM, and Valery, Maxim and SergeyY of Parity
> Ukraine, have been focusing on H3. 
> 
> H3 and H4 differ from each other in two ways. First, H3 is interpreted
> (java) whereas H4 runs native code. Second, H4 embeds the UI (ISS Client 
UI)
> within the native executable, whereas H3 relies on the UI integrated 
within
> HBX itself. 

I think there are potentially/probably more points of diferentiation. 
Since the "H3" version is checked into CVS it is easy to see where it does 
and does not diverge from the Higgins architecture and whether or not it 
supports the interfaces we've been discussing within the project.

> I have drawn here [2] a line from HBX directly to the RPPS Core. This is 
the
> intent, and the subject of this email, but NOT how it works today. Today 
HBX
> makes SOAP calls to the RPPS Webapp (much like H1). 

I am not sure I understand the differentiation. The SOAP calls are always 
local RPC, not remote.
Is it your intention to use the local vs. remote designation to mean 
in-process vs. cross-process?
If so, then the H2/H4 line from HBX to ISS Client UI should also be red.

Having a single, consistent UI experience is important, whether invoked 
from a browser or from a rich client. Therefore, putting the UI into 
common code (not the browser) makes the most sense. Therefore, there needs 
to be some language nuetral IPC mechanism that allows us to invoke the 
ISS/RPPS from a client. 

> As I understand it, there are two problems with HBX's use of SOAP to 
connect
> to RPPS Webapp (vs. some alternative way to connect to RPPS Core): 
> 
> 1) The size of the code. The presumption is that if we find some other 
way
> for HBX to talk to RPPS that the size would be reduced because several
> SOAP/XML-related libraries could be eliminated.

Considering the small SOAP subset used, no SOAP library should be 
required. Seems like the service interface is (or should be) simple enough 
to construct (marshall/unmarshall) messages from either XML or strings.

> 2) The installation and run-time complexity: A separate java process 
must be
> installed and be running at all times.

This is no different from CardSpace (look for infocard.exe in the Task 
Manager). When CardSpace is invoked, if the infocard.exe is not running, 
it gets started. Once started it stays running (unless you kill it). The 
first time CardSpace is invoked it takes a little longer becuase the 
process is starting.

I cannot say how this is different from H4 since I don't have it.

> Soo.....We need to find and evaluate architectural alternatives to 
address
> these issues. Anyone have experience with javascript-to-java bridges?
> Should/could the Higgins code run as a java applet!? Can we just address 
the
> installation and run-time issues with fancy installers and live with the 
OS
> background process requirement? 
> 
> Anyone with ideas about how to solve these issues, please join the 
#higgins
> IRC channel tomorrow from 10-12am ET (9-11am CT). 
> 
> -Paul
> 
> [1] http://wiki.eclipse.org/index.php/Deployments
> [2] http://wiki.eclipse.org/index.php/Architecture 
> [2]
> 
http://wiki.eclipse.org/index.php/Deployments#H3_Identity_Agent_.28100.25_lo
> cal:_HBX_launches_java_application_.28JVM_required.29.29 
> [3]
> 
http://wiki.eclipse.org/index.php/Deployments#H4_Identity_Agent_.28100.25_lo
> cal:_HBX_launches_native_code.29 
> 
> PS: the H4 configuration Novell uses doesn't have these issues because 
it
> can simply have HBX (or equiv) launch an executable. This approach works 
for
> H4 because...
> - there is effectively only one method "getDI" (aka "getToken") that 
needs
> to be supported. Thus all of Higgins can be wrapped up as a single
> executable with a single entry point ("main()") and command line 
arguments.
> This works because the UI is contained in the executable NOT in the 
browser
> extension.
> - Higgins running in native code is fast enough that it can be launched
> every time it is needed without appearing sluggish.
> 
> PPS: In the short term (for H4) we can use the perpetual motion add-on 
to
> launch the executable, and in the long term we'll include this "launch"
> functionality within HBX
> 
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev