Question to Ray Lai ( about your book J2EE platform for webservices)

[Kishore Dandu]

Ray,
I have 2 questions. One is related to the book and the other related to your approach to writing a book.
1) Are web services being used extensively in the Industry. How about if they are used in places where they are not really needed. Does your book give some details about where to use them and where not to.
2) What made you to pursue a book(which I heard takes a lot of personal time from start to finish). Is it personal satisfaction or to give out your knowledge to the world or combination of both.
Let me know.
Kishore Dandu.

[Lasse Koskela]

Originally posted by Chris Daniel:
2) What made you to pursue a book(which I heard takes a lot of personal time from start to finish). Is it personal satisfaction or to give out your knowledge to the world or combination of both.

I'd say these two are the same thing
In general, humans don't do anything out of generosity but only because it gives them satisfaction -- of course that satisfaction can be of the type, "I'm glad I could help that guy out with his Java problem".

[Ray Lai]

Originally posted by Chris Daniel:
1) Are web services being used extensively in the Industry. How about if they are used in places where they are not really needed. Does your book give some details about where to use them and where not to.

There are many web services applications in the industry, but most of them are kept as pilot, or as low-profile confidential implementations. Very often, vendors or consultants cannot reference them in public (say, in books). IMHO, web services are fairly common in the vendor market (e.g. apps server, middleware), and most customers are using them without realizing them. In the customer application side, web services are used in the financial services industry and government space. I also see the telco and travel/transportation industries (e.g. Sabre) are picking up pilots and large implementation. I do have some first hand consulting experience with some major financial services institutions, telco and transportation firms for the past year that have just deployed web services. Borrowing Gartner's technology hype model, I'd say web services technology has reached or perhaps passed the hype point/maturity point.
One thing I've emphasized in my consulting. Don't hardsell web services when it's not required. There are always scenarios where web services technology is one choice, but not necessarily the best choice. In my book (section 2.6 establishing a business case), I've discussed how to create a business case, and rationalize for scenarios where web services technology is appropriate, e.g. external or internal integration where there are more than three trading partners, and the interface changes are dynamic. (Well, if there is only a point-to-point interface between 2 trading partners, and the interface/contents don't change, then it is not necessarily cost-effective to use web services.)
Where to use and not use -
A rule of thumb is to look at examples where web services are applied (e.g. case studies, real life examples). This can help the technologist to determine where to use, and where not to use. Section 2.4.2 shows a list of cases. It's important to understand what are the business drivers behind these examples (e.g. new intermediary, multi-sourcing), which are good indicators of where to use web services.
Another approach is to define the characteristics of good web services cases, e.g. large number of trading partners, high re-usability, branding / white labeling of business services, etc. Section 2.6.2 depicts and discusses a list of them. Typically, you may like to scrutinize yourself by doing a risk analysis (section 2.6.7), and a ROI model (section 2.6.9) to ensure this business case make sense.

2) What made you to pursue a book(which I heard takes a lot of personal time from start to finish). Is it personal satisfaction or to give out your knowledge to the world or combination of both.

Motivation - I want to make a contribution to the industry. I thought about writing a financial services application book/case study book in Java. Web services technology strikes me, as this is really exciting. After some exchange with many practitioners, I determine to do a case book based on my field experience - it's an adventure and learning experience.
It's both sharing experience with the industry, as well as a great personal experience (satisfaction).
A lot of personal time? Definitely. I spent 4 elapsed months finishing the first draft. But I rewrote 40% of it after the first iterations of feedback. This web services space is evolving so fast that it's really difficult to keep up-to-date.
[ February 25, 2004: Message edited by: Ray Lai ]

[Kishore Dandu]

Thanks Ray.
Its great to make a difference for the betterment of society. Keep it up.
Dan.

[Avi Nash]

Hi Ray
I want to know these things:
1. When should we go for Web Services?
2. When should we not go for Web Services?
3. For what kind (and what size?!) of projects should use web services?
4. What are other alternatives instead of using web services?
5. What are the security features to be considered while using Web Services?
Thanks and Regards
Avinash

