RE: Can someone recap the differences between @serviceGroup vs. definitions-targetNamespace ?

Bijan:

> I don't think you should :) I *think* targetResource encourages you 
> too. Certainly the service description author ought to. And 
> if it's in 
> the WSDL, it seems like the service consumer *should*, at 
> least some of 
> the time, at least want to care :)

I think I agree with this - if you're saying I shouldn't care, that is.

> > I call getPrinterInfo(...) and I get info
> > based on the token I passd.
> 
> Whoops. getPrinterInfo has no parameters. So, callit 
> getPrinterFooInfo(). That way, PRINTADM does have a definite 
> printer it 
> targets.

Well in that case, aren't you just saying that you implicitly pass the
parameter because it's encoded in the targetResource? If so I could argue
that a "PrinterContext" would work just as well - and that could easily be
shared amongst parties that are interested in a particular printer, not
arbitrarily as a targetResource advertises.

> >  I call notifyPrinterRepairPersonOfProblem(...)
> > and someone goes out and examines some hardware somewhere 
> based on the
> > token
> > I passed.
> 
> Only thing you pass here is the problem description.

I don't get this bit. Could you elaborate?

> The question is, as I understand it, imagine you have 40 
> printers, all 
> web/web services ready. Each has a pair of WSDL files with operations 
> hardcoded for their specific printer. How do you relate the two files 
> corresponding to each printer?

I don't see this in terms of files. I see this in terms of a single service
implementing a number of interfaces. If I understand the service I can use
it (providing I am authorised to etc). If I don't understand the interface
then tough. 

> (There has to be a better description for the problem.)

:-) I think this one is simple enough so we don't trip over the problem
domain.

> >> Is this sort of grouping uncommon? Unlikely?
> >
> > I suspect grouping of related methods to be quite common,
> 
> E.g., A Service! :)
> 
> >  and I suspect that
> > related interfaces will be grouped too.
> 
> In this particular targetResourcey way? Or in various sorts of groups?

Various kinds of groups that I would call interfaces in "normal"
component-based programming. 

> >  That's why multiple interfaces per
> > service was nice - it gave you the normal "print" interface and the 
> > "management" interface at the same endpoint.
> 
> Well, and it can give you completely unrelated interfaces (say, the 
> "print" and the "post to my weblog" interfaces).

Yes, but that is an service designer's choice. I think exposing back-end
resources - breaking encapsulation - is too high a price to pay for the
luxury of believing that all coders are idiots (which would make my life
easier as a coder for sure).

> It might well be, but it doesn't have to be. I guess the 
> point would be 
> is that you might want to know that these two interfaces talk to the 
> same printer? You keep starting from the pov of *knowing*. So I have 
> one of the WSDL files, how do I (automatically?) tell that 
> the other is 
> relevantly similar?

You know because this is your application. You submit a job to the printer
service, and perhaps you explicitly pass the name of the printer, or perhaps
you have a printer context which identifies the printer. Either way you
don't violate encapsulation, and you assume that every time you pass the
token (or context containing the token) "ColourPrinter1" that is pops out of
the same printer.

> I think someone like Jeff would argue that this is too arbitrary or 
> tedious compared to just comparing targetResources. If the case is 
> common enough, the a little extra support *doesn't* seem unreasonable.

I'll let Jeff argue that - but I'd contend that it's no harder seeing if a
printer name is part of an XML Schema enumeration than comparing a
targetResource value. And (again) I don't break encapsulation.

> > Or rethink both if necessary. Does it make sense to expose the
> > resources
> > from one administrative domain to another (which is how 
> duffers like 
> > me are
> > bound to abuse targetResouce)?
> 
> I worry strongly about this ;)

We shouldn't let dogma be a barrier to getting this right though. 

> I mean, is a Service supposed to be more like an object or a library, 
> with the intuition that methods associated with an object are 
> primarily 
> concerned with manipulating the state of that object (or the state of 
> other objects access through my home object). This doesn't really get 
> strong semantic coherence, but ok, we can explain this. With 
> a library, 
> I'm just grouping a bunch of functions in a convenient package.

I think neither. It's a component - more coarse grained than an object and
might support a number of interfaces onto the same underlying machinery.

> You could, but that semantics was entirely extra-WSDL. See: 
> http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_services
>
> You get to see multiple ports of the same portType as semantically 
> equivalent, but that doesn't entail that the operations therein 
> manipulate the same components (imagine a grab bag utility library 
> which has a Pascal and a C implementation). Multiple portTypes don't, 
> themselves, have any suggested relationship, it's just noted 
> that it's 
> handy when they *are* related in certain ways.

Absolutely right. The portTypes contained within a service might do things
that are totally unrelated at the back end. If so, that's probably a poorly
designed service. Nonetheless, given that I don't have any visibility into
the back end of the service, I can't see this bad design in action anyway.

> If we kept multiple interfaces, we'd have the same problem. One thing 
> for targetResource, it does seem intended to address this gap. One 
> thing for serviceGroup, its intended to make this gap explicit, and 
> provide a hook for filling it in an flexible way.

Then I suggest an alternate solution - contextualise your interactions.
Using the context, the reciepient service(s) can relate disparate
invocations, and possibly even route them to the same back-end resource.
This is more flexible than targetResource since it allows shared context
across multiple services. However, I don't think this is part of WSDL (does
this mean that by implication neither should be targetResouce?).

Jim

Received on Tuesday, 15 July 2003 09:43:54 UTC