On 10/25/03 5:45 PM, "Michael D. Thomas" <[EMAIL PROTECTED]> wrote:
>
>>> * 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.
>
Or direct method invocation.
>>> * 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.
>
Do you think that the way it is being sold isn't being or intended to be
interpreted as "if you build it they will come" and excuse from all
architecture? Or do you think that like APIs, SOA will evolve to fit its
users with *some* intimate knowledge on how its *generally* used and how the
other APIs interact with them?
>>> 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...
Agreed, but regardless I feel that database-based application design is
inherently flawed and leads to scaleless systems.
>
> 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.
>
Do you mean Big Up Front Design approach? You feel that web services
necessitate this?
>> 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!!"
>
If it takes "<int>42</int>" to transfer what I previously would have
transferred as "42", have I still saved a nickel? Or have I merely shifted
it?
>
> 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.
>
Do you feel that web services really simplifies the model?
> 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.
>
Do all systems require interoperability?
>
> 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.
>
Do you feel that it will be always true given the advanced amount of
serialization it requires. For instance, if my application takes an E10K to
run and adding web services makes it take two E10Ks and my realized profit
from this system is 10% of the value of an E10K per year and this is an
internal use application which maybe sends a few messages to our JMS
compatible accounting and ordering systems...how will changing those
interactions to web services benefit me?
>>> - 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
XML databases...hehe... That is an entirely other discussion.
> 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.
>
Seeing that almost every language supports zip....do we really need yet
another standard? Or could the standard be something like "just do a gzip
stream" or something like that... I realize that we'll need a few
committees to draft that ;-)
>> 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.
>
But I thought we were going to write a lot of "Touchstone artifacts" -- how
do those fit into your agile approach? How does the design of the actual
web services standards compare with agile approaches? How will this affect
adoption?
At what point should we call web services a "failed to be adopted" standard
(for CORBA this was bout 10 years) and move on?
>
>>> - 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.
>
To what degree do you think this is why the web succeeded and to what degree
do you think the fact that it was demand driven which necessitated
interoperability started the cycle? To what degree do you think the web
service committees resemble the OMG's committees? Do you think that these
vendor-driven communities will succeed where the OMG failed?
>> 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.
>
That all depends. In the case of EJB there are transactional effects which
value objects solve as well as serialization effects. If you pass back an
entity reference, there are transaction implications. Also I like to pass
back immutable values often.
> 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.
>
I despise EJB local interfaces. In the case of JBoss they are only relevant
where the standards make them relevant. Everywhere else you're just coding
needlessly. That doesn't mean you don't need to take notice...but having to
dwell via object model on the locality or inlocality is gross IMHO.
Now would you like to switch sides? ;-)
-Andy
>
>
>
> _______________________________________________
> Juglist mailing list
> [EMAIL PROTECTED]
> http://trijug.org/mailman/listinfo/juglist_trijug.org
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
The views expressed in this email are those of the author and are almost
definitely not shared by the Apache Software Foundation, its board or its
general membership. In fact they probably most definitively disagree with
everything espoused in the above email.
_______________________________________________
Juglist mailing list
[EMAIL PROTECTED]
http://trijug.org/mailman/listinfo/juglist_trijug.org
