All Annotations

JSR-311: a Java API for RESTful Web Services?

I am still not so sure what they want to do exactly, but it seems to be based on JRA which has annotations of the form:

@Get
@HttpResource(location="/customers")
public List getCustomers();

For me a more interesting JSR would be one that would standardise the @rdf annotations the way so(m)mer is doing it.

The RESTlet framework was created because:

"I noted the lack of a REST framework in Java. The only project that came close to it was 1060 NetKernel developed by 1060 Research but it had too many features for my needs and I found that the mapping of REST concepts was not as direct as I was expecting."

It seems that annotations are an exceedingly useful tool, especially having used Elmo's annotations of interfaces to generate beans from RDF (link to PDF documentation). Annotating interfaces rather than classes, seems to be the way to go, given that interfaces can represent relationships like multiple inheritance. Elmo was inspired by subject oriented programming that provides a way "to group common behaviours and separate these different roles into unique interfaces and reusable classes." It's especially useful for unplanned extensions (through composition).

Googling for the various projects brought up, Tripresso looking at mapping RDF to OO (including Java, Ruby, Python and PHP projects). If object to relational mapping is the Vietnam of computer science, I wonder what object to RDF mapping is.

See the previous discussion, RDF on Rails ( mentioning ActiveRDF, RdfReactor, etc) and Henry Story's original, Java Annotations & the Semantic Web.

Dynamic vs Static

A Semantic Web Primer for Object-Oriented Software Developers "In contrast to object-oriented systems, where objects normally cannot change their type, applications based on Semantic Web technology can follow a formal, yet dynamic typing system. RDF and OWL classes themselves are also dynamic, it is possible to create and manipulate them at runtime. For example, one could define a temporary class that is formally represented as an OWL expression and then ask the reasoner about the instances of this class. This means that reasoners can be compared to rich query answering systems. These queries can not only be asked at ontology design time, but also at execution time."

OO is a trick, functional programming is a lie and C# sucks

Good Ideas, Through the Looking Glass (PDF) "Enough has been said and written about this non-feature [goto] to convince almost everyone that it is a primary example of a bad idea. The designer of Pascal retained the goto statement (as well as the if statement without closing end symbol). Apparently he lacked the courage to break with convention and made wrong concessions to traditionalists. But that was in 1968. By now, almost everybody has understood the problem, but apparently not the designers of the latest commercial programming languages, such as C#."

"To postulate a state-less model of computation on top of a machinery whose most eminent characteristic is state, seems to be an odd idea, to say the least. The gap between model and machinery is wide, and therefore costly to bridge. No hardware support feature can wash this fact aside: It remains a bad idea for practice. This has in due time also been recognized by the protagonists of functional languages. They have introduced state (and variables) in various tricky ways. The purely functional character has thereby been compromised and sacrificed. The old terminology has become deceiving."

"...this writer believes that a more effective way to let a system make good use of parallelism is provided by object-orientation, each object representing its own behaviour in the form of a “private” process."

And on Object Oriented Programming: "Objects are records, classes are types, methods are procedures, and sending a method is equivalent to calling a procedure...Was this change of terminology expressing an essential paradigm shift, or was it a vehicle for gaining attention, a “sales trick”? "

Encapsulation for Design by Contract

The Three Reasons for Data Encapsulation "It’s not that data encapsulation does not separate interface from implementation, or that separating interface from implementation is unimportant. It’s just that this is by far the least important reason for data encapsulation...Data encapsulation allows programmers to enforce class invariants, preconditions, and postconditions."

"The I in API stands for interface, and interfaces are for people, not just machines. APIs can be complex, confusing things. The less there is of it, the better. The smaller and simpler the API is, the easier it is to learn and use; the more likely it is that the API will be used correctly."

Rationalizing Relational and OO

Moving forward with relational: looking for objects in the relational model, Chris Date finds they were there all the time. "The question is how to integrate the good ideas of object-oriented database with relational ideas. The wonderful thing is, it turns out you don't have to do anything to the relational model. Absolutely nothing. The relational model is so solid and so robust..."

