Hi,
The ServiceContract abstraction sounds good to me. One comment:
For the Operation, I thin we need to add a list of fault types.
List<DataType<?,?>> faultTypes;
Thanks,
Raymond
----- Original Message -----
From: "Jeremy Boynes" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Wednesday, August 09, 2006 10:50 PM
Subject: Re: Refactoring of Service Contracts
On Aug 9, 2006, at 8:16 PM, Jim Marino wrote:
Another issue that has come up is representation of data binding
types for parameters. We could perhaps have a generic
representation of an operation, Operation, that has a
getParameterTypes() which returns a collection of Class elements.
The actual class elements would correspond to type system of the
specific data binding used.
I was chatting with Raymond at OSCON about metadata for the data
binding framework and I think that is relevant here. We talked about
representing the data being bound using three pieces of information:
* the physical Java class in use in the runtime
* a logical identifier for the data type
* metadata defining the association between the two
The physical class is Java because the runtime is written in Java so
we need to pass around Java Objects. In terms of data binding this
would be the Class of the actual object that was passed to the
binding framework. This may be a user supplied Object, but may also
be some other representation of it such as a DataObject, a Document,
an XMLStreamReader or an InputStream.
The logical identifier is used to describe the data that is
represented by the physical object. If the type scheme is "Java" then
this would be the same Class as that used for the physical type. For
XML type schemes this would be something like the QName of the type.
This is used so that we know the type of object the user is passing
even when that is not apparent from the physical form - for example,
it would provide information about what ca be read from a stream.
The metadata adds more information about the object that can provide
hints about the format that would factor into the binding frameworks
choice of technology. For example, it may provide the size on a
stream which might be used by the framework to decide between a
technology that would pull the stream content into memory for random
access vs. one that would keep it on the stream or spool it to disk.
It may also provide user hints - for example, that although the user
had specified an actual Java interface for the physical object they
also wanted the implementation to be cross-castable to DataObject.
I think this ties into the service contract as this metadata should
be used to represent the parameters to the operation rather than a
simple collection of Class elements. Something like:
class DataType<P, L> {
Class<P> physical;
L logical;
Map<String, Object> metadata;
}
class Operation {
String name;
DataType<?,?> returnType;
List<DataType<?,?>> parameterTypes;
boolean nonBlocking;
}
class ServiceContract {
Class<?> interfaceClass; // optional, used if there is an actual
interface for this contract
Class<?> callbackClass; // optional, used if there is an actual
interface for the callback
List<Operation> operations;
List<Operation> callbackOperations;
}
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
