Sasan,
WSDL is not an abstract contract. It specifies the concrete formats
and protocols used to interface with the service. The data format of a
WSDL contract is expressed as XML Schema. A WSDL would never expose a
contract that looks like:
public int method(java.util.List objects)
because a WSDL never exposes a Java interface.
I gather from the way you ask the question that you are using the
code-first development model, and you are asking your SOAP framework
to generate a WSDL contract from your code.
So first, using a code-first development model is a bad practice
because it invariably leaks implementation-specific information into
your supposedly platform-independent service. (Unless you have no
intention to support non-Java clients.)
Second, your SOAP framework will almost certainly map your List to an
xsd:Any or an array of items of type xsd:anyType. In other words, you
would have an unspecified contract, and users of your service would
have to negotiate with you out-of-band to determine what data formats
your service expects and/or accepts. And as you say, nothing about
xsd:Any or xsd:anyType conveys any information whatsoever that the
service expects the input to conform to JavaBean conventions. Those
conventions are completely lost in the translation.
As a general rule, requiring out-of-band negotiation of data formats
is a bad practice when using SOAP. The whole point of using SOAP is to
enable automatic generation of client and server stubs which
automatically serialize and deserialize objects to XML and XML to
objects. If you don't intend to take advantage of automatic
serialization, I question why you chose to use SOAP in the first
place. Try JMS, RMI, Jini, or some other Java-specific communication
protocol that understands the Java interface.
Anne
On Mon, Aug 24, 2009 at 9:36 AM, Sasan<[email protected]> wrote:
>
>
> I'm sorry that I have to talk technology oriented. In this particular case
> the client only has access to abstract contract i.e WSDL. So if list
> includes the type i.e. List<SomeType>, it is possible to identify the
> content structure of "SomeType" but it seems to be very risky because based
> on some prototypes, some of the content might not be discovered if
> "SomeType" do not fully comply with a java bean convention (having
> getter/setter for all attributes). this is only for dynamic access to
> services
>
> Sasan
>
> ________________________________
> From: Michael Poulin <[email protected]>
> To: [email protected]
> Sent: Monday, August 24, 2009 12:49:21 PM
> Subject: Re: [service-orientated-architecture] Re: good or bad practice? or
> maybe ugly
>
>
>
> Oh, this "an intermediary" ... In this case, Hitoshi-san, what the consumer
> knows about the service interface - is it with a List or with a non-List? If
> it is with the List - problem not only stays but gets worth; if the consumer
> gets a non-List, do you wan the intermediary be so smart to know what
> transformations are needed for each consumer (assuming that service
> interface is with List)? I do not even talk about Service Contract where all
> service interfaces must be agreed with the consumer (and the intermediary
> is invisible; we talked about it already in this Forum). What the purpose of
> having List on the sender side while receivers need have non-Lists?
>
> - Michael
>
> ________________________________
> From: Hitoshi Ozawa <htshoz...@gmail. com>
> To: service-orientated- architecture@ yahoogroups. com
> Sent: Sunday, August 23, 2009 11:23:06 PM
> Subject: Re: [service-orientated -architecture] Re: good or bad practice? or
> maybe ugly
>
>
>
> Hi,
>
> On a local call, using List with TypeOf can be used. List is just a
> handy way to allow different subclasses of List to be passed.
> When using on a network interface, more consideration is necessary. It
> is possible to predefine elements in a List both at both ends but this
> doesn't make too much sense because it defeats the meaning of using
> List. What is possible is to predefine a structure so it will contain
> both the definition and the data. In this case, you'll actually be
> extending the interface standard, which means you shouldn't be using
> it for a public service. It's, nevertheless, is convenient when
> creating a 1 supplier to N consumer format with a List being used
> between a supplier and an intermediary and an intermediary converting
> the List to a non-List's. :-)
>
> H.Ozawa
>
> 2009/8/22 Gregg Wonderly <[email protected]>:
>>
>>
>> In this particular case with Java, the interface can include generic type
>> references on the List to control the types of things sent to it.
>>
>> public int method(List< DataObject> lis)
>>
>> helps software developers know exactly what kind of list should be passed.
>> A
>> List is not any worse than a XML document or a stream of some other
>> structure
>> values. It is important to understand that exporting "DataObject" in the
>> interface definition does create a type base dependency that you have to
>> be
>> ready to manage the life cycle of.
>>
>> Gregg Wonderly
>>
>> jesseezell wrote:
>>>
>>>
>>> Best practice with service interfaces is to pass messages that have been
>>> specifically crafted to contain information about the requested
>>> operation, not lists of objects. Any interface where you are basically
>>> just taking a call that could have been a local method call and exposing
>>> it over the wire may be a web service, but that doesn't mean it's
>>> service oriented. It is often a good idea not even to use objects from
>>> your domain model directly, because you want your service interface to
>>> be stable.
>>>
>>> --- In service-orientated- architecture@ yahoogroups. com
>>> <mailto:service- orientated- architecture% 40yahoogroups. com>, Sasan
>>> <sasanp...@. ..> wrote:
>>> >
>>> > Hi,
>>> >
>>> > Is it good practice to have a service that exposes a method with a
>>> List of objects as a parameter? Programmatically speaking from Java
>>> programming point of view java.util.List.
>>> >
>>> > Example:
>>> >
>>> > public int method(java. util.List objects)
>>> >
>>> > Even if the interface is documented, I do not see this as a good
>>> practice cause this tells me the method takes a list of basically any
>>> object type. This could be troublesome for clients that discover
>>> services dynamically.
>>> >
>>> > I appreciate all opinions on this.
>>> >
>>> > Thanks,
>>> > Sasan
>>> >
>>>
>>>
>>
>>
>
>
