Mar 22, 2007

From OpenLiberty.org Wiki

Back to Meeting Minutes←

Present: Conor C, Asa H, Eric T, George F,Curtis J, Chad L.

Updates

Asa: HP installation on hp.openliberty.org is finished. but need to confirm. Had a conf call with Chad and Scott to go through the Open SAML XML tooling. Code is extraordinarily deep. They have an XMLObject that you write extensions to. What SAML layer can do is if saml assertions are being marshalled and unmarshalled the saml can be preserved transparently.

they offered to do a drive through when htey finish their security layers rebuilt. Could do this on a future version of this call.

One thing though, it's a lot of work if you have to roll your own classes. In order to take advantage of all the features you need to extend a lot of base classes. Still need to discuss Java-openws (soap layer).

XML tooling continues to be developed for Shib.

Conor: they have written stuff that sits ontop of xml tooling?

Asa: they are rewriting OpenSAML2 on top of xmltooling and they are redoing the security layers. Should be done by the end of the month. Fully integrated with junit. Gives a lot of confidence. Examples of use on their website.

[Chad joins]

Asa: would Chad be able to give a walkthrough on a future wsf-dev call?

Chad: sure.

Commitment

Asa: Other items: someone asked what the commitment level for coding? Posted discussion on blog. Other thing is that in terms of governance, things are owned by "primary coders".

Asa: as far as stuff being built, Curtis has been hired by Zenn.

Asa: Curtis and Asa are collecting code, compiling, configuring and learning

Session / Context Rehash

Asa: Discussion last week regarding distinction between Session versus Context.

Conor: sso defines single session, but when the client turns around and calls other WSCs there may be multiple sessions.

Asa: So you define a session as a discover followed by multiple invocations

Conor: Multiple actions derived from sso at a SP. you take the disco EPR out of the SSO to discover and invoke services with multiple "conversations" but all related through the initial session.

Asa: had envisioned that the client library would have a session as the overriding context

conor: get sso login info and then use that SSO bootstrap to invoke other contexts. Believe that you have a single context that is bootstrapped from a session at the SP. The only way you can have multiple sessions if you call the invocations at multiple WSPs "sessions".

Asa: Scott's basic point is that the session is something that exists on the server side, and context is a better term for this WSC-WSP interaction. A context is a good name because it keeps track of what's involved

Conor: you'll have 2 kinds of context, All the info managed at the WSC, and all the info managed for multiple WSPs.

Asa: so the "wsc context" --- everything should be serializable,

Conor: you also need a wsp invocation context