William Henry wrote:
> On the other hand, as you point out having a specific interface
> operation for every product in your store is not practical or useful
> either. Your "2" below is much more practical interface than "1" -
> which is too cheesy ;-) Especially considering that it's probably more
> like:
>
> buyItem (ProductCode)
>
> Consider Amazon.com. You can be sure that there is not a
> placeItemTypeInCart for every subcategory of ItemType - i.e.
This is an important point. As I mentioned in my previous response, the use of
a general interface of buyItem(), instead of buyCheddarCheese(), has its
merits.
As a general service inteface, it makes sense where the products are wide and
varying. But for classifications of items, there use of more specific types
can
actually simplify your client designs and reduce the exposure of certain
characteristics of your actual service interfaces.
I've used a general service interface with mutiple virtual service definitions
via mobile code to allow the implementation details to change more fluidly when
I had well defined client needs.
> This is the problem with taking some of the OO type concepts into the
> SOA world. We saw this and the earlier everything-is-a-string type
> approaches in CORBA and I'm sure J2EE. Successful CORBA application
> implementations were more than likely SOA based (and one could argue
> even when they were embedded). And this is back to Ron Schmiezer's
> point which I'll express slightly differently: you can't should not, as
> much as possible let your implementation influence your SOA. Now
> sometimes it does because perhaps you're not starting from scratch and
> you are dealing with production code (aka legacy).
I think you have to be careful with such suggestions. In many cases, its more
likely that your implementation will restrict your SOA than extend its
capabilities. I think this should encourage you to say that your
implementation
should strive to empower your SOA, not restrict it.
> Amazon.com became popular because it was easy and often cheaper to
> purchase your books on-line through their service. The simple shopping
> cart made it an easy to use service - a "good service". There us of the
> www instead of some downloadable rich client with proprietary
> connection to their business meant that they used a scalable
> infrastructure.
William, your consistent theme of storefronts here is an interesting focus on a
particular type of "presense" to an SOA. I think its important to also decide
that multiple interfaces to your SOA should be part of the design. You might
decide that a general interface on the inner most service layer is good for
minimizing changes to that interface. But on the outside, you might need to
have a more focused interface layer that minimizes the exposure of your
implementation to the clients so that you can change it as needed.
My examples of using mobile code focus on how mobile code allows these kinds of
decisions to be made with little impact to existing clients. As a general SOA
issue, layers of abstraction that provide differing implementations seem to
create some arguments.
One of the issues you deal with, without mobile code, is the fact that you
might
have to create multiple services running on one or more machines. The
multi-layer execution path can greatly complicate the operations of your SOA,
introducing latencies and making multi-failure scenarios difficult to diagnose.
With the use of mobile code, you can push one or more of these layers to the
clients execution environment, while still maintaining a generic service
implementation on the service side. But, that's an implementation detail, not
a
public detail.
Related to your statement about downloading rich clients, the popularity of
AJAX
style web client interfaces demonstrates that there are things that are better
done on the client. The original Java applet implementation model was not rich
enough to maintain growth of the use of that model. Compatibility of
implementations created dependability problems.
There are currently many javascript issues that are just a return to the same
issues that Java experienced. Compatibility is not there. More specific
implementation requirements need to be spec'd, and more exacting
implementations
need to be created.
The standardizations of CSS and DHTML provide a place for javascript to plug
into document layout. Java applets had no such path, and the applet model was
never extended to include that level of access.
These are interesting times...
Gregg Wonderly
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/
