I think the question is why you'll want to provide consumers with dynamic interfaces using WSDL because each consumers would have to write a custom interface adapters. Do you want to use the WS-* stack without having the limitation imposed by static WSDL?
H.Ozawa 2009/8/25 Sasan <[email protected]>: > > > Anne, > > the question is not about bottom-up to top-down service implementation. this > is more about consuming services dynamically without knowing their used > types. I am trying to come up with a guideline for consumers that access > services dynamically. As I have mentioned before dealing with cusomized > types and even List of those types, or even a List by itself, leads to > confusion for consumers as what types of signature they are dealing with. > Having the service and generating wsdl here is only an example, the focus is > on consuming it. > > Sasan > > > ________________________________ > From: Anne Thomas Manes <[email protected]> > To: [email protected] > Sent: Monday, August 24, 2009 9:43:52 PM > Subject: Re: [service-orientated-architecture] Re: good or bad practice? or > maybe ugly > > > > 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-independen t 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<sasanp...@yahoo. com> 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 <m3pou...@yahoo. com> >> To: service-orientated- architecture@ yahoogroups. com >> 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 >>>> > >>>> >>>> >>> >>> >> >> > >
