× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



This statement below sums it up perfectly.
A contract-first (WSDL) approach to web services is best, in my opinion, as
opposed to a code-first approach. The WSDL is valuable and allows
discovery of the service operations. Implementing the SOAP part is where
things can get quite confusing.

<side note>
The tooling in VS.NET makes creating a web service client easy by simply
accessing the WSDL and creating a web reference. This is good and bad
since many .NET coders (at least the ones I have dealt with) have no idea
what to do if things don't work at this point.
</side note>

Thanks,
Todd Allen
EDPS
Electronic Data Processing Services
tallen@xxxxxxxxxxxx




Aaron Bartell
<aaronbartell@gma
il.com> To
Sent by: "Web Enabling the AS400 / iSeries"
web400-bounces@mi <web400@xxxxxxxxxxxx>
drange.com cc

Subject
2009-12-29 16:36 Re: [WEB400] EGL, Java and PHP


Please respond to
Web Enabling the
AS400 / iSeries
<web400@midrange.
com>






I still believe the WSDL-contract is A Really Good thing even if
everything
else is a mess.

Agreed. The concept of full technical documentation of a web service is a
good thing. Now if we could just get rid of SOAP :-)

Aaron Bartell
http://mowyourlawn.com
http://mowyourlawn.com/blog/


On Tue, Dec 29, 2009 at 3:32 PM, Thorbjoern Ravn Andersen
<ravn@xxxxxxxxxx>wrote:

Aaron Bartell skrev:
How much work would it be for example to create a scalable, standards

compliant web service which serves images, pdfs and excel sheets
dynamically
from contents in a database table?

Depends on who is on the other end of the web service. If it is .NET
then
any given upgrade it stands the potential to break. Microsoft is STILL
adopting web service standards before the rest of the world agrees on
them
which causes issues for even Java programs wanting to make standardized
communication with them.

Can we agree that a proper implementation of web services is a
non-trivial matter? :)

I'd be perfectly happy with saying a web site if that is better :D

Whether something is "standard" is quite a relative term I have found.
Is
it standard according to the WS-* profiles?, standard according to the
W3C?,
standard according to a JCP/JSR?, standard according to Microsoft? Web
services are soooooo over architected it is painful to watch them
(Microsoft) "progress to make things easier". Did you catch that Sun
has
semi-formally made a move away from SOAP for many web services?
http://www.sdtimes.com/link/32959


I am aware of the REST concept as being something where you separate the
data from the action (which is part of the URL instead) as opposed to
SOAP where you basically do remote procedure calls according to the
WSDL-contract. But having

I still believe the WSDL-contract is A Really Good thing even if
everything else is a mess.

All this is still somebody trying to get Remote Procedure Calls right.
Eventually it will happen :)

--
Thorbjørn Ravn Andersen "...plus... Tubular Bells!"







This communication and any transmitted documents are intended to be confidential. If there is a problem with this transmission, please contact the sender. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.