"The key notion underlying The Manifesto is thus the equation: domain = object class. A domain, or an object class, is a data type that is encapsulated, which means that the only way you can operate on values of that type is through operators that are defined for the type. You don't actually see the way the data is represented. That's not relevant. You only know that there are certain functions you can perform. It might be a primitive system-defined data type. More generally, it's going to be a user-defined data type. The values of these data types can be arbitrarily complex."

"The values in row and column slots can then be anything you like. They can be simple integers. They can be strings. They can be arrays. They can be books. They can be engineering drawings. They can be videos... They can be anything you like - as long as you can define the data type. In fact, I believe do one of the reasons we're hearing so much hype about object-oriented is because of a failure on the part of the relational vendors to step up to the mark. They haven't supported the relational model. If they had, we wouldn't be having these silly arguments now."

"In my opinion, there are precisely two good ideas. One is the data type concept - user-defined data use of arbitrary complexity, with encapsulation and user-defined functions. The other is inheritance. For example, in a geometric database you might have an object class called polygons, and one called rectangles, where rectangles are a subclass of polygons because every rectangle is a polygon. Therefore it follows that everything that works for polygons automatically works for rectangles too."

"If under the covers, the representation changes - if polygons are represented by a sequence of points for the vertices, and rectangles are represented by just the bottom left and the top right corner or something like that - the code to implement the operator has to change too, but that's implementation. From the model's point of view, if you have a function called area that returns the area of a polygon, automatically it means that you can invoke the area function on a rectangle and get the right answer. Under the covers, it may be desirable to reimplement that function. I don't care. That's implementation."

At War with Ourselves

I read this a while ago but it seems somewhat relevant recently.

The Vietnam of Computer Science "Although it may seem trite to say it, Object/Relational Mapping is the Vietnam of Computer Science. It represents a quagmire which starts well, gets more complicated as time passes, and before long entraps its users in a commitment that has no clear demarcation point, no clear win conditions, and no clear exit strategy."

Solutions:
"Developers simply give up on objects entirely, and return to a programming model that doesn't create the object/relational impedance mismatch. While distasteful, in certain scenarios an object-oriented approach creates more overhead than it saves, and the ROI simply isn't there to justify the cost of creating a rich domain model. ([Fowler] talks about this to some depth.)"

Fowler's piece I believe is, "GetterEradicator" which links to "Tell, Don't Ask", which makes an important point about Design by Contract, "According to Design by Contract, as long as your methods (queries and commands) can be freely intermixed, and there is no way to violate the class invariant by doing so, then you are ok. But while you are maintaining the class invariant, you may have also dramatically increased the coupling between the caller and the callee depending on how much state you have exposed."

"Developers simply give up on relational storage entirely, and use a storage model that fits the way their languages of choice look at the world."

"Developers simply accept that it's not such a hard problem to solve manually after all, and write straight relational-access code to return relations to the language, access the tuples, and populate objects as necessary."

"Developers simply accept that there is no way to efficiently and easily close the loop on the O/R mismatch, and use an O/R-M to solve 80% (or 50% or 95%, or whatever percentage seems appropriate)..."

"Developers simply accept that this is a problem that should be solved by the language, not by a library or framework...bring relational concepts (which, at heart, are set-based) into mainstream programming languages, making it easier to bridge the gap between "sets" and "objects". Work in this space has thus far been limited, constrained mostly to research projects and/or "fringe" languages, but several interesting efforts are gaining visibility within the community, such as functional/object hybrid languages like Scala or F#, as well as direct integration into traditional O-O languages, such as the LINQ project from Microsoft for C# and Visual Basic. One such effort that failed, unfortunately, was the SQL/J strategy; even there, the approach was limited, not seeking to incorporate sets into Java, but simply allow for embedded SQL calls to be preprocessed and translated into JDBC code by a translator."

