Moved my technology blog to java.net

Starting January 2006 my technology blogging will be on my blog at java.net.

/computers | permanent link

conferences

I have a lot of conference activity this month. I am on the program committee for this year's International Symposium on Distributed Objects and Applications (DOA) , part of OnTheMove - OTM 2005 Federated Conferences. I was just notified last night that I need to start bidding on papers to review.

I'll be presenting my paper on llava - Java in Lisp Syntax at the International Lisp Conference 2005 at Stanford University June 19-22, 2005. I'll post the paper here after the conference. For now, try the language out: llava.org

I'll present IIOP and SOAP Failover in Static Clusters (coauthored with Ken Cavanaugh) at the International Conference on Communications in Computing (CIC) , part of The 2005 International MultiConference in Computer Science and Computer Engineering (IMCSE'05).

/computers | permanent link

PEPT: description more important than transport

Yesterday I gave a PEPT/SOA talk at Professor Phil Windley's graduate seminar on middleware.

In that presentation I show a "history" of SOA centered on description languages: from C *.h files, through various forms of IDL, to WSDL. While the syntax has changed the function remains the same: show inputs and outputs to "procedures."

I also emphasis how coupling and scaling has changed with respect to "remoting" systems over time. In *.h the coupling is direct - in the same address space, and the scale is direct - communication within a single program.

In DCE, CORBA, RMI the coupling is still tight (i.e., synchronous) but between address spaces, and the scale of communication is increasing - generally across LAN and WANs.

Then I note that SMTP and HTTP taught us that sending messages scales better than RPC

Web Services are beginning to focus on loosely-coupled message-based communication on Internet scale.

However, from a user point of view, the only thing that matters is their data and how that data is used. They don't care if that data has to move from the location of one service to another. And, if the data moves, they don't care how it moves.

So, as a service-oriented architect, the first concern is what the services can do with your data. In other words, with inputs and outputs to the service - not with how the service receives/sends inputs/outputs.

Phil, in a ZDNET entry on my talk, sums the above up nicely as: description is more important than transport.

A service-oriented architect wants a platform that lets them concentrate on the description, letting the platform handle the details of transport.

PEPT is an architecture for such a platform. Course-grained phrases like "alternate transports," "alternate protocols," are useful when talking about the need to be description-oriented. But to actually build a platform that can handle many types of "protocols" it is necessary to be a bit more precise.

So PEPT talks about:

