UPortal and CHEF Charles Severance ([email protected]) University of Michigan

uPortal and CHEF

Charles Severance ([email protected])

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


Service Broker


GUI Framework


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


Service Broker


GUI Framework


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)

UPortal and CHEF Charles Severance ([email protected]) University of Michigan

Documents

Transcript of UPortal and CHEF Charles Severance ([email protected]) University of Michigan