"Developers simply accept that this problem is solvable, but only with a change of perspective. Instead of relying on language or library designers to solve this problem, developers take a different view of "objects" that is more relational in nature, building domain frameworks that are more directly built around relational constructs."

Purity

A couple of Artima posts, "Pure and Impure Functions" and "In Defense of Pattern Matching".

An I quote: "A pure function is one which has no side-effects and does not depend on any state beyond its local scope. This means that it can be replaced with any other pure function which returns the same result given the same input. This property is often referred to as referential transparency...some impure functions, can become pure when they are passed constant values."

"I think pattern matching is extremely convenient and is a good fit with object-oriented programming. I wonder why not more mainstream languages have adopted it."

Links to Scala. I was recently looking at Clean. And if you really want to, "Functional Programming in Java: More fun with Generics and CGLib" "They are Java instance methods which are pure-functional, that is, without side-effects, and do not reference any object fields or non-static variables. Essentially, they are non-mutating static functions declared without a static qualifier."

Revisiting Visitor

I was looking for another approach to implement parsing expressions and came across Visitors in JSR 269 and "The Expression Problem Revisited", "The expression problem (aka the extensibility problem) refers to a fundamental dilemma of programming: Can your application be structured in such a way that both the data model and the set of virtual operations over it can be extended without the need to modify existing code, without the need for code repetition and without runtime type errors."

"All proposals that we know of take as a starting point either a data-centered approach, making it hard to add new operations, or an operation-centered (visitor-based) approach, making it equally hard to add new data types."

"Despite its simplicity, this trick is one of the major contributions of this paper, because it finally moves the visitor-based approach to the expression problem into the realm of static type safety...[it] divides the node classes of the different phases into separate, incompatible families, each characterized, in the form of a type parameter, by the specific brand of Visitor they are capable of accepting."

To put it another way, this enables you to define what implementation of Visitor you wish to use when you construct your visitable classes (at compile time, not runtime) - a pretty neat trick.

Via, why Visitors?.

Update: I've started using these ideas in JRDF to implement the SPARQL query layer and see what practical benefits are.

Too Much Class

This is a paper that offers a potentially positive argument for smaller methods: Reengineering Analysis of Object-Oriented Systems via
Duplication Analysis "A manual approach to the reengineering has been compared against a tool-aided approach, highlighting the time saving (8 man days against 1 man month) and the amount of duplications undiscovered by the manual analysis. It has been stated that a tool for duplication detection can drastically reduce the time to identify the duplication in software systems at file, class and method level only if suitable metrics and duplication analysis support are available. On the other hand, the adoption of a tool only at file level does not guarantee a better identification with respect to what can be performed manually by an expert system engineer. The inspection at class and method levels reduces the time to perform the analysis and allows identifying several activities to be performed during the code manipulation phase."

Good Design and Web Spreadsheets

I've been using Spring Rich Client recently and it made me think of what makes a good design pattern as I go and implement the MVC pattern.

So with object-oriented programming I have to say that the most benefit I've seen is the combination of data and behaviour which enables large parallel development. As Alan Kay has said on his history of Smalltalk, "..."doing OOP right" would be to handle the mechanics of invocations between modules without having to worry about the details of the modules themselves." This is what the naked objects guys call behavioural completeness. They quote Riel by saying: "'Keep related data and behaviour in one place.','Distribute system intelligence horizontally as uniformly as possible, that is, the top-level classes in a design should share the work uniformly.', 'Do not create god classes/objects in your system. Be very suspicious of a class whose name contains Driver, Manager, System or Subsystem.'"

As they also mention, the MVC pattern is frequently misunderstood and misused as the controllers "...take on the role of task-scripts, incorporating not only the optimized sequence of activities, but business rules also - thereby usurping what ought to be responsibilities of the core business objects." This is usually extended to MVCP (or Model-View-Controller-Peristence) where persistence is not hidden from the other layers.