• Presentation: the APIs used to send/receive data and data types allowed.
• Encoding: the wire-representation of the data (and the process of converting to/from that representation.
• Protocol: the use of metadata to handle and route the encoded data.
• Transport: the mechanism used to move the encoded (meta)data from one location to another.

PEPT defines these four fundamental building blocks of a remoting system and shows the relationships between them that allow a system to dynamically switch from one encoding and/or protocol and/or transport to another.

Bottom line: As a SOA user, focus on the data and the descriptions of services. As a SOA platform architect, use an architecture that isolates the use of the platform from specific "transports." Use an architecture that can dynamically switch "transports" on each invocation as need be. Use an architecture that support change over time. PEPT is such an architecture.

/computers/pept | permanent link

Today at the University of Utah School of Computing Industry Forum

Today I spoke at the University of Utah School of Computing's Industry Forum class hosted by Professor John Carter. Ann Torrence helped with logistics.

I was met by one of the students at the door. We spent some time talking about the "real" world - particularly about working remotely. Then off to the class - about 50 undergraduates. They are "bribed" (joke) take the class - they serve them pizza before the class. After the student introduced me I gave my talk. No slides. Just some notes I referred to while talking and writing on the whiteboard.

Like last week, I enjoyed myself. They students asked some good questions and, hopefully, that got something useful from me. I've included my raw notes for the talk below. You might find it interesting.

=================================================

Part 1: Is Worse Worse or Better?

Part 2: To Compose or to Count?

Main point: Encourage *Extensible* Architectures and Languages

subthemes:

     Ability to handle *change* built-in from the beginning

     Long term versus short term

=================================================

Part 1: Is Worse Worse or Better?

BETTER IS BETTER - the "right thing"

    do the right thing no matter how complex it makes code

"MIT/Stanford" style of design

Important to get all right:

Simplicity -- interface (most important) and implementation

Correctness -- Incorrectness not allowed

Consistency -- Inconsistency not allowed.  
    Design may be less simple/complete to avoid inconsistency.

Completeness -- all reasonably expected cases must be covered.
    Simplicity not allowed to overly reduce completeness.

Examples: MIT ITS, CommonLisp/CLOS and Scheme

-----------------------------------------------

WORSE-IS-BETTER:  make code simple, 
                  even if it makes user do more work

"New Jersey" style of design


Simplicity -- Most important design consideration.
    implementation (most important) and interface

Correctness -- Better to be simple than correct

Consistency -- can be sacrificed for simplicity
    better to drop parts that deal with corner cases
    than to introduce implementational complexity
    or inconsistency

Completeness -- all reasonably expected cases should be covered.
    Can be sacrificed in favor of any other quality.

    Must sacrificed when implementation simplicity jeopardized. 

    Consistency sacrificed to achieve completeness
    if simplicity retained; 

    Consistency of interface not important

Examples: Unix and C

-----------------------------------------------

Richard Gabriel's Basic premise: 

    worse is better has better survival characteristics
    than "the right thing"

Example:

MIT ITS:  system routines always succeed, even when interrupted

    simple interface / more complex implementation

UNIX: user code must check error code and loop if failed

    simple implementation / more complex interface

-----------------------------------------------

virus lives while complex organism dies

"Viral" UNIX (and C): easier to understand, implement, port
 - thus they spread (while MIT ITS dies off).

UNIX/C limited functionality (50%).  
Improves through spread to the masses.

But the masses conditioned to accept worse-is-better.

-----------------------------------------------

lesson learned 

undesirable to do right thing first

better to get 50% of right thing available 

it spreads like a virus

once people hooked, take time to improve to 90% of right thing

Note: 50% solution must be basically right

=================================================

Worse is Worse (Jim Waldo "rebuttal")

better is better: 
    do the right thing no matter how complex it makes code

worse is better:
     make code simple, even if it makes user do more work

-----------------------------------------------

Examples:

Multics and VMS viz Unix

CL/Scheme viz C

Beta viz VHS

CORBA viz SOAP

The "worse" one won

-----------------------------------------------

Superior Lisp lost to inferior C

superior by what metric?

But, *at that time*, C:

* produced faster code

* was easier to master

* was easier to use in groups (*.h files)

* ran well on less expensive hardware

So, with these metrics, C is better-is-better.

-----------------------------------------------

Superior Beta lost to inferior VHS

Beta had superior recording quality, but VHS:

* capable of recording longer programs on  single cassette

* could be played on cheaper recorders

* had a number of different suppliers (viz Sony/Beta)

VHS beat because better in *some* dimensions 
(time to record, cost, availability) 
but worse in others (picture quality).

-----------------------------------------------

Superior Multics loses to inferior Unix lost to DOS

but Unix (at that time):

* ran on wide variety of cheap hardware

but DOS (at that time):

* ran on even cheaper hardware

the property of existence on really cheap hardware
turned out to the the metric of goodness that
appealed to the customer

Then, later, Linux and new metric and gains ground:

* open and free

-----------------------------------------------

worse is worse (worse is not better)

what is "better":
    complicated notion: depends on variety of metrics

What "geeks" think is better
may not be what customers think is better.

-----------------------------------------------

"worse is better"

better sound bite than:

"better depends on your goodness metric"

-----------------------------------------------

"worse is better" has become catch phrase for 

* justifying shoddy design

* following crowd (rather than doing right thing)

* claiming customers are too stupid 
  to appreciate quality products
  (so why spend time on right thing)

-----------------------------------------------

End result:

* sloppy products that don't work

* hard to use

* unreliable

Cheapens are craft.

=================================================

Gabriel UPDATE: worse is better 

start with a minimal creation and grow it as needed. 

Christopher Alexander / Pattern Languages:
    "piecemeal growth"

=================================================
Part 2: To Compose or to Count?
=================================================

Composition:  g(f(x))  - as in mathematics

Count:    int a = f(x);
          int b = g(a);

Languages and tools (e.g., debuggers) slanted
toward counting not composing.


-----------------------------------------------
Paul Graham:       

"languages designed for smart people" (LFSPs) 

more fun than

"languages designed for the masses" (LFMs)

LFSPs have greater support for (defining) abstraction

-----------------------------------------------

LFMs deliberately restrict abstractive power

Reassuring 

* average programmer isn't going to see code he can't understand

* manager knows he can fire you and find someone else

But frustrating to Wizards:

* design can be made N times more general and abstract
  but LFM forces one to do the Same Old Thing again and again.

Mixed ability corporate team viz uber-programmers

-----------------------------------------------

Java started as LFM.

Is it becoming a LFSM?
(but has already spread via worse-is-better):

* The new for loop syntax.

* Auto-boxing on assignment and parameter passing.

* Unboxing may cause a null-pointer exception.

* Which method of a set of overloaded methods gets called in the
  presence of auto-boxing.

* What method is being called when some methods may have been
  "statically" imported.

* What identifier is referred to when enum constants have been
  statically  imported.

* What is going on when methods have been added to individual enum
  constants.

* What the new angle-brackets mean when defining a generic type.

* What the angle-brackets mean when using a generic type.

* Where the angle brackets go for a generic method.

* Remembering that generic methods may throw generic exceptions.

* Remembering that you can't use reflection to determine the
  parameterized types at runtime.

* Understanding what happens to your generic type when someone simply
  "casts it away".

-----------------------------------------------

Experiment:

Go to Java 1.4 java.util.Collections documentation.

Compare with Java 1.5 version.

Which is simpler?

If Java would have started with the 1.5 version
would it have been successful?

-----------------------------------------------

LFSM: love to program. 
    Fun (& delighted to find people who will pay them)

LFM: code to pay the bills.

-----------------------------------------------

Technical versus Social Decisions

Lifecycle: maintenance mode:
   successful projects are ones that can
   be maintained by average programmers.

-----------------------------------------------

Personal example: first "loss":

  integrated IC design/simulation system

  broke up into isolated programs that communicated via files

  bad technical - good social
  (two principals could not stand each other)

-----------------------------------------------

Personal example: second "loss":

  Lisp versus C++ (then Java)

  Composition versus Counting

  Composition is "higher" level thinking

  Line-based steppers versus expression based steppers

  Logging, assertions, statements versus expressions.

  AOP to the rescue

  Java + XML = Lisp--

-----------------------------------------------

Aside:

  What are all those parens for?

  "Like nail clippings in a bowl of oatmeal" - Larry Wall

  Indeed, if you're not defining LOTS of macros 
  then what *are* they for?

  Could just use for list data only (e.g., Python)

  But then, how to do macros?  (e.g., H-expressions)

-----------------------------------------------

Notation is important:

  Polya - a good notation helps the problem solve itself

  Bias:
  People have spent a lifetime of education using math notation

  But only half way there:

    They want 
              f(x, y);  - math notation

    not 
              (f x y)   - as in Lisp

    But they want to *COUNT* (or tools force):

             int a = f(x);
             int b = g(a);

  By counting I mean:

  "first do this on this line,
   then do this on the next line"

-----------------------------------------------

Personal example: third "loss":

  CORBA versus SOAP

  XML "ASCII"-based *EASE-OF-ENTRY" (via editors) versus 
  complex binary structures.

  HTTP (simple, dumb, viral spreading) versus IIOP (complex, isolated)

-----------------------------------------------

Generations:

No literature search in industry.

No encouragement for deep knowledge (want "code monkeys")

To climb ladder encouraged to manage or "architect" versus doing "the" work

-----------------------------------------------

Great painters and writers don't delegate 

They continue to do the work themselves

And they continue to study the works of others

-----------------------------------------------

Conclusion:

  Design for the long term:

        Design for *CHANGE*

-----------------------------------------------

Bibliography:

Richard Gabriel, worse is better: 
http://dreamsongs.org/WorseIsBetter.html

Jim Waldo, worse is worse: 
http://www.artima.com/weblogs/viewpost.jsp?thread=24807

Paul Graham, LFSM:
http://paulgraham.com/

Alan Kay:
http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273

/computers | permanent link

Yesterday at the University of Utah School of Computing Colloquium

I gave a talk yesterday at the University of Utah School of Computing. My slides are available in PDF, StarOffice, and html.

It was good to see both old friends and new people there. John Carter is doing research in "surrogate" computing that allows users to dynamically locate, allocate and exploit resources in surrogate computers. His work relates to Sun's utility computing offerings. Jay Lepreau leads the Flux Research Group (that includes Eric Eide and Russ Fish ), doing systems software research. Matthew Flatt does language research using one of my favorite languages: PLT Scheme. He is working on a version of the language with Java-like syntax that includes macros. I was hosted by my thesis advisor, Robert Kessler who is doing research in software engineering.

I also saw Erik Brunvand, Al Davis, Ganesh Gopalakrishnan, David Hanscom and Tom Henderson. All-in-all I enjoyed myself very much. I need to get up to the school more often and attend colloquiums and seminars. A great resource to keep current and stay connected with people in my field.

/computers | permanent link

Harold Carr will speak at University of Utah School of Computing Colloquium and Brigham Young University middleware class

I've been invited by the University of Utah School of Computing to give a colloquium on the topic of my choice on Wednesday February 2, 2005 at 3:30am.

I'll also give a similar talk at Phil Windley's CS601R course on middleware and connected computing at Brigham Young University.

Here's my abstract for both talks (although I will probably give slightly different versions of the actual talk at each event, not sure of the slant yet):

The PEPt Service Oriented Architecture

Service oriented architectures (SOA) are moving us closer to reusable and adaptive remoting systems since they enable users to focus on the exchange of data, not the infrastructure by which it is exchanged. Building a SOA platform is a complex task. That is where PEPt comes in. A SOA platform uses PEPt to implement the lower-level message exchange system. PEPt gives the SOA platform the ability to integrate with existing services (e.g., CORBA, SOAP) and to evolve as new encodings, protocols and transports come into use. This integration and evolution can happen without changing the upper orchestration and choreography layers since they are properly using a more abstract view of data and message exchange.

Sun Microsystems has used PEPt in CORBA to dynamically alternate between TCP/IP, shared memory and InfiniBand transport, and between OMG CDR and Java serialization. PEPt is also used in JAX-RPC to alternate between SOAP Doc/Literal and binary XML encodings.

This talk will first give an overview and history of Service Oriented Computing. It will then present technical details of how the PEPt architecture is used to adaptively exchange messages.

Dr. Harold Carr received his Ph.D., in 1994 at the University of Utah Department of Computer Science, working with Dr. Robert Kessler on Distributed C++. Since then he has worked in the area of distributed computing as a Senior Staff Engineer at Sun Microsystems, designing and implementing the CORBA and JAX-RPC systems in Java.

More information: http://haroldcarr.net/pept

/computers | permanent link

Harold Carr will speak at University of Utah Industry Forum Lecture

I've been invited by the University of Utah School of Computing to speak in their Industry Forum class on February 11, 2005 at 11:40am.

I'm considering contrasting Sun DE Richard Gabriel's paper Worse Is Better with Sun DE Jim Waldo's alternate view. I will illustrate it with my own experience in designing and building computer typesetting systems, IC CAD design systems, Lisp systems and distributed computing systems.

I will also talk about the price of success - dealing with locked-in APIs and versioning now that you have real clients.

/computers | permanent link

Kevin Kelly's Cool Tools and Wired's TEST

Today, in my RSS feed from Kevin Kelly's Cool Tools, he is praising TEST, a trial publication from Wired magazine featuring Consumer Reports' type testing of fast-moving electronic gear. TEST actually says which one is best out of the ones they tried. We includes a link to a PDF (8 MB) version of the magazine supplied by the publishers.

/gear | permanent link

PEPt at the International Conference on Service Oriented Computing

I just returned from presenting the PEPt Service Oriented Architecture at the ACM International Conference on Service Oriented Computing in New York.

PEPt summary: Service descriptions should be abstract. The SOA/ESB platform should adapt to the concrete technologies used by each service. PEPt enables the multi-protocol aspect of SOA - in other words, wide-ranging interoperability.

The conference was good. I had a number of conversations with people I haven't seen at the ACM Middleware 2003 and Distributed Objects and Systems 2003 conferences I have presented at recently.

I spoke at length with Steve Vinoski from IONA. He well understands what I am promoting with PEPt: multi-protocol or multi-access services. See his IEEE paper on the subject

In discussing PEPt in hallway conversations, if Steve was present, he would always point people to Artix, IONA's commercial product that supports multi-protocol services like PEPt.

The rest of this message has highlights of keynotes, presentations, panels and hallway discussions with/by:

• Adam Bosworth : Google (previously BEA, Microsoft, ...)
• Harold Carr : Sun Microsystems
• Tim Berners-Lee : W3C
• Thomas P. Kozempel : Verizon Communications
• Hugh Grant : Credit Suisse First Boston
• Steve Vinoski : IONA
• Mark Roth : Sun Microsystems

Adam Bosworth - Keynote

His main theme: KISS - Keep it Simple and SLOPPY

He is arguing that anything that faces the user should allow for contradictions and ambiguity. Asking for precision from an end-user is the kiss of death for a product or platform. Instead, allow the user to be sloppy and figure out what their intent is. This raises the bar for the engineering team since the internals need architecture and precision.

He mentioned the rising use and interest in scripting languages as an example of KISS: people writing programs in those languages (e.g., Ruby, perl, PHP, ...) are writing disposable programs that generate content. The programs are sloppy and unmaintainable, but the content they generate is the real value. This shifts the focus to content/data and away from APIs.

He is promoting simple, low-tech solutions for users : value is in information, not in the method.

He promoted document exchange: HTTP + XML is good; SOAP + WSDL is bad.

He does admit it is then up to all the PhDs Google is hiring to make sense and organize this content. He said AI is big in Google but you'd be surprised by the amount of Perl code Google produces.

I asked about sloppy viz-a-viz maintainability. He said that strongly-typed languages and OO seemed like silver bullets initially but that large OO-based projects are still difficult to maintain and change. So OO-based projects are more maintainable to a degree but not as much as people like to believe.

I asked about BEA. He said before he left there was a struggle between himself, who was promoting supporting .NET on their platform and the app server people. The app server people won. He thinks that BEA is becoming a legacy app server company. He also said most people buy an app server then only use servlets connected to a database anyway. He also mentioned that, with the availability of zero-cost or low-cost app servers, the money is in service contracts and BEA is not set up to function as a service company.

He mentioned that RDF and IIOP were collapsing because they were to complicated compared to the KIS/Sloppy principle he was advocating. I pointed out that IIOP was doing just fine, maybe not getting the update of SOAP, but certainly not collapsing. Steve Vinoski pointed out that IONA makes 90% of their revenue from IIOP. When further pressed he admitted that things like RDF are used internally alot at Google - in other words, his KIS/Sloppy principle applies to user/customer-facing software, not the the internal architecture of such software.

I asked why so many of Google's new products/features only work on Windows. He said, 0) it is not intentional; 1) because Google acquires small companies with that characteristic and Google then doesn't have a business case nor people/resources to make it cross-platform; 2) because Google is a very engineering driven company and engineers use whatever tools they like - many of them coming from Windows shops.

