May 23, 2007

From OpenLiberty.org Wiki

Jump to: navigation, search

Contents

Open Liberty

Face-to-Face meeting – Georgetown 23-May-07

Attendees

  1. Asa Hardcastle – Zenn
  2. Curtis Jones – Zenn
  3. Conor Cahill – Intel
  4. George Fletcher – AOL
  5. Chad La Joie – Internet2

Minutes

Open-ID

  1. Asa: Should we demonstrate OpenID interoperability?
  2. George: Use-case drives it – who uses OpenID? People who just want to get on without true authentication, etc. We can show technical reasons for doing it, but what’s the value?
  3. NOTE: Amazon – S3-based back-end – “Jungle Monkey”?
  4. George: Paul had started doc discussing translation OpenID <-> ID-WSF
  5. Conor: We should focus initially on bootstrapping off of SAML – forget about OpenID for now
  6. Asa: I want to find people to help build this – OpenID has a community
  7. George: Various historical discussions have occurred about how to roll in/embrace OpenID in various ways
  8. Asa & George: There’s no openly available services (People Service) or otherwise for developers to bounce up against
  9. Conor: Once we get a working WSC toolkit – deals w/ID-WSF framework layer – we work on a WSP layer. A toolkit to provide a WSP
  10. Conor: His toolkit can provide a WSP (Java)

Steps

  1. All: It’s a chicken & egg situation (WSP/WSC) we need both the chicken and the egg to really get rolling
  2. Curtis: If we could inspire those companies that have closed implementations to open up and donate implementations to the community, it would help
  3. Sampo’s is closest to doing this

XML Tooling

  1. sa: This is the basis for all our development
  2. Asa: There’s this marshalling/unmarshalling method in place – I can see how it could be implemented in different ways, but I’m curious about what’s driving your prefered approach
  3. Conor: (at white-board – replicated in Graffle by Asa)
  4. George: You will likely need to manage multiple contexts per user – one user context, and then one service context for each service they’re working with
  5. Asa: So far, the XML tooling emphasizes the idea of fully integrating objects into the XML tooling. You register that things of type “person” are handled by these mechanisms.
  6. Asa: My understanding of desired approach (e.g., EPR), you have many sub-elements. Now, for each element, you’d have to build an objects and a set of handlers. Is this correct?
  7. Chad: Not necessarily. The marshallers/unmarshallars “chain” – you could create one of each that takes care of everything. Or you could have a parent that delegates to children as necessary.
  8. George: We need to add to our list of things to do for developers, the list of marshallers/unmarshallers for everything.
  9. Chad: For our code, we go with maximum delegation (granularity) = lots and lots of classes.
  10. Group: It’s clear that this is tedious & burdensome.
  11. Group: It’s not clear that this can be easily automated – but is doable by a semi-intelligent programmer
  12. George: We should first implement and prove that this approach works, then find a way to wrap/automate the tedium
  13. Conor: I’ve done it both ways – one direction, I go straight to the DOM (no marshalling/unmarshalling) and in the other direction, I use streams w/marshalling/unmarshalling
  14. Conor: Different DOM/XML-processor tools may not play well together if we wrap this stuff
  15. Chad: We’re not doing any of this for performance or speed – not a goal. We were to make this easy to use by our developers.
  16. Asa: If we were to wrap the EPR -- kept it primarily DOM-based, we could make a big class that does it all, but extracts the difficult bits (SAML). If we were to do this, is it more likely that we’d produce a “non-normal” document?
  17. Chad: Signing is in the DOM – so theoretically, no.
  18. Conor: Signing is painful
  19. Chad: Encryption is even more painful
  20. George: For user, for every new WSP, there’s a WSC-interface piece required. Should creating that be the responsibility of the WSP developer?

Conor’s walk-through

  1. Uses Fedora Linux under Windows (VMWare) CLIENT LEVEL – C++ (C writtin in C++)
  2. Make with no args shows options
  3. Applibs contains “application-level” libraries – all about WSCs accessing a service
  4. Lib contains lower-level ID-WSF-level libraries
  5. Unusual exception:
  6. LibDisco -> used by WSPs to manage EPRs
  7. LibAuth -> contains discovery component used by WSC
  8. When one WSP needs to talk to another WSP, it is acting as a WSC
  9. Most (vast majority) users will have one instance of auth and one discovery service
  10. “IDP discovery”
  11. Asa: I like the idea of making each ID-WSF step distinct at the WSC library level – and then providing a higher-level library interface that bundles them together to make it easy for developers SERVICE LEVEL – JAVA
  12. Uses PostgreSQL for database backend stuff – but doesn’t use any PostGreSQL-specific stuf
  13. In the liberty folder, he has a complete set of the Liberty spec reference files
  14. Axis requirs WSDLs – they are the easiest way to get the code automatically generated
  15. ID-WSF directory contains the ID-WSF level classe
  16. Build-place where all code is compiled
  17. Dist – where jar files go
  18. Source – modified source code (that conor wrote) goes
  19. Database access logic is separated – app-level code doesn’t call db stuff directly
  20. Typically only replaces the implementation class
  21. Stores modified source in different directory
  22. Ant then over-writes code generated from WSDL with modified code
  23. This model has risk of: modifying WSDL (which changes generated code) but failing to also apply changes (manually) to modified code – only to have the “old” modified code overwrite the “new” generated code – stepping on changes and creating problems
  24. Conor: disclaimer: “chose to write this in Java because I didn’t know Java – so it’s not great Java”

Chad’s XML-tooling walk-through

  1. a. three to focus on:
    1. opensaml2
    2. openws
    3. xmltooling
  2. XML tooling stuff is done, the client stuff (HTTPS) is not (yet
  3. Marshallers: data objects -> XML
  4. Unmarshallers: XML -> data objects
  5. XML objects are simply data stores – logic is above this level
  6. There is a lot of code in xmltooling to deal with moving xml from one place to another and normalizing the namespaces appropriately
  7. Asa: What instantiation approach would you recommend
  8. Chad: In Shib 2, we’re using “spring”
  9. NOTE: Scott Cantor is through-and-through a C developer
  10. Chad: static loading can cause problems in containers (e.g., Axis
  11. Asa: That says that we’re going to want to do this differently – because containers will be used a lo
  12. Conor: Not sure about that – might well be some plain-jane developers
  13. George: They’ll still be calling from some containe
  14. “Velocity” = a templating mechanism
  15. Conor: Need to be able to support simple string sending
Retrieved from "http://openliberty.org/wiki/index.php/May_23%2C_2007"
Personal tools