Simon Nash – member of JSR 175 team

(http://www.softwaresummit.com/2003/speakers/nash.htm)

Back ground and motivation

JSR 175 specification

1)    Source syntax

2)    Processing model

3)    Runtime api

4)    Class file format

5)    Standard annotations

 

Background – java is imperative not declarative, java has declarations but only for core language constructs. The declaration of ‘the what’ limits the scope for tools to help the developer be more productive.

 

The annotations are beyond the bounds of the language, instead it fits into the language. Its not about making Java huge to handle every  thing, its about making a way for you to extend stuff so that you can declare what in your java classes (i.e. this class is a web-service). The annotation are not part of the program logic but can affect the meaning of the program (i.e. the declaration that the class is a web service might causes WSDL to be generated at deployment time). An annotation will not change the way assignment works or the way that try/catch works.

 

Semantics of the annotations can be standard or user defined. (I’m assuming that at some point we will see how to use user defined annotations. Just said we’d be getting to that…)

 

Benefits – productivity, clarity, flexibility, correctness – all the same stuff you get from something like MDA or other model based code generation. I like this but its just not new. Now that its becoming part of the language though it seems that we might be at the cusp of general acceptance of meta-data based programming (i.e. MDA). If you build bad stuff with this it will be bad. Clearly you can build bad stuff with anything, this is no difference.

 

Q: will AOP make use of this, A: probably, seems a natural fit (the join points should be able to be specified with these annotations).

 

175 – simple meta-data in source code, attached to program syntactic elements, limited range of type, stored in the class file (available at runtime), can be read at runtime.

 

Cool example of declaring a web service for a class. Interesting thing to note is that the types of the attributes for annotations is only a limited set (most noteably not Object or any arbitrary subclass, only the types defined in the JSR to be able to be used).

 

Attributes can be defaulted.

 

An example of @WebService annotation for a class then adding an @Operation on one of the operations. The @Operation is not explicitly contained in the @WebService.

There are 4 meta-annotations @Target – what can the annotation end up on, @Retention – how far to carry the annotation forward, @Inherited – declares if the annotation should be inherited, @Documented – should this stuff show up in the java doc.

 

@Retention – runtime, class or source – class is default, runtime makes them available for reflection

 

Since source is the default retention it seems that the expectation is that post processing on class files will be the norm.

 

Annotations can be used anywhere that ‘public’ can be used. They are seen as modifiers.

 

You will be able to annotate your package with a package-info.java file.

 

Processing Model:

1)    Source based

2)    Class based

 

You can integrate your annotation processors with the java compiler? There was a slide about that but it appears that its not ready yet. The way they are thinking is making a plug-in architecture for the compiler. Today what you have to do is post process the class file or process the java code (i.e. you have to parse the java…)

 

JSR 175 extends the reflection API’s to get at annotations. There is a new thing called AnnotatedElement.

 

More annotations are changed or defined in JSR’s (181, 207, 224 others as well).

Paul Giangarra – Portals

 

Third or forth generation portals are about collaboration? Missed the detail on that comment.

 

What is a portal?

1)    a place to start for your users

2)    a place to aggregate the stuff that people want to do

 

Value of Portals

1)    simplify access to resources

2)    eliminate information overload

3)    personalize for the one-to-one marketing appeal

4)    collaboration meets applications

5)    the enterprise now ‘owns’ the desktop

 

The Portal helps to aggregate the information that we want to see, personalized etc. Allows us to avoid info-overload.

 

Why Portals – employee productive, increase efficiency through automation, quicker response to customer

 

Gen0/Gen1 (-1998 to 2000) portals simple hyperlinks and search, homepages on sterids

 

Gen2 (2000 to 2001) robust app framework, collaboration, Mobile and wirelss, management framework, being deployed today

 

Gen3  (2002+) context personalization, cascading portals, web services, process integration, abstraction layers, federated search, federated portals, p2p offline support, proactive notification, mainframe support, knowledge management

 

Why are biz portals so important?

