Post on 21-Jan-2016
uPortal and CHEF
Charles Severance (csev@umich.edu)
University of Michigan
http://www.chefproject.org/
What is CHEF?
• Application development framework– Like a portal – Gadgets, flexible,
reconfigurable, personalizable– Like an application – tool set is consistent and
interwoven
• Applications – “Collaborative”– Course Management System – CourseTools– Research Group Collaboration – WorkTools /
NEESGrid
CTNG/NeesGrid Screenshots
Portal Engine:
JetspeedVelocityCHEF
Teamlets:Written in JAVAResponsible for
GUI Operate in the
context of a session.
Rely on services for any persistent
or “cross-user” information.
ServicesPersistent
System-wideMultiple
implementations of services
Configurable as to what
implementation provides what
service
Servlets:Access services outside of the portal engine: AccessServlet
and WebDavServlet
Services A
PI
CHEF Architecture
WebServer:
TomcatTurbine
Non-HTTP Components (i.e. E-Mail)
Similarities
• Hierarchical Presentation / Aggregated Content
• Fine grained authentication/authorization
• Helper Notion
Differences
• Jetspeed framework• Velocity Markup Language at the core• CHEF
– is both an application framework and an application (a set of coordinated tools)
– is not a myUMich portal
• Services notion formalized• uPortal uses CARs – Chef uses modules
(source-bases)
Go Forward
• Jetspeed will be evolving to something based on WSRP and JSR-168
• Want to take advantage of the following uPortal thrusts– Aggregated Content– XML at the core– WSRP and JSR-168 implementations
• Want to add to the uPortal thinking– Notion of Services– Super-duper-channel– CAR – and then Super-CAR
What is a Service
• Long-term lifecycle• One instance
– Must be aware that multiple users can use service– Can use memory resident information
• Pluggable implementations– Memory version– XML implementation– Web services implementation– Database implementation
Service Implementations
Teamlet
Service A
PI “G
eneric”
ServiceCOmponent
PortalEngine
ServiceComponent
ServiceComponent
The API is an Interface which defines how we talk to a “Generic” service – There can be any number of different service implementations which implement the Interface.
Service C
over
Services in Jetspeed / Turbine
Teamlet
Gen
eric AP
I
TurbineService
Component
Turbine ServiceBroker chef.properties
PortalEngine
The chef.properties file associates a particular service implementation with its service API at run-time. The cover uses Turbine to find the service at runtime. The Teamlet has no dependence on Turbine.
Tu
rbin
e Co
ver
Turbine Aware
Desired Goal State
Teamlet
Gen
eric AP
I
GenericService
Component
Xyz ServiceBroker Xyz Config
PortalEngine
Gen
eric Co
ver
XyzAware
Would like to find a standard API to/from a service broker so that we don’t have to develop a cover and service component for each broker.
The Super-Car File
• Standardization for interchange of two types of packaged components– User Interface
• Multiple presentation components
– Service
Service Package
Portal ServiceComponent
<broker> Blah</broker>
User Interface Package
<gui> <wml blah…> <html blah...> <swing blah…> <services-req’d blah…></gui>
User InterfaceComponent
WMLComponent
SwingComponent
HTMLComponent
Assembling a Portal
• A portal will require a standardized hosting environment for both User Interface and Portal Service packages
Standardized Hosting Framework
Service BrokerGUI Framework
Service
UI WML
SwingHTML
UI WML
SwingHTMLUI WML
SwingHTML
Service
Service
Portal At Run Time• The hosting framework provides services to all of the
components – User Interface– Presentation– Service
• The components are connected using standardized APIs as appropriate by the hosting framework
Standardized Hosting Framework
Service Broker
Portal ServiceComponent
GUI Framework
User InterfaceComponent
HTMLComponent
WMLComponent
Presentation and Framework• Because of lack of standards, consensus, and experience in the
space, we cannot standardize on portal and presentation approach at this time– Jetspeed– GridSphere– Java Desktop Applications– JSP– Perl– Command Line Interface
• Each approach has strengths and weaknesses
Standardized Hosting Framework
Service Broker
Portal ServiceComponent
GUI Framework
User InterfaceComponent
PresentationComponent
HTML Framework
Broker
Service
GUI
UIHTML
WML
Future State
• Standardize full scope of hosting framework• Packages usable in multiple environments
SWING Framework
Broker
Service
GUI
UISWING
Service
UI WML
SwingHTML
Schedule
• [To be determined later]
The Secret Plan for Total World Domination
• uPortal and CHEF steal best practice from each other and begin to align future efforts– Services / Super-GUI / Super-CAR
• Once we have services defined – make reference OKI service and OKI tools – deploy LOTS of places– uPortal, Jetspeed 1.4, Jetspeed 2.0, JSR-168,
WSRP, (and Swing)