Talk:SMILA/Component Requirements/Record Binary Storage Requirements

Tom: I wouldnt use the smila specific 'record' and 'attachment' name parts because in/out arguments are generic.

Juergen.schumacher.empolis.com Yes, indeed. There is nothing record-specific in the arguments so we do not need to talk about records and attachments. But I wonder if it would make sense to add another parameter to be able to ensure that different clients that use BinStorage for difference purposes do not have ID collisions. Otherwise one client would overwrite the BLOB of another client by accidentally using the same ID. So we could have:

Igor.novakovic.empolis.com Well if you take a closer look at the page name, you'll see that page actually defines the _record_ binary storage requirements ;-) So here we are talking about the record-centric binary storage. The reason why I proposed to "tie" this concept to record is quite simple: We have to take care that our project concepts are not only technically sophisticated but also "user friendly" and easy to understand. IMO this can be achived by:

1. Having a simple story behind SMILA: SMILA operates on (un)structured data. This data is internally encapsulated in Objects that we call records. The Records are passed from one service to another and can themselves contain (very) large amount of information (e.g. one record can represent the whole book). To be able to swiftly share this information between BPEL services we introduced the blackboard service which is actually the only client to low-level services like record binary and XML storage.
2. Having self-explaining method names.
3. Avoiding the "generic bug". By introducing services that are too general (i.e. can serve multiple different clients) you can confuse the person that is using them and also make them harder to implement than really needed.

void store(String namespace, String id, InputStream stream);
void store(String namespace, String id, byte[] blob)
byte[] fetchAsByte(String namespace, String id)
InputStream fetchAsStream(String namespace, String id)
void remove(String namespace, String id)
int fetchSize(String namespace, String id)

Igor.novakovic.empolis.com IMO there is no need to introduce namespace since we in fact only have one client - the blackboard service.

Alternatively we could require that IDs are not unstructured strings but something like "URIs" (maybe even javax.xml.namespace.QName instead of java.lang.String?)

Igor.novakovic.empolis.com I would leave (like in current implementation) IDs being generated by the blackboard service as strings that are calculated like this id = hash(record.id + attachmentName)

Tom:

> namespace parameter

I had that different in mind, namely when requesting the service, the client would pass in that info. that way we could have diff. BinStoreService instances and the client wouldnt have to pass in that info each time.

Igor.novakovic.empolis.com Here we have it - the "generic bug". Not only that the client needs to know which particular implementation of the binary storage he wants to contact to, but he also needs to know which instance has been properly configured for him.

> 6. The client component must use different instances of the binary store fully transparently

@Igor: could you make this requirement more precise?

Igor.novakovic.empolis.com This means, that the client must not know anything about the implementation details of the the record binary storage service (e.g. if binary storage stores data in a file system or into a DB).

Juergen.schumacher.empolis.com Ok. I suppose, creating one BinStorage service per "namespace" would be fine, too. So the API could be:

void store(String id, InputStream stream);
void store(String id, byte[] blob)
byte[] fetchAsByte(String id)
InputStream fetchAsStream(String id)
void remove(String id)
int fetchSize(String id)