> > * What's the silliest use of web services you've seen thus far?
> Local invocation of web services.
In general, this tells me that the point of reusability for the service
is too high. If you have to consume a web service that you don't own,
then you're doing your best. But if you are providing a web service, you
should be using service oriented patterns such as session fa�ade and
service locator. Then the consumer of your web service, if they are
J2EE, can decide whether or not to hook in at the web services or EJB
level. If they aren't J2EE, then web services is probably the most
cost-effective option. It might be, regardless.
> > * Service Oriented Architecture (SOA): What do you think about it?
> For the most part I like it...it just its another tool in the bag..
Lets
> hype it a few years and see if the bosses like it. However, I dislike
the
> way its preached ("you'll never have to do architecture, human
> communication, or forethought again!"
SOA doesn't dismiss you from solving software architecture problems any
more than the concept of reusability or "goto statements considered
harmful" does. It's a guide to a problem. The problem is that you are
going to need to provide a new type of 'user' interface to your
functionality. The interface is going to be exposed on the network and
the 'user' is going to be a software application that you probably know
little about and that may not even be written yet.
SOA isn't a big leap for anyone that has written APIs, distributed or
not. But for those that develop with the screens-spaghetti code-database
model, it is.
> > In fact, I think
> > that a lot can be learned by looking at how databases are designed
and
> > how the database schema plays a crucial role for both technology and
> > business design. Your thoughts?
> >
>
> Boooo. Database-based application design sucks.
Ah, the object model vs. relational model debate, right? My current
thinking is that the way in which an app persists data can't be
abstracted away entirely and we do need to model both, but that's a
different discussion...
I think I'm trying to make a different point. There are some artifacts
out there, like ERDs or UML Activity Diagrams, which everyone on a team
understands. When I say everyone, I mean everyone -- developers,
managers, sales people, subject matter experts, etc.
These artifacts are highly accessible -- let's call them touchstone
artifacts. Touchstone artifacts matter because development isn't done
entirely by developers. Non-technical business people matter.
Web services needs touchstone artifacts if web services is going to be
used for true business-to-business integration on a wide scale. I'll
even argue that touchstone artifacts are more crucial because they are
being shared between different enterprises.
> Other books have said that web services adoption is top down where the
web
> was bottom up. This means the heavies (IBM, et al) are pushing this
> standard more than the users want it. Thus they're trying to create
> demand.
The vendors are known for pushing a vision that is then corrected by
customers. Over time, the practitioners lead the market if there is one.
All the vendors can do is to help seed it. For instance, the vendors
want to act like every enterprise is going to offer Google/Amazon-style
web services and that everyone is going to be using UDDI. But really,
how many enterprises are there that are going to be publishing truly
public web services? What I see happening is that web services are
popular for technology integration. As people become happy with the
underlying architecture, then you'll start seeing web services taking
over the EDI-space -- i.e., "We saved a nickel!!"
> > Thus, the best discussion we could have is "will (or, what part of)
web
> > services will matter 5 years from now and why?"
> >
>
> I dunno. 5 years ago, I wasn't sure Java would still be around. I
> question
> whether the performance disadvantages of web services will be so
> pronounced
> due to Moore's Law. I do suspect they will continue to fail to live
up to
> their promises. That�s a pretty easy prediction to make.
I agree with your prediction.
Per performance -- you get your best performing systems by writing
everything from scratch and tuning to your problem domain. Clients,
servers, network stacks, datastores, everything. No one does that
because the improved performance isn't worth the cost.
Web services isn't about performance. It's about interoperability.
People will definitely put out web services that don't perform because
of the inherent limitations of the model. For such cases that don't
require the infrastructure simplicity and loose coupling that web
services affords, it may be profitable to develop some web
services-to-CORBA refactorings.
For a lot of cases, I suspect that performance of properly architected
web services will be adequate, just as Java performs adequately even
though it has inherent limitations that other comparable technologies
(e.g., C++) don't have.
> > To start that discussion, I'll offer that web services is a simple
> > messaging paradigm uses HTTP for transport and XML for semantics.
> This is new? Are you sure it is not a sequel to past technologies
with
> different acronyms?
For any particular "clean whiteboard" problem, web services doesn't
offer much that couldn't be solved with other distributed computing
standards. But web services may be able to solve the problem at less
cost and the solution may be more reusable for other problems.
> > - There isn't a standard for optimizing XML.
> Do you think that web services continue to have advantages if they are
not
> wire-human-readible.
XML is humanly readable. However, when you put XML in to most any XML
database, it isn't humanly readable. It isn't necessary that XML be
humanly readable while it is in transit. When transmitting large amounts
of data, human readability is quite a disadvantage. But if there isn't a
standard for how to compress XML for transit, then the provider and the
requestor are coupled by whatever compression mechanism is used. Such
coupling defeats the key advantage of web services and reduce the
reusability of the code.
>
> > - Security/authentication. Security and authentication issues make
web
> > services more complex.
>
> I think now we want practical descriptions "do this and this" not more
> theory about security on web services.
Then the answer is SSL. I've read a lot of the web services security
theory. There are some very interesting problems, but maybe they are too
interesting... I don't see a lot of 2004-2005 problems. I see 2008
problems, maybe 2016 problems. By the time we get there, the solutions
will be more obvious. I.e., the industry will follow an agile approach
instead of a waterfall approach.
> > - Distributed computing is hard, but web services /seems/ easy.
> Honestly, I can by about 300 books on this viewpoint. Make sure
you're
> going to present a really new take on it.
I'll try ;-) I think the interesting story is that web services has its
roots in the resource-centric web, not in the heavier distributed
computing systems such as CORBA that are more focused on high-end
development problems. The web succeeded where other hypertext systems
like Xanadu failed because it focused on the simple end of the problem
domain and not the complex. I think web services is doing the same
thing.
> Not ignoring object location is different from dwelling on it. For
> performance you need to think about it. That doesn't mean I should
have
> to
> create needless forked trees of inheritance based on object location.
Hmmm.... Don't know the difference between "not ignoring" and
"dwelling"...
Some effort is needed to avoid pass-by-value vs. pass-by-reference
semantics problems. Using value objects helps, though you don't want to
be passing value objects between two objects that will always be
co-located. Thus, you need to define what constitutes a service.
Along these lines, here's a problem I encountered recently: a service
may be invoked locally or remotely. To get maximum reuse, I used the
Command design pattern in front of either a web service (remote) or a
clone factory (local). In the local case, copying the value object graph
is inefficient. But it preserves by-value semantics and is more
efficient than serialization. Also, you could optimize for the local
case -- e.g., reference immutable objects rather than copying them -- in
the factory.
_______________________________________________
Juglist mailing list
[EMAIL PROTECTED]
http://trijug.org/mailman/listinfo/juglist_trijug.org
