On Tue, 2006-07-18 at 20:41, Gregg Wonderly wrote:
> Andrew S. Townley wrote:
> > On Mon, 2006-07-17 at 14:09, Harm Smit wrote:
> >>Absolutely. The lightbulb10.turnOn() formulation was merely given to
> >>set it off against lightbulb10.PUT(<state="on"/>) or something
> >>similar.
> >>In actual practice, the lightbulb and its services would be
> discovered
> >>dynamically.
> >
> > Ah. What threw me was the 'lightbulb10' part rather than turnOn vs.
> > PUT. I'm not sure that I would've characterized the REST approach
> via
> > the mechanism you did, but I get your point.
>
> I also think that it's important to note that lightbulb10 is really a
> virtual
> name in this example, not a written name in the software. It's a
> reference to
> an instance.
>
> I see some comments like Andrew's that make it seem that many may not
> always
> think about how software can use discovery techniques to arrive at an
> instance
> of a service rather than having hard coded knowledge.
Maybe this is just from years of looking at code and having arguments
about "appropriate" variable names, but my natural thought was that
somewhere there was also a reference to lightbulb00-09/0F which were
indicating specific instances. I'm not quite sure I understand your
comment, but I've certainly seen a large number of cases where
individual developers prefer the specific reference to *this service
right here -->* vs. using the abstraction techniques you are
discussing--including a recent minor production environment outage I
heard about.
>
> for( Light l : getLights() ) {
> l.turnOn();
> }
>
> getLights() is the discovery piece. It might hardcode the instances,
> it might
> use Jini lookup, UDDI, a CORBA ORB etc. The enumeration of the choices
> and how
> that is abstracted is part of the software system design.
I agree with you that it's part of software system design, but I
wouldn't have had the same initial reaction from the above code.
Another reason I wanted to stress the point is that most code generation
tools also err on the side of specific bindings vs. looser coupling
because it's easier to implement. To most people, using code-generation
tools is implementation vs. design, so the design part can easily be
lost.
Was just trying to help people avoid shooting themselves in the foot. :)
ast
***************************************************************************************************
The information in this email is confidential and may be legally privileged
Access to this email by anyone other than the intended addressee is
unauthorized. If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken or
omitted to be taken in reliance on it is prohibited and may be unlawful. If you
are not the intended recipient, please reply to or forward a copy of this
message to the sender and delete the message, any attachments, and any copies
thereof from your system.
***************************************************************************************************
------------------------ Yahoo! Groups Sponsor --------------------~-->
Check out the new improvements in Yahoo! Groups email.
http://us.click.yahoo.com/6pRQfA/fOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