Slides from his talk are available at Adam Bosworth's Weblog

Harold Carr

Service descriptions should be abstract. The SOA/ESB platform should adapt to the concrete technologies used by each service. PEPt enables the multi-protocol aspect of SOA.

Steve Vinoski asked what type system is used by PEPt? PEPt does NOT define a type system. That is an agreement between the presentation layer (what language data types are allowed) and an Encoder for a particular "protocol". There is NO universal type system.

In the following afternoon's Panel discussion Steve was asked is WS/SOAP different/worse/better than CORBA? He said the basic infrastructure is the same but the thing that made SOAP better (in terms of scalability) in that it does not define a type system (as in IDL) that must be mapped onto each language. He said a universal type system does not scale.

Tim Berners-Lee Keynote

Perhaps the most interesting, to me, comment he made was regarding RDF goal resolution for workflow instead of BPEL:

Rather than UDDI/BPEL, etc., advertise and find services via RDF descriptions. And describe the work flow with RDF. Then the workflow description plus goal resolution becomes the workflow.

In design, bottom-up/outward good for unintended consequences. Top-down/inward doesn't play well with the world outside it. His examples: top-down: BPEL; bottom-up: OWL.

Other tidbits:

Big change depends on getting the small details of the lowest levels right.

Promoted document-exchange rather than RPC.