1)    eventually all web apps will be portal apps

2)    portals will be the most visible software infrastructure in a company’s e-business strategy

3)    the need for integration drives the growth and importance of portals

4)    application vendors are using portals as UI and Integration

5)    Portal frameworks…

 

Portal Planning Process – or how to get a portal into your company

1)    obtain sponsorship

2)    analyze drivers and expected benefits

3)    inventory the features desired

4)    conduct an infrastructure impact assessment

5)    select products

6)    sell internally

Basically laid out how to decide if you want to build a portal, decide what you want/need, a portal for portal sake is stupid.

 

Don’t confuse a Portal with a web site. The are not the same, the portal is window into web applications/web sites.

Portal Infrastructure

1)    knowledge arch

2)    community arch

3)    security arch

4)    tech arch

5)    dev and dep

6)    operational arch

Important for B2C portals to truly aggregate the info instead of sending you off (i.e. looking at CD players and linked off to Sony, you just lots a customer, Sony.com has a link to ‘find someone to sell this to you’).

 

Knowledge management is important in building a portal. Unstructured info is just info, if you can organize it its knowledge. We need knowledge.

 

(Paul spawned a thought: Interesting thing to think about: A development portal for open source communities. Why don’t we have something like a portal for developers. Aggregate information into knowledge, connect people in great ways that makes the community more effective.)

 

Lots of detail about objectives that you’d want to build a portal for. This was a lot like a marketing pitch of why portals are important, i.e. why do a portal.

 

Technical arch of the portal

1)    Portlet container services

a.     Content access

b.     Web clipper

c.     Search

d.     Document manager

e.     Po9rtlet data

f.      Admin

g.     Collaboration

h.     Credential vault

i.      Portlet proxy

j.      Single sign-on

2)    J2EE

3)    Page aggregation

a.     Themes and skins

b.     Transcoding

c.     JSP tag library

d.     translation

 

Base portal design – think about it, users, admin, roles etc.

Think through your page layout as well. Title bars, menu’s, hierarchies of portlets etc.

 

JetSpeed is a great spot to play with portlets.

 

Themes do most of the hard work for cross-browser support and accessibility.

 

Delta from JSP/Servlet to Portlets,

1)    portlets are very dynamic

2)    portlets can know personalization info, locale, devices etc.

 

Building a poral –tasks

1)    creating page definitions

2)    create themes ad skins

3)    developing portlets

Cool thing is that all this can happen independently.

 

JSR 168 gives us – interoperability between local portlets and portals, i.e. we can put a portlet written WLS can be deployed into WebSphere

 

WSRP – goals

1)    enable the sharing of portles (markup fragments) over the internet with a common interface

2)    enable cross vendor publishing and consuming of content

 

WSRP allows us to build a portlet and let it be vended into another portal?

A proxy portlet receives info from a web-services interface and then render that portlet in the local Portal.

 

On the portal server the generic proxy (only one, we don’t need to implement it) and it goes off via SOAP and asks for some rendering to be done. The proxy then takes the rendering from the back end and displays it. Very interesting.

Simon Philps – keynote

 

The Massively Connected Era – assumption is mostly valid, the infrastructure is something we can take for granted. When you can just connect and not worry about the syntax of XML etc. you are massively connected.

 

Rapid evolution, in just one decade the world has become massively connected. Other major changes with new inventions has changed the world a lot fast than other inventions.

 

Technology Promotes Connection – divice proliferation, growing bandwitch , SOA, many dimensions/layers of relationships

 

Moving towards Fractal Architectures – we are moving to networks of networks. (Grid Computing?) We will need an understanding of fractal dynamics in networks.

 

Massively Connected – every node is connected to everything else. Thankfully the Internet was not build like bulletin boards. Instead it was built with free open source shared, open, royalty-free standards.

 

Exponential Opportunity Growth through blah blah blah, missed what he said…

 

Interpreting Open for the Era:

1)    80’s

a.     hardware-inspired standards processes

b.     committee membership, specification

