Stephen Graham

Sanjay:
If SOAP/WSDL and UDDI are sufficient for your needs, then great, you can stop there and be productive. The decision in the Web services community was to produce a collection of smaller, relatively complementary standards as opposed to a single monolithic approach. This allows a mix and match approach to designing and deploying applications and middleware. This makes it much easier from a standards perspective as well, as changes can be made locally to existing specs where appropriate and new specs can be added to the mix to serve special purpose.
I agree there is a lot of new technology coming down the pipes, but I assert that the rate of change will slow down over the next 6-12 months to everyone's relief.
sgg

Originally posted by Sanjay Bahal:
Sometimes I wish- they will makeup thier mind and create a standard so that we can move and implment the business rather than going thru the learings of every new flavr of technology.
Webservices started with SOAP/WSDl/WDDI. There already new additions like WSCL/WSFl etc- they are useful but a lot of strain on developers.
Sanjay

------------------
sgg.
Author of "Building Web services with Java" http://www.amazon.com/exec/obidos/ASIN/0672321815/104-9025316-6753534

Fei:
The book is aimed at developers and designers. The book takes the reader through an introduction to what Web services is all about, does a tour through the important aspects of XML needed for Web services, we then discuss SOAP, the Apache Axis implementation of SOAP. We then have a chapter dedicated to other e-business aspects of Web services (such as security). We then cover WSDL, UDDI and then discuss other vendors approaches. The book finishes with a tour of "what the future holds" for Web services
Pretty comprehensive overview, it should be good to get any developer started.
sgg
------------------
sgg.
Author of "Building Web services with Java" http://www.amazon.com/exec/obidos/ASIN/0672321815/104-9025316-6753534

Johannes:
MQ doesn't replace SOAP. Rather, the positioning to consider would be something like SOAP over MQ (MQ replaces HTTP in this case). Check out the HTTP-R (http reliable) specification. www.ibm.com/developerworks/webservices has some good httpr resources (primer and spec) and the WSTK 2.4.1 has an httpr impl and demo.
sgg

Originally posted by Johannes de Jong:
"Web Services consists of SOAP (the protocol for distribution),"
Could SOAP be replaced by MQ of IBM ?.
We are going the web-services way with our internal systems. Basically it will consist out of

1. The application (could be legacy)
2. XML as the "interface"
3. MQ as the "data-bus"

That's the chosen "architecture" in very basic lines, sorry I saw only rough draft . Am I then right that they use MQ as opposed to SOAP.

------------------
sgg

Max:
The Axis WSDL support does handle complex types, to a certain degree. The state of the art of WSDL tooling is still maturing, as a result, the book is constrained by the current tool set for the most part.
With respect to object modelling in WSDL, this is a bigger problem. There is no convenient way to express this in WSDL. PortType inheritance does not exist (unfortunately). The only way around this that I have heard of is to use multiple port elements under a service.
So...
if I have 3 portTypes: Super, Middle, and Sub, and corresponding 3 bindings superBinding, middleBinding and subBinding, then I would define a service with 3 ports:
<service name="inheritanceHack">
<port name="superPort" binding="superBinding">
<soap:address location="http://someaddr/>
</port>
<port name="middlePort" binding="middleBinding">
<soap:address location="http://someaddr/> (note: same address)
</port>
<port name="subPort" binding="middleBinding">
<soap:address location="http://someaddr/> (note: same address)
</port>
</service>
Now, this will have the effect that the resource located at http://someaddr will have the transitive closure of all the operations defined in the three portTypes. Very weak inheritance, furthermore the ordering of inheritance is not defined. Most tooling won't recognize this service element as representing inheritance. WSDL spec is vague with respect to how to interpret the collection of port elements under a service element.
That is ugly, but as close as WSDL gets.
sgg
------------------
sgg

CPU speed is a consideration, but if you do complete performance analysis, most business systems are I/O bound, not cpu bound.
------------------
sgg

the reference to "green" pages is the registry of Web services associated with a business. So if the white pages are the business registrations, and the yellow pages connote an organization scheme (taxonomy) of businesses and services then green pages are the registry of services.
------------------
sgg

Another advantage to consider is reach of your customers/business partners that will be accessing this service. There is a higher likelihood that these partners will be able to host a Web services infrastructure.
------------------
sgg

Yes, Web services are quite new and still evolving. However, do not mistake the current pace of new "languages/techniques" for a steady-state. I expect that the range of "new" Web services technologies (like WS-Inspection) will calm down within the next 6 months. The real work will begin with a new phase, already started, and most likely lasting for 12-18 months, in which we will see continued improvement of the implementations and tooling in this area.

Originally posted by faisal mahmood:
This article is written in Oct 31, 2001.
Also, from the content it seems things are happening recently.
Is Web-service so new?
Faisal