SOAP is good since it focuses on the wire not on languages or types.

He presented the pros and cons of WS design approaches at different levels. Of course, with Tim, it leads up to the promotion of the Slides from his talk.

Panel on Industrial SOA

Thursday afternoon Steve Vinoski moderated a panel on industrial service oriented architectures. The panelists were Hugh Grant from Credit Suisse First Boston, Thomas P. Kozempel from Verizon Communications, and Francisco "Paco" Curbera from IBM Research (T.J. Watson)

Thomas Kozempel gave an overview of what they're doing with services at Verizon, how getting there required a few non-technical and cultural changes, and how they're now much more able to measure return on investment - a SOA success story.

A SOA is the underpinnings of Verizon's iobi offering.

Hugh Grant mentioned the shortcomings of UDDI for his organization. He said the thing that makes SOAP good is INTEROPERABILITY in the sense that Microsoft is in the game. He said where we are today is where we could have been in 1995 if Microsoft would have done IIOP.

Other papers

Multi-Channel Adaption - from Italy Enable users to switch from one device (e.g, cell to PC) to another to perform similar activities via a reflective architecture that discovers and automatically adapts to the accessed services or different channels.

Hybrid Web Service Composition: Business Processes Meet Business Rules - from Germany Claims that BPEL4WS and BPML cause the whole business logic underlying a composition (including business policies and constraints) to be coded as a monolithic block. They show an alternative "Aspect-Oriented" AO4BPEL approach claiming it is more modular and dynamic.

Dynamic Service Composition Using Semantic Information -from UC Irvine Existing service composition systems require requests in strict syntax. That is an obstacle to discovery and use. Instead, they argue that service composition should be semantics-based and show a prototype system.

Cremona: An Architecture and Library for Creation and Monitoring of WS-Agreements - from IBM Watson Using services across domain boundaries requires the setup of agreements between parties. Cremona (Creation and Monitoring of Agreements) proposes an architecture for the WS-Agreement implementing middleware.

Hot Service Deployment in an Ad Hoc Grid Environment - from Germany A solution to the problem of dynamically deploying grid service factories onto computing nodes running an implementation of Open Grid Services Infrastructure (OGSI).

A Concrete Solution for Web Services Adaptability Using Policies and Aspects - from France SOA aims to develop more adaptable systems but we aren't there yet. This paper show using Aspect Oriented Programming to weave in non-functional security aspects depending on policies requirements.

Exact Functional Context Matching for Web Services - from Australia Service discovery based on keyword-matching (UDDI) have a low matching precision (note, just about everyone at the conference panned UDDI). The propose exposing the service's goals and domain semantics to enable better matching.

Behavioral Models as Service Descriptions - from AT&T Labs Interface descriptions (e.g., WSDL, IDL) are too abstract to describe complex e-commerce services. This paper extends the WSCL and OWL-S semantic service descriptions with abstract executable behavioral models.

Web Services: a Process Algebra Approach - from Italy Design and verification of WSs using process algebras. Show two-mapping from these algebras and BPEL4WS.

A Service-Orient Architecture for Digital Libraries from Penn State This paper reports on how they enable CiteSeer as a Semantic-Web service. At the end of their presentation they noted that Google has now introduced a beta version of a similar service http://scholar.google.com/

Other papers on trust, selection, monitoring, measuring, securing SOA based systems.

I ended my trip in New York by meeting up with a Sun coworker, Mark Roth, who lives and works in New York. We went to dinner in the Village, then jazz at the Village Vanguard.

/computers/pept | permanent link

PEPt and SOA at Sun & Greg Papadopoulos at the Computer History Museum

I'm in Silicon Valley this week. Today I gave a presentation at Sun on PEPt and its relation to SOA and ESB. More on that in a future entry.

In the evening I went to the Computer History Museum in Mountain View to hear Sun's Greg Papadopoulos' talk "The Glacial Rate of Breakneck Change." Here are my notes.

Reasonably modern processor design goal (IBM ACS circa 1965):

64-bit; 7-issue; out-of-order; 50 instruction window; branch
prediction; precise interrupts; 16-way memory interleaves; 2-way
set-associative cache; kifer road startup; 10ns cycle time; 