So by taking this more procedural or subject-oriented view, clothing it in OOP and design patterns, it leads to an architecture that is brittle when subjected to change. This approach has been proven to be less able to adapt to changing business requirements than one that is behaviourally complete.

This also ties into the semantic web for object-oriented software developers where it says, "The key power of OWL is that classes can be defined by combining multiple restrictions and other classes. For that purpose, OWL provides logical operands to build intersections (and), unions (or) and complements (not) of other classes. For example, you could define "the class of all customers from France who have issued at least 3 purchase orders or at least one order consisting only of books, except those customers who have ordered a DVD". This is also an example of behaviour and data moving around together and being combined and types inferred - I don't see it as a contradiction between the two as long as you consider a dynamic typing system like Ruby or Java with AOP, reflection, proxies and annotations. I also see it as the killer application of things like Google's spreadsheet - in fact their spreadsheet is an almost ideal expression of this shared, global object that takes messages and performs operations.

As an aside, I went searching for where I first read about the "Design Patterns" book and it was from a review by Tal Cohen who said: "The concept of design patterns was first discussed by Christopher Alexander, an architect, back in 1977. If someone from the software industry would have considered Alexander's' words back then, perhaps the first book about design patterns in software would have dealt with patterns in FORTRAN programs. As it happens, software design patterns were first discussed in this era, when most software design is object-oriented in nature." And recently, although I don't have access to read it, someone has applied design patterns to Fortran 90/95 (might be as interesting as Object Oriented Javascript).

RDFHibernate

Re: How will the semantic web emerge - OO languages:

"> For certain ontologies, java beans are a reasonable model. For
> others, though, with extremely flexible type systems, involving
> type relations outside those that map directly onto the java type
> system, its not so clear. Say it were possible for some instance to
> be a foaf:Person from one ontology and a deo:God from another
> ontology and a comic:Superhero from yet another, and there were no
> subclass relationships among these. Heck, perhaps deo:God and
> comic:Superhero both subclass from et:Nonhuman . While this isn't
> absurd by any means, it does make denoting the instance's type in a
> java bean complicated at best (I anticipate lots of interfaces ;-) ).

yes. My RDFHibernate library [1] works with interfaces that map onto
an RDF database using dynamic proxies."

It's listed under Java Distributed Data Acquisition and Control but does not seem available - except for the Subversion repository.

Henry Story just announced a new project which also has Hibernate overtones, Sommer "Sommer is a very simple library for mapping Plain Old Java Objects (POJOs) to RDF graphs and back. Sommer stands for Semantic Object (Metadata) Mapper. In German it also means "summer", the season opposite to winter, when animals no longer hibernate. In French a "somme" is both the sum of things as well as a little rest."

The New OO

So now that Ruby is officially the next new thing it's time for the next level of books. Bruce Tate's From Java to Ruby or From Java To Ruby "Java to Ruby is packed with interviews of Ruby customers and developers, so you can see what types of projects are likely to succeed, and which ones are likely to fail. Ruby and Rails may be the answer, but first, you need to be sure you're asking the right question. By addressing risk and fitness of purpose, Java to Ruby makes sure you're asking the right questions first."

Protected is Evil

I thought I'd blogged about this before but apparently not.

So I'm a fan of both Alan Holub's articles about "Getters and Setters being Evil" and "Why extends is evil". These articles reminded me of an early book by Peter Coad called, "Java Design: Building Better Apps and Applets" which introduced this idea of composition over inheritance. Certainly a predecessor to the whole IoC bandwagon.

In fact, re-reading Holub's article it's interesting in the summary he writes: "As much as 80 percent of your code should be written entirely in terms of interfaces, not concrete base classes. The Gang of Four Design Patterns book, in fact, is largely about how to replace implementation inheritance with interface inheritance."

Likewise, Arthur Riel's, "Object-Oriented Design Heuristics" doesn't ban inheritance but offers the few cases where it is should be used.