------------------
sgg

There is a speed/flexibility trade-off with Web services. There is no doubt. With HTTP and XML, there is a ubiquitous infrastructure upon which Web services can ride. There is a higher likelihood that organizations can get Web services up and running much more quickly than with previous distributed computing technologies.
This is about reach to customers/suppliers and other business partners here, this is not about raw compute performance.
When you consider the use of Web services (coarse-grained) distributed computing, the network latency is the biggest performance consideration. If you are trying to use Web services for fine-grained tight object integration over the Internet, then you may want to completely reconsider your architecture. Even with CORBA/RMI, you are going to have significant performance problems.
So, given the network, particularly the Internet, is a core part of the architecture with any Web services interaction, you need to ask yourself, what percentage of overall performance do I actually have control over?
One interesting side note, because Web services is based on Internet technologies, we will be able to piggy-back on top of a lot of the infrastructure that makes the Web move faster (routers, sprayers, edge of network boxes, etc).
sgg

Originally posted by faisal mahmood:
Hi,
Performance wise how is web-services?
I think it would be slower than CORBA or RMI?
Faisal

Faisal:
The book does have a chapter devoted to vendors and tooling. This is a rapidly evolving field. A good resource to keep in touch with what is happening in the Vendor space of Web services is www.webservices.org.
sgg

Originally posted by faisal mahmood:
Hi,
Is this a new book? Also how about information about vendors (WebServices implementors)
Faisal

Mr. Goundalkar:
Your three questions deserve (at least 3) answers:
1) Basic requirements of creating/developing a simple web service:
- This depends on your starting point. Many organizations already have their business processes in some automated form. The use of Web services in this case is to expose one or more operations from these business processes in a form invocable over the Internet. Currently, use of SOAP is quite popular as the mechanism to send messages over HTTP. We will see moving forward that in many cases (particularly document centric messaging) that simple post of an XML payload using HTTP will be sufficient. SOAP has benefits in an RPC-centric model, but it is not clear that this will be the prodminant model within the next 12-18 months.
If you are building the business logic from the ground up, you will need to choose an implementation technology (I recommend J2EE)and then expose the EJB as a Web service.
net/net: to get started, you need a the business logic implemented in some programming language, and you need some sort of SOAP middleware (I recommend Apache Software Foundation's Axis project).
Once you get your feet wet with this, you can then move up the stack (make the Web service secure, describe it using WSDL, publish it in a UDDI registry). Walk first, then run. Happily there is plenty of tooling available to help out.
2) How is a Web service different from RMI, CORBA, etc.
Web services have in common with RMI and CORBA the fact that they are all distributed computing technologies. Web service differs in a couple of very important points.
a) intent: Web services is the first distributed computing technology to marry RPC-centric and messaging (document centric) models. RMI and CORBA are unapologetically RPC. Prediction: the business world will move to document-centric model within 12-18 months.
b) granularity: this is somewhat associated with (a). Web services, when done right, encourages much more coarse grained, less brittle APIs than RMI and/or CORBA.
c) Web services is NOT distributed objects. You will not see notions of distributed garbage collection, etc. with Web services. This is incredibly simplifying, and forces developers to abandon the false-promise of local/remote transparency.
d) XML. Don't underestimate the power of XML. It is readable, simple, flexible and is the underlying power source for the Web services approach.
3) What are the new technologies?
Happily, your Java skills will still be very important. Web services is an access technology, not an implementation technology. The logic still needs to exist in program form. Keep using Java, it is a good language for implementing logic in a portable, object-oriented fashion.
The tooling support makes it possible to do Web services without learning any new technologies (just use the tools and you are done). The downside is that the current state of the tooling art is quite primitive. However, there is a lot of vendors doing a lot of really good work in this space.
If you are really motivated to learn what is under the covers, here are some technologies that are a starting point:
a) SOAP. The base messaging mechanism. Check out Apache Axis (www.xml.apache.org/axis (http://xml.apache.org/axis/index.html)
b) WSDL. This is the base IDL for Web services. It is a little strange, but easy to get used to. The best way to learn WSDL is to review the spec (www.w3.org/TR/wsdl) as well as stare at some WSDL examples (www.salcentral.com).
c) UDDI. This is a registry API for Web services. Check this out at www.uddi.org. Get a) and b) down solid before moving to c).
Of course, there are rich resources for Web services on the web. I personally recommend www.ibm.com/developerworks/webservices.
good luck
sgg

Originally posted by L Goundalkar:
Hi All,
Can anyone tell me what are the basic requirements of creating or developing a simple web service.
How a web service is different from RMI, CORBA and so on.
Being a Java developer what are the new technologies I have to learn to start a new ride in Web services.

TIA

------------------
sgg