------

37 years of moore's law give 2^24 but tech factor (ram, cycle, flops,
disk transistors) is around a factor of 1000.

Moore's law about density (ie minituration)

------

5 arch ideas:

- indirection
- interpretation (ie microcode)
- caching     
- virtualization (many machines on one)
- parallelism

--------

don't let electrical engineers design processors
DSP = destroy software productivity

Intel 432 may have been way ahead of their time
don't let computer scientists design them either
-----

Value: Hennessey and Patterson: computer engineering

CS' big failure: Binary Compatibility is a bug, not a feature

We write in high-level languages but deliver in binaries.
Therefore, when buying software you need to buy for your system

We shouldn't have to care about he instruction set

-----

parallelism - use it out of necessity - not because it is elegant
easier to reason about a single line of control

parallelism: pipelines; multi-issue + speculation; multi-thread +
speculation; multiprocessor

Burton Smith (Cray) has a unified view of all of this... use it to
hide latency and delay

------

1994 - collapse of a rich debate

SIMD; MIMD; COMA (Cache-Only Memory Architecture); VLIW, transactional
memory; dataflow; collective communications;

all informed by Linguistic Exploration

-----

Architectural Axioms

Cray: there is no substitute for real memory

Culler: there is no substitute for real bandwidth

Smith: It's latency, stupid

Papadopoulos:: tolerating latency is no excuse for introducing it

-----

Golden Age:
   proprietary HW/OS: 

   vector: cray-1, fujitsu, nec

   MPP: CM-5, T3D, AP1000 Pragon, KSR..

Dark age:

   commodity HW/OS

   clusters

-------

Bit-mapped displays set back computer arch 10 years.

So left using languages for design and started drawing pictures again

Linguistic Regression?

Vector -> data parallel -> Message Passing
Vector    MPP              Clusters

-----

lesson from MPP era:

scaling up doesn't matter if you can't scale down

-----

Microcircuits 
discrete processors -> (transition around 1985)

microprocessors
discrete systems -> (transition coming in 2nd half of first decade)

microsystems (entire computer on a chip - no more motherboards)
discrete networks

progress in cache coherency, big swp, ...

-------


sun
niagara
32-way server-on-a-chip

-------

single-thread single-core
multi-thread single-core
multi-thread multi-core (back to the future: simple processor design)

-------

tagged memory (ala Lisp) coming back (for security reasons)

-------

big organizational concepts:
historical cycle of computing industry - every 10-15 years

system / when / tech                       / scale
MF     / 60s  / transistor and core memory / 1
Minis  / 70s  / SSi & MSI                  / 1
PC WS  / 80s  / uP & LSI                   / 1
SMP    / 90s  / VLSI & DRAM                  / 100

NEW    / 00s  / Microsystems & Fiber Optics / 1000s

------

bandwidth increases

all-optical circuit-switched networks

------

what is the O/S for this new systems?

------

fundamental issues:

- distribution
- energy
- uncertainty
- trust

--------

energy: computing must ultimately be environmentally sustainable

uncertainty: microscale: quantum and cosmic particles
   macroscale: interacting complex systems

----

if IP is the backplane then the whole internet is the computer

-----

Q&A

Need to get free of instruction sets.

Internet programs are a step in the right direction.

It's not about the processor architecture - it's about the
organization of the larger systems

The utility of service model of computing will happen.

SETI: are we alone?  How do you look for technology artifacts?

Watershed: Your time is more valuable than the computer's time.

Future watershed: when the computer decides that its time is more
important than yours (ie AI)

/computers | permanent link

Things to consider when starting a new project

It doesn't work to add these items later. You've got to design it in from the beginning. Also see my note on Ray Ozzie's Extreme Mobility for his list.

/computers | permanent link

llava - the labor day release

Well I spent my 3-day weekend working on llava. I've cleaned it up a bit and I just did the laborday release. Check it out:

http://llava.org/

The main thing I did was write the beginnings (still plenty to do) of a "llavadoc" system. Here is an example to get the flavor:

(package org.llava.lib.Exceptions)

(-doc-
 (name apply-fail-on-false)
 (param procedure)
 (param list)
 (result obj "like (apply procedure args)")
 (throws LlavaException "If result is false.")
 (description 
  "Identical to apply except it raises an
   exception if the result is false."
  (example "(apply (lambda (x) (pair? x)) '((1 . 2))) ==> true")
  (example "(apply (lambda (x) (pair? x)) '(1)) ; throws exception ")))

(define apply-fail-on-false 
  (lambda (procedure args)
    (let ((result (apply procedure args)))
      (cond (result)
	    (else (error* (cons procedure args) " failed"))))))

So the documentation on the site is fairly complete (in terms of listing the available macros and procedures) but still needs lots of detail and a format more like javadoc. But it's a big improvement over what was there before.

Enjoy - "the llava team"

/computers/llava | permanent link

Structure and Interpretation of Classical Mechanics

I stumbled across a book I'm surprised I didn't know about sooner: Structure and Interpretation of Classical Mechanics by Gerald Sussman and Jack Wisdom. Gerald Sussman is also the author of Structure and Interpretation of Computer Programs - a classic in computer science and in the Lisp/Scheme world.

SICM uses Scheme to teach classical mechanics like SICP uses Scheme to teach computer science. From the publisher:

/computers | permanent link

Jim Waldo at Sun Labs Open House

I was in Silicon Valley last week, on-site at Sun's Santa Clara campus and attending the Sun Labs Open House at the Computer History Museum in Mountain View. I enjoyed Jim Waldo's (the father of Java RMI) talk and spent some time with him in the hallways discussion aspect of distributed computing.

Some high-level notes from his presentation:

Need to build in the ability for the system to change over time. (Sounds like PEPt to me.)

The phone network guys got it right.

Infinite storage: implies hard to find data

Challenge: pairing computation and information

Challenge: How to compute on partial data: (no global quantification; data changes faster than you can): implies perhaps statistical computing

Reliability as system property: Individual machines will fail. Network must remain - survive any component loss Components will be replaced (repair faults; increase capacity; upgrade)

System evolution: new components; functionality; changes made without interrupting or shutting down existing services

