- From: Sergey Beryozkin <sberyozkin@zandar.com>
- Date: Sun, 22 Jun 2003 14:33:03 +0100
- To: "Sergey Beryozkin" <sberyozkin@zandar.com>, "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <www-ws-desc@w3.org>
Hello, I'm replying to myself :-) Sanjiva Weerawarana wrote : > One can of course define a printer service in which every > operation takes the printer as an argument. In that case one > wouldn't need different services .. the printer is part of > the input. >There are different ways of defining interfaces obviously. This >is nothing new from WSDL - this is the way with any language. I've just read it again. And I think a message from the above is that it's all about deciding how one wants to allow customers to print on a number of printers and manage those printers. Target resource attribute is an *optional* one, and as such it gives one way to provide the solution, but does not enforce it, no more no less. There're might be alternative ways to do the same, but it's all up to a service designer as to which approach to choose. For example, taking a printer and printerManager scenario as an example, one should answer the questions like when thinking of using @targetResource: Do clients care what printer to print upon ? Why do they want to print on a specific printer ? Is is because it's the closest one, but not because it's an HP prinetr ? How do they find out that this printer is the closest one ? Through a communication, perhaps ? So what happens then when PrinterA gets moved from a second floor to another one, and PrinterB takes its place instead ? No problems when @targetResource just identifies a printer on a second floor, and if all I want because the second floor is the closest location, it can become a problem if I chose the closest printer with an advanced feature (which happened to be printerA), but PrinterB does not have that feature. So, it's all about building the best solution. If @targetResource helps to do it, then it's fine, if not, well then, it's just an option. Thank you Sergey Beryozkin P.S. By the way, please ignore what I said in the fragment below, the code is probably incorrect... > What is interesting in this case is that instead of writing something like > this : > PrintService.print() > PrintManager.cancel() > > I'd write something like this : > > PrintJob job = PrintService.print() > job.cancel(job.id)
Received on Sunday, 22 June 2003 09:34:23 UTC