Good catch.
I need something like this for WSDL processing as well so I will go
ahead and add the objects as described below into the config model.
--
Jeremy
On Aug 12, 2006, at 10:34 AM, Raymond Feng wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
