Java design issue: Preparing for future extensions/versions...

[Casper B]

"Program to Interfaces, not Implementations " we've all heard, however I
now identified a scenario where this idiom can not be used (I think) and
is searching for another approach.

I have a method exposed as a webservice (JAX-RPC) which specifies that
the pass/return types must adhere to primitive types, beans and/or arrys
of these.

My application is supplying an argument in the form of an ArchiveItem
instance when calling the webservice:

// Argument bean
class BookItem
{
String Title;
String Publisher;
}

// Calling webservice
...lookup( ArchiveItem );

However, what if I wanted to plan ahead, knowing that probably soon I
will have to add another customer who wish to search by another field,
say Author. At the same time, I wish to let the existing customers use
their existing code and call the now "deprecated versions". By
implementation enheritance I could:

// Argument bean
class BookItemAdvance d extends BookItem
{
String Author;
}

// Calling webservice
lookup( ArchiveItemAdva nced );

This would solve the problem, but it requires implementing a new
(overloaded) webservice and introducing a potentially large versioned
hiarachy (Next extension would be BookItemSuperAd vanced...).

Is there a smarter way from a design perspective that does not simply
pass an interface; I am unable to pass/return interfaces over
WebServices pressumely because of serializabilty issues.

Thanks in advance,
Casper