2)    90’s

a.     business-inspired standards processes

b.     consortium membership, implementation

3)    21st

a.     community-inspired standards processes

b.     community involvement, open source

Open source is more about the consequences of saving a few bucks on your purchase price, it’s a result of our massively connected time.

 

If the network were the computer,

1)    there would be no boundaries to defend, security would be very different. If we had an identity based approach, web services would be different, because we would not have to be pushing everything through port 80. Instead the security would be defined around identity instead of the boundaries.

2)    Software would become a service that would self organize etc. We would not have to know about or care about where it was running. Grid computing again…

3)    Software would be licensed on scale, not on implementation details. We don’t know exactly where/when the surge will show up so you don’t need to know about licenses (or should not need to know).

4)    System stakeholders would be enfranchised in development. The individuals involved in using (i.e. stakeholders) the software should be involved in defining the software.

The network is the computer now. Part of the reason everything is changing so quickly.

 

Open Source:

1)    it is mostly or largely a development methodology

2)    definition – commons-based peer production http://www.benkler.org/CoasesPenguin.html - 2 modes of production in the past, artisizans work, and manufacturing. Open source is the new type of production, commons-based peer kind of production. Interesting idea.

3)    Structured and controlled development

a.     Reputation-based

b.     Controlled by initiators

c.     Things based on your reputation not your status, your employer etc.

4)    High quality results commonly

5)    Remains loosely-coupled – maintains choice

a.     First and foremost is the right to fork the code, you can always take the code and make your own copy.

6)    Facilitated by commons-creating license

a.     Make the commons possible, not the most important thing, just makes it possible for the community to form and contribute

7)    Many licenses, one objective – make the community possible.

 

Open Source: Agile Development done by a community

 

Open and Proprietary – lots think these are opposite, they are not, standards are open or closed, source is community or proprietary, impl is interoperable or locked

 

Staying Open…

License is for copyright, who owns it and why – LGPL and GPL keeps the power in the hands of the copyright (and threrefore power) holder and not the community.

 

Understanding open source – deployment

The scope of free – free is not the same as zero dollars, free is about freedom not about saving money. Source is for developers, deployers don’t really care about source, they want it to work and be able to fix it if its hosed. The licenses facilitates community.

J we use the same term for our consumers as the drug industry, the first shot is free. J

 

deployment models for open-source;

1)    help your self

2)    package to produce and support

3)    customize per use and support

4)    customize to product and support

5)    aggregate to bundle and support

These are the ways that we will be using open-source in the future.

 

Research suggests that the #1 reason is choice and freedom and quality of the code. Cost is shared, not free, but controlled and shared.

 

www.sunsorce.net for details

 

Lots of other stuff about the open source stuff that Sun, openoffice.org, netbeans.org,

 

Sun Java Desktop System – complete desktop for the average user – initalliy aimed at groups. Looks really cool (it just works, idea ‘stolen’ from the mac J) Open office, mozilla etc.

 

Why sun is doing open source:

1)    shared innovation

2)    customer and partner benefits

3)    increased quality and security

4)    future direction of most software

5)    base for future evolution of best practice and unexpected value

6)    and its still great stuff even after all that

 

Sun’s Expirences – Issues

1)    open source is a big step – its for life not something you drift into

2)    source needs hosting

3)    community needs facilitating

4)    license issues outside education of most IP attorneys

5)    Developers find public exposure a shock

6)    Managers find loss of control challenging

Sun’s Experience – benefits

1)    Good returns

a.     Savings take time to appear

b.     Community is chief asset

2)    Software quality is better

a.     Fewer bugs, more quickly identified

b.     Design tracks market needs

c.     Design improved by extensive review

3)    Lock-in Avoided

a.     No single dominat force

b.     Influence of would-be marked controllers largely avoided

c.     Can always go elsewhere, no IP locks

 

Open Source is the methodology of the massively connected society

Business models of open source are better and the only way to support open source. The community is not set up for deployment, most people choose open source for freedom not because the price tag is low.