Tony Morris (a fellow mouse) has written, "Why extends is not evil". Where he talks about interface inheritance and makes a pretty good point: "The only keyword that is exclusively associated with concrete inheritance is the protected keyword. The use of this keyword should be avoided indiscriminately."

RDF on Rails

While searching for Ruby APIs for RDF I came across: ActiveRDF: object-oriented RDF in Ruby "Although most developers are object-oriented, programming RDF is triple-oriented. Bridging this gap, by developing a truly object-oriented API that uses domain terminology, is not straightforward, because of the dynamic and semi-structured nature of RDF and the open-world semantics of RDF Schema.

We present ActiveRDF, our object-oriented library for accessing RDF data. ActiveRDF is completely dynamic, offers full manipulation and querying of RDF data, does not rely on a schema and can be used against different data-stores. In addition, the integration with the popular Rails framework enables very easy development of Semantic Web applications."

"The development of such APIs has been attempted using a statically-typed language (Java) in RdfReactor, Elmo and Jastor. These approaches ignore the flexible and semi-structured nature of RDF data and instead:
1. assume the existence of a schema, because they rely on the RDF Schema to generate corresponding classes,
2. assume the stability of the schema, because they require manual regeneration and recompilation if the schema changes and
3. assume the conformance of RDF data to such a schema, because they do not allow objects with different structure than their class definition.

Unfortunately, these three assumptions are generally wrong, and severely restrict the usage of RDF. A dynamic scripting language on the other hand is very well suited for exposing RDF data and allows us to address the above issues."

The homepage: ActiveRDF. Uses YARS and Redland.

Recent related W3C note: "A Semantic Web Primer for Object-Oriented Software Developers".

Related previous posting: "Scripting the Semantic Web".

Update: It looks like Henry Story noticed ActiveRDF as a good idea too.

Update 2: Brian Gilman recent posting to the Life Science list links to the BioRuby project.

Links

• On setters, constructors and modelling reality "In my experience there are almost no situations where a setter method is a good idea...I often see setters used where information relating to an object is not known at construction time, and needs to be added later. This is usually a symptom of choosing the wrong class to store that data...Note that just because all the fields are final and there are no setters, this doesn't mean that the object is immutable. It just means that its behaviour more closely models reality, and your interactions with it will be far more meaningful."


• ABC Video On Demand including all your Chaser needs.


• Agile Development: Schema Evolution "One of the characteristics of agile development is that designs are often refactored. As result, the data model may evolve during the lifetime of a project. What happens if the data model of the db4o databases is changed?"


• Smalltalk to Java - the Good, the Bad, and the Unbelievably Ugly "The Smalltalk code was "too Smalltalky" for the translation (again, design is language specific IMHO). They had DNU handlers, descendants from nil, #perform, etc. Then there's the whole utility class issue - final classes in Java (String, Date) that would simply be subclassed in Smalltalk. Joshua Bloch, call your office :/"


• Running Code Doesn't Lie "This statement pretty much sums up why agile software development practices like eXtreme Programming and Getting Real are so powerful. Instead of business analysts or programmers writing pages of documentation for what they think the system does, the system tells you what it does. I like to call this a Self Describing System."


• TestDox "TestDox creates simple documentation from the method names in JUnit test cases."


• Multi-core Processors: transputers reborn "
  In the Eighties, there were only a small number of people who were interested in fast drawing of Mandelbrot sets. The same is true today. But today, everyone is interested in having their web sites scale well in terms of performance and in terms of price. The killer application of parallel computing is all around us. It is called the Web."

I Object

A response to some points in, The perils of avoiding heresy (or "What are Design Patterns") and Visitor Pattern and Trees Considered Harmful.

""21 reasons C++ sucks; 1 embarassment; and an Abstract Syntax Tree"...So if the book is predominately a catalogue of unfortunately necessary kludges around the semantic weaknesses of mainstream OO-languages, why do I still highly recommend it to new programmers?"