[Ray Lai]

Originally posted by Avi Nash:
1. When should we go for Web Services?

Difficult question.
Short answers - large number of trading partners, dynamic/complex integration requirements (e.g. frequent changes), need reusability, etc.
BUT - they all depend; it's a matter of spectrum of choices, relative pros/cons and constraints, political context, etc.
My book ch 2, p. 33 section 2.6.2 defines the list of attributes of the web services candidate.

2. When should we not go for Web Services?

Relatively easy to answer -
Do web services for technology sake, point-to-point interface that does not require reusability or frequent changes, low awareness of what web services is, high risk project, lack of business executive sponsor, etc.

3. For what kind (and what size?!) of projects should use web services?

My book ch 2, p. 41 section 2.6.6 discusses what kind of projects should use web services, e.g. high business value, thought leadership, process-oriented, etc.
Typically, from a management perspective, you don't want a large size high risk project to go for web services. It's the same principle for any emerging technology.
From my first hand experience, most early adopter customers start small project size, but high business impact (e.g. high cost savings, operational) but not necessarily mission critical. Small size means different things to different industries and regions, e.g. in terms of dollar, US$100K is considered relatively high in some Asian countries, but US$300K-500K is a small size project to some US companies. In terms of team size, team size of 10 or below is small to many companies. I did see many web services pilots are achieved by 3-5 top-notched architects/developers.

4. What are other alternatives instead of using web services?

Traditional EAI, middleware, screen-scrapping (tactical integration tools] are examples of alternatives.
Some even claim Corba, parameter-driven or OO-design are also alternatives.

5. What are the security features to be considered while using Web Services?

My book ch 7 pp. 362-434 defines a design methodology for web services security. Typically, you need different flavors of security for different stacks, e.g.
* Infrastructure, e.g. key management, directory server, identity server, host security hardening, intrusion detection, protection of web services objects/infrastructure
* Message level security, e.g. WS-Security, XML-encryption, XML-DSIG
* Messaging/routing level, e.g. web services proxy
* Policy-based, e.g. XACML
* Authentication, e.g. Liberty-based security
* Distributed security, e.g. SAML-based single sign-on
* Transport level, e.g. HTTPS
* Process-oriented, e.g. risk mitigation against replay, man-in-the-middle, Denial of attack
* Proactive security assessment methodology before production/checklist
e.g. p. 420 table 7-3 shows a simple checklist
I'm currently co-authoring with 2 specialists on a specialized J2EE/web services security book, which will be available by fall 2004.

[Avi Nash]

Thanks a lot Ray
I also want to know
1. can state be maintained between SOAP requests and if yes, how?
2. disadvantages of using web services? and
3. What is better option for web services - .NET or J2EE?
Thanks and Regards
Avinash

[Ray Lai]

Originally posted by Avi Nash:
I also want to know
1. can state be maintained between SOAP requests and if yes, how?

Basically you have to maintain states between SOAP requests.
If you use a stateful session bean to invoke remote web services, you can store states between SOAP calls. There are some disadvantages obviously.
One argument is that your remote web services may be tracking the states already. so why are you tracking additional state information? perhaps you can use a stateless session bean to invoke remote services, and keep track of the return code (instead of full state information) for re-try or recovery.
State management is a complex subject, and can be very debatable. ch 4 pp. 188-192 section 4.8.5 discusses the subject.

2. disadvantages of using web services? and

One disadvantage is that web services can be quickly deployed, and it may take longer time to make it right (due to the complexity of deployment, and SLA management). You have to build web services it seriously with subject matter experts. You can't do web services half-hearted - you have to do it right, considering all layers and platforms. For example, wrapping your legacy apps with SOAP, and exposing them in production. This won't work because it does not have a thorough security design.

3. What is better option for web services - .NET or J2EE?

There is no better option, because people use heterogeneous platform for production. There's always proponents for specific platform technology, no matter .net or J2EE - you always hear from the .net guys saying .net web services is fast and developer-intuitive; the same for Java guys.
Hope these discussion makes sense to you.