Previous experience (none of these have the scale of everything connected): Flexible/adaptable: Jini; JXTA; LOCKSS Sensor networks; RFID

/computers | permanent link

Gosling on corporations

"Never mistake a corporation for a coherent entity."

/computers | permanent link

PEPt going to Las Vegas

My paper "Client-side Encoding, Protocol and Transport Extensibility for Remoting Systems" has been accepted as a regular research paper in the International Conference on Communications in Computing (CIC) as part of the 2004 International MultiConference in Computer Science and Computer Engineering to be held in Las Vegas, Nevada, USA June 21-24. Here is a draft (pdf) of the paper. I'll update the link with the final version soon.

/computers/pept | permanent link

Ann Eskesen on SBIR

Yesterday I went to the Huntsman Cancer Institute auditorium to see Ann Eskesen's, President of Innovation Development Institute, presentation "Effective Usage of the Federal Small Business Innovative Research program". Ann is recognized as one of the leading SBIR experts and an advocate for this important small business development resource program. She is a very dynamic public speaker. Here are my notes.

Delay or don't do external financing. Instead, use SBIR to develop capabilities.

Use SBIR to commercialize current research (not to do further research).

Ideas are a dime a dozen. The real question is how to develop, deliver and HAND-OFF your idea.

Stages: 1. research. 2. development. 3. Demo. 4. INTO USE-CONDITION.

"I found it!" viz-a-viz "I sold it" = science viz-a-viz technology. SBIR is about technology.

With SBIR: no debt, no outside ownership, no downstream royalties.

Multiple SBIR submission strategy: What have you got NOW? What will you have in the pipe in 2-3 years?

Find out what SBIR agencies are financing - what are their needs? Fill those needs but have a backdrop agenda to meet your needs.

Unbundle your project such that each piece is valuable to some agency. No single agency should be the kingping. Spreads risk. They pay for a piece but get whole.

Possibility: (Software) development like producing a movie. Bring in independents under strong director and talent to create a functional organization. When project done players disperse into other projects.

Know BUZZWORDS important to evaluators.

Search abstracts of previously funded projects to see who funded them. Correlation between project and agency not obvious (e.g., don't go to EPA for an environmental project).

Agency TECHNICAL OFFICER: person responsible for tracking what you are doing with their money (and his career).

TALK to technical officer. Visit them. Get their input Visit them Build the cost of visit into your proposal - get government to pay for it. Whenever you get publicity be sure to mention agency and technical officer by NAME.

Find where the technical officer is on their tour-of-duty (e.g., DOD has 4-year stints). If near end, cultivate relationship with successor or others in agency who will go to bat for you.

Build a close working relationship. Know who is making decision and how they are being made.

The agency/to funding you is your CUSTOMER. Find out their PROBLEM. Find out where they get their MONEY.

SBIR program manager are usually 35-42 years of age on their way up the ladder. They want you to succeed so they will succeed.

SBIR proposers are often in their 50s, already have professional experience.

SBIR topics, evaluation process and evaluators. Downstream condition (phase III).

Mission agency (e.g., DOD, NASA): contract obligation.

R and D agency (e.g., NIH, NSF): grant for directed research.

Mission agency: to solve CURRENT operational and production problems. To prepare for contingencies. To explore new technology.

What is their MISSION? What are they BUYING? You are NOT SELLING.

Read topic carefully. Review state-of-art (know your competitors). Identify independent experts. Interact with topic sponsor (before topic goes public).

Identify and make contact with END-USER (during phase II) - the person who will actually use your product.

Pre-proposal: Allocate resources to handle SBIR. Understand needs of customers. Extensive use of collaborations. Show clear, credible path to IN-USE condition. Create setting in which to brainstorm with topic sponsor. Write white papers and give presentations. Define commercialization strategy. Play to your strength but know your weaknesses.

Proposal: Read instructions. Visualize flow. Illustrations. Outline. Storyboard. Write out-of-order.

Recent SBIR award recipients: Qualcomm, Biogen, Millenium Pharm, Speechworks, Cepheid, Curagen, Amgen, ABIOMED, Stem Cells Inc., Cor Therapeutics

Previous SBIR recipients: Nortan (antivirus), JDS Uniphase.

IP is yours. Be sure not to sign it away. Not required by SBIR.

What you need: R and D: $100K. Prototype: $700K. First commercial release (early adopter): $4,900K.

Time you need: R and D: 1 year. Full development: 3 years. Profit: 2 years.

Read Crossing the Chasm.

Statistic: companies with patents have more SBIR money.

/computers | permanent link

Foundations of Computer Communication

There is much talk of web services being a new paradigm - fundamentally different than previous remoting systems such as DCE, DCOM and CORBA. There are some fundamental differences such as loose or tight-coupling, stateless or stateful, object-based (implying object references) or service-description-based, etc. Two of my previous posts (1 2) map some of these differences.

However, web services and distributed objects do share much infrastructure as pointed out by my PEPt architecture. They both exchange messages. The data exchanged needs to be encoded according to some agreement between communicating peers. The "business" data needs some accompanying "meta" data and protocol information to help route the data to the correct handler. The messages are exchanged by means of a transport.

Sometimes people say that messaging systems and RPC systems are fundamentally different. At the programming model they are different, but at the infrastructure level they both have encodings, protocols and transports.

PEPt is the beginning of a Foundations of Computer Communication, showing what is common such that the common parts may be shared, and pointing out what is different so real value can be obtained from those differences.

/computers/pept | permanent link

Middleware 2004 Conference

The 5th ACM/IFIP/Usenix International Middleware Conference will be held in Toronto in October. Hans-Arno Jacobsen heads the program committee (which includes me). Steve Vinoski heads the general organization. Deadline for submission is March 30th. For more details see the conference website and the call for papers.

/computers | permanent link

PEPt is Structure and Profitability = Functionality + Manageability

Perez' law: Profitability = Functionality + Manageability relates to my PEPt remoting architecture:

Manageability = Structure

Both structure and function are important to profitability.

We mostly think of profitability from the functional side:

• What can we sell, and for how much?
• Features directly visible to the customer.

Profitability isn't only about revenue, but about cost as well.

Good structure:

• Holds down development costs by localizing change.
• Reduces cost by making the code easier to understand and modify.

Poor structure leads to increase in raw development cost:

• long discovery times
• more intense coordination across major interfaces.

I've been promoting PEPt as a way to do more with less.

/computers | permanent link

PEPt presentation at OTM 03 (Sicily)

Today I gave a presentation ( sxi) on PEPt - A Minimal RPC Architecture has been accepted for the Industry Program Workshop (IPW) portion of On the Move Federated Conferences (OMT 03).

The complete paper is available: html, pdf, ps.

/computers/pept | permanent link

OTM 03 Banquet in Sicily

Tonight, at the conference banquet, I had dinner with Hojjat Jafarpour, a graduate student from the University of Tehran. He is presenting a paper on Friday on "A fast group communication system for large-scale distributed objects". His central idea is to have each group member host a Message Dispatcher Object that distributes (in parallel) the group communication load among all members. The proposed mechanism recovers from host failure. I am hoping to hook him up with the University of Utah's Netbed (aka emulab) project to help him further develop his system. That's Hojjat in the middle background between Denis (left) and me (right) in the foreground of this picture from the banquet.

/computers/pept | permanent link

Dinner in Acireale, Sicily (OTM 03)

I'm in Sicily to present a paper on PEPt at On the Move Federated Conferences (OMT 03). Tonight I had dinner with Richard Soley, Denis Caromel, and Bruno Dillenseger in Acireale at Ristorante L'Oste Scuro.

/computers/pept | permanent link

PEPt going to Italy (OTM 03)
My paper PEPt - A Minimal RPC Architecture (html, pdf, ps) has been accepted for the Industry Program Workshop (IPW) portion of On the Move Federated Conferences (OMT 03), a federation of conferences including Distributed Objects and Applications (DOA), Cooperative Information Systems (CoopIS), and Ontologies, Databases and Applications of SEmantics. It will be held in Catania, Sicily at the foot of Mount Etna. Do you know of any good air fares or sights I shouldn't miss while there? I'll post my slides for my presentation once I make them.

/computers/pept | permanent link

Tight viz-a-viz loose-coupling
Manageability has a useful table which references Bill de hora's blog entry blog entry (loosely-coupled programming is not like Java programming):

• Avoid changing or extending the interface methods
  • REST style
• Control change by using a dictionary interface
  • Dynamic Typing
• Calls should return documents not objects
  • Coarse-grained messaging
• Avoid binary compatability
• Don't confuse an API with a contract
  • Contracts instead of APIs - choreography
  • Being able to introspect the definition of how parties interact is something completely absent in conventional programming.
• Version the contract
• Don't build an API for data transfer.

/computers | permanent link

REST Limitations
Although I have been a fan of REST, Werner Vogels' recent post, Web Services are NOT Distributed Object helped me to see that REST has been useful in foregrounding document-exchange, but thats its days are numbered in the enterprise since it depends on HTTP. Here are some excerpts from Werner's post:

Web services are frequently described as the new incarnation of distributed object technology. This is a misconception.

Minimal web services defined

• The Service. A software component capable of processing an XML document it has received through some combination of transport and application protocols. How this software component is constructed is not important.
• The Document.  The XML document to be processed is the keystone of a web service, as it contains all the application-specific information. The documents are described using an XML schema shared by processes engaged in a conversation.
• The Address. A protocol binding combined with a network address that can be used to access the service.
• The Envelope. A message encapsulation protocol that ensures that the XML document to be processed is clearly separated from other information such as routing, security, etc., added to the message without the need to modify the XML document.

Document-oriented distributed computing is all about the design of the documents you want to exchange. Protocols and addresses are glue. The goal of web services is to enable machine-to-machine communication at the same scale and using the same style of protocols as human interface centered World Wide Web.

Misconception: Web services are just like distributed objects

Both have

• some sort of description language,
• well-defined network interactions,
• mechanism for registering and discovering available components.

An aspect at the core of distributed object technology is the notion of the object life cycle: instantiation, invocation, release. The object is identified through a reference. The notion of object reference is essential. It enables a caller to call the same object again and as such access the same state.

The only technology web services have is XML documents and document encapsulation.

• Distributed objects enable statefull distributed computing.
• Web services enable stateless distributed computing.

Whether a service is truly stateless is disputable (e.g., web document contains a customer identification number, which the service then uses to retrieve customer state from a database). Web services need Coordination to enable multiple services and their consumers to establish a context for their interaction. It is a misconception to see this context as a weak form of object references, as it references an ongoing conversation and does not reference any state at the services.

Misconception: Web Services need HTTP

Web services are transport-agnostic, meaning that they can be accessed over any type of transport or application protocol.

However, it is true that the majority of the web services that are in use at this moment run over HTTP. Reasons:

• Early web service toolskits use Apache, Websphere, etc.
• Current slim-economy requires web service to be built without requiring too much new infrastructure.
• Bypass firewalls (dangerous: should only do this with extensive content-based filtering).

Misconception: Web services need web servers

Drop the "web" from web services: e.g., service-oriented architectures or services bus which do not rely on any web technologies such as HTTP, or web servers.

There are toolkits that support web service development/integration without the need for a web server infrastructure, e.g., are Simon Fell’s PocketSoap, Systinet’s WASP,  IBM’s Emerging Technologies Toolkit and Microsoft’s WSE, Artix and DocSOAP.

Regarding REST: REST encompasses some of the techniques that make web infrastructures scalable. REST adds value by foregrounding resource identification and operation visibility. But REST is becoming irrelevant for the bigger picture of web services, given that transport independence is surpasing the importance of the "web" part of web services. REST principles are relevant for the HTTP binding, and for the web server parsing of resource names, but are useless in the context of TCP or message queue bindings where the HTTP verbs do not apply.

/computers | permanent link

JBOSS, Middleware 2003 and PEPt
I recently gave a presentation on JBOSS implementation details as I understand them from their paper/presentation at Middleware 2003. My presentation focuses on JBOSS' Remote Invocation Architecture (RIA).

JBOSS's RIA correctly separates the presentation block from the encoding, protocol and transport blocks (EPt - as defined by PEPt). Client-side proxies convert all invocations into an internal data structure. This internal data structure is what is referenced/passed throughout the system. From a PEPt point-of-view that means the JBOSS internal architecture uses a single, unified presentation block. This important step allows the system to dynamically support multiple EPts without the entire internal architecture needing to be aware of this support. Instead, EPt support, in JBOSS, is encapsulated at the point invocations go on the "wire".

My presentation shows how JBOSS RIA realizes PEPt. It shows that EPt is encapsulated by "Invoker Proxies" and "Invoker Mbeans". The slides show a sound architecture but are somewhat misleading. They do not show the complexity of the internal details of EPt support. For that, I refer you to my papers on PEPt.

/computers/pept | permanent link

Ray Ozzie's Extreme Mobility
Ray Ozzie, the founder of Groove Networks, recently blogged on extreme mobility. I've summarized his main points here:

Dimensions of mobility:

• Automatic synchronization of multiple devices.
• Support for federation of function across devices.
• Universal accessibility: (generally through web browser)

• Assumes all infrastructure is usable yet inherently untrustworthy.
• Rule-of-thumb: if I can get a browser to display an arbitrary web page, then my mobile application should work (maybe slowly).

• "With whom is this application being shared?"
• an application can interact with one or more individuals and/or systems/processes/agents/

Aspects of mobility

• Application on server.
• Remote interface (X-Windows, Remote Desktop, Browser)

• Restricted to "tethered" mode.
• Subject to bandwidth and latency issues.

• Moving data (documents, contacts, records) between server and mobile device.

• Asymmetric (dissemination with caching, such as RSS or HTML)
• Symmetric (checkin/out or synchronization/replication with conflict handling)

• Synchronization of _references_ to data objects concurrent with movement of data.

• Synchronization of intended behavior of operation/transaction within an distributed application (e.g. offline and/or concurrent users performing task that needs to be reconciled).

Architectures for mobility

• Centralized data & applications, remote access by live or cached UI.
• Application centralized, data centralized, transaction integrity.
• Example: SharePoint, Remote Desktop, eBay.
• Pro: universal access.
• Con: small range of mobility scenarios; no offline use; firewalls may block access.

• Centralized data & transaction services, loosely-coupled decentralized applications bound by interface/protocol agreements.
• Same or different applications distributed, transactions centrally coordinated, transaction integrity.
• Example: SharpReader, Radio, Groove Web Services.
• Pro: best of breed interface for a broad variety of device types.
• Con: no offline use; devolves to checkin/out or workflow to deal with sync when offline.

• Decentralized unsynchronized data & loosely-coupled applications bound by interface/protocol agreements.
• Same or different applications distributed; no inherent synchronization; no inherent coordination of transactions.
• Example: Outlook, Office, InfoPath, Chandler.
• Pro: works on/offline for uses involving routing of data objects such as contacts, messages, files and documents.
• Con: cannot deal with collections of workspaces, or applications shared across devices or by multiple people.

• Decentralized synchronized/replicated data; loosely coupled applications bound by data format agreements.
• Same or different applications distributed; underlying data synchronized/replicated; differing transactions uncoordinated with integrity not possible.
• Example: Lotus Notes, Palm Desktop, Groove Mobile Workspace for SharePoint.
• Pro: works on/offline for shared collections of simple data objects such as contacts, messages, documents, tracking applications.
• Con: does not handle distributed consistency of application behavior.

• Decentralized synchronized tightly-coupled applications & data.
• Same app and data distributed; transaction behavior coordinated; transaction integrity.
• Example: Groove Workspace.
• Pro: works on/offline.
• Con: requirement for same application on all endpoints may not fit all types of devices.

• Applications and data will be distributed
• User-friendly key management
• Secure (even in the face of user indifference)

/computers | permanent link

Binary XML
A long time ago, in compiled LISP, if you had:

    '(a "b" 3 4.5)

/computers | permanent link

Motivation for PEPt
Since Phil Windley mentioned PEPt in his blog I've received questions such as

• "Is this a system I can download to do XML-RPC?"
• "What language is it written in?"
• "Does it support JMS?"

/computers/pept | permanent link

Categories as Ontologies
When you create categories for a weblog (or browser bookmark folders for that matter), you are essentially creating an ontology. Designing an ontology for knowledge sharing and reuse is a deep research topic. Especially when one realizes that an ontology will need to evolve (i.e., change). Coupled with permalinks, it's enough to make you freeze up before committing to any particular set of categories.

So how to start? One can go to first principles, as Thoreau did in Walden where he came up with four categories:

The necessaries of life for man in this climate may, accurately enough, be distributed under the several heads of Food, Shelter, Clothing, and Fuel; for not till we have secured these are we prepared to entertain the true problems of life with freedom and a prospect of success.   ...   The grand necessity, then, for our bodies, is to keep warm, to keep the vital heat in us.

• Conceptual Trends
• Design
• Health
• Homestead
• Learning
• Livelihood/Workplace
• Media
• Nomadics
• Systems
• Tools
• True Films

• Places
• Shelter
• Technology (another name for Tools?)
• Community

/learning | permanent link

Synchronization
I typically use several machines (many simultaneously):

• Solaris 5.7: Sun Ultra 10 (Utah)
• Solaris 5.8: Sun Ultra 10 (California)
• Mac OS X: Apple iBook (everywhere)
• Windows NT: Toshiba Tecra 8000 laptop (Utah)
• Windows 98: home-built desktop (Utah)
• Linux (RedHat 7.1): my sister's old Compaq Presario (Utah)
• FreeBSD : hosts my website (Colorado)

/computers | permanent link

PEPt in Brazil
I recently returned from two weeks in Brazil. The first week I was in Rio de Janeiro presenting a paper on the PEPt Remoting Architecture at Middleware 2003.

/computers/pept | permanent link

about: Harold Carr
harold dot carr at gmail dot com

Syndication

Music, Art, Life: haroldcarr.org

Software
llava.org

Computer Science
PEPt
DCS Course Proporosal
curriculum vitae

Categories

• computers (19)
• gear (1)
• learning (1)
• places (0)

Archives

• January 2006 (1)
• June 2005 (1)
• April 2005 (1)
• February 2005 (2)
• January 2005 (1)
• December 2004 (2)
• November 2004 (1)
• September 2004 (3)
• August 2004 (2)
• July 2004 (1)
• April 2004 (3)
• March 2004 (1)
• February 2004 (1)
• November 2003 (3)
• September 2003 (4)
• August 2003 (1)
• July 2003 (5)

Technorati Profile