Design patterns are not reliant on OO, Java, C++ or any particular language or programming paradigm. It's not even reliant on Computer Science. The source of design patterns comes from architecture (Christopher Alexander) and is used in diverse areas such as dating. Grady Booch's Handbook lists 1000s of patterns, so many reasons OO-languages suck.

"Singleton. This is a global variable."

So variables and objects are not the same thing - variables lack behaviour (amongst other things). The Singleton pattern as implemented by IoC containers like Spring, Yan, PicoContainer all use Singleton as configuration on a plain Java object - so again it's not necessarily a concept in code at all.

"In a language with first-class constructors, the Factory Method Pattern consists of factory = MyClass.constructor"

This just shows a misunderstanding of the the Factory pattern - its intention is to decouple object instantiation, especially at runtime. In languages that have first-class constructors, like Ruby, you still use the Factory pattern.

An interesting discussion, Factory and Singleton are false Design Patterns?.

So the old chestnut, the visitor. "The visitor pattern is kludge used by programmers in a language that doesn't support multiple-dispatch to provide themselves with a static version of double-dispatch."

This I agree with. But the rest seems simply a rant against OO.

So Wikipedia says, "...visitor design pattern is a way of separating an algorithm from an object structure. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures."

So there's no need for multiple if-then-elses or case statements which is what happened in Python as there is no switch statement.

The Visitor pattern is not the ultimate answer to writing a compiler. It's very straight-forward for small languages, simple languages, languages where you might find changing the code and the syntax independently, etc. Having written a C compiler using SableCC I have seen the issue of breaking encapsulation - in fact most compiler implementations I've seen tend to create global state of one sort or another anyway.

The main issue with compiler compilers that I tried before SableCC (which uses the Visitor pattern) is the combination of grammar and Java code. I have similar problems with PL/SQL, JSPs, etc. This combination is also detrimental to tools like debuggers, IDEs etc. (the work that goes into JSP support in IDEs is a good example of how hard it is).

I can't think of a successful combination of the two styles, declarative and imperitive. To me it seems to always end in very poor, unmaintainable code. And through the eyes of a lemming it's much poorer than sticking within the OO paradigm.

A better article is, Translators Should Use Tree Grammars. At the end of article the author writes, "...aspect-oriented specifications as long as we are thinking about putting actions outside of the grammar. Action execution is just an aspect and each phase would be an aspect." which seems very similar to the way things like transactions and context have been implemented in Spring. It might well be that combining AOP and OOP will provide a clean solution to writing compilers.

Objectifying the Web

REST versus Object-Orientation (and a little python) "From my perspective, the concepts of Object Orientation (OO) and REST are comparable. They both seek to identify "things" that correspond to something you can about and interact with as a unit. In OO we call it an object. In REST we call it a resource. Both OO and REST allow some form of abstraction. You can replace one object with another of the same class or of the same type without changing how client code interacts with the object. The type is a common abstraction that represents any suitable object equally well."

REST and Object Orientation via OWL "So the most important aspect of RESTful programming as Benjamin points out is that now all objects are universally nameable and universally accessible. A few simple verbs allow us to create, delete and change the state of these resources. Access Control Lists allow fine tuning of responsibilities for a resource. And OWL gives us the Object Oriented conceptual structure to predict and understand the content of these resources and how they relate to others."

People seem to forget that method calls in Java or whatever can be considered message passing. What could be more OO than REST? GET isn't analogous to "getFoo" or "getBar" on a JavaBean object. The semantics behind GET/POST/PUT/DELETE is better thought of as how you are changing the object (related to Create Retrieve Update Delete (CRUD)). What could be more RESTful than OO?

The Dining Philosophers in REST "...it's trivial to encapsulate transactions into a single atomic exchange, and exposing those encapsulations as first class entities is generally a pretty good idea. And it certainly fits with the REST model of the world. MUCH more so, in fact, than RPC, as it forces one to aggregate those operations in the server design rather than leaving it open to the client to abuse. In fact, I'd even say that doing so is critical to the ability to build workable distributed systems."

Also related "Using RDF to improve Object-First Development".