.NET is a Web services infrastructure that uses the same general concepts found in a J2EE Web services infrastructure. In my opinion, major corporations or major divisions of large corporations will adopt either .NET or J2EE Web services, or they'll stay with more traditional approaches to distributive systems. Both .NET and J2EE Web services revolutionize distributive systems -- and are not the next evolutionary phase. Assuming that both .NET and J2EE Web services are comparable (each company needs to make a self-evaluation), the choice will come down to dependency on one company (Microsoft). Once a company makes the financial commit to .NET, they must be prepared to work under the thumb of Microsoft and be prepared to pay the ongoing "Billy tax." That is, whenever Microsoft is missing their quarterly number all they need to do is raise licensing fees and those companies committed to .NET have little choice but to pay those fees. What are the trends to solve access rights problems related to UDDI? Is JAAS relevant in a way? Is the problem independent of UDDI itself?
There are public sites that host UDDI registers that can be used by anyone. In fact, you used them to publish your own Web services today. By their nature, you should have rights to access UDDI public registries. However, access to a public UDDI registry only means that you access information about Web services that are published in that registry.
This means that the new J2EE 1.4 specifications include Web services. Keep in mind that specifications are the Java community process requirements that manufacturers of JVM and Java compilers must incorporate into their products. Specifications affect APIs used by Java developers and APIs used by makers of JVM and Java compilers. What is the relationship between UDDI and SOAP?
A programmer uses UDDI to locate Web services that have been published and uses SOAP to invoke a particular Web service. What is the protocol for publishing Web services? Who can register a Web service?
Web Services Description Language (WSDL), Universal Description, Discovery, and Integration (UDDI), and Service Oriented Architecture Protocol (SOAP). You'll find all you need to publish and interact with Web services in "J2EE, The Complete Reference." What's the current competition status between J2EE and .NET? How should a company choose a correct enterprise integration strategy?
Determining if a company should adopt J2EE Web services, .NET or remain with their present distributive environment requires a feasibility study. The feasibility studies that I conduct for companies answers one and maybe two questions. (1) Does moving to Web services make business sense? (2) If so, then is J2EE Web services or .NET the better choice? Every company has different requirements, so it is irresponsible to make a blanket statement about the correct enterprise integration strategy. The feasibility study must identify economies realized by moving to Web services and compare it to the cost to build a Web services enterprise infrastructure. The cost factor includes both startup and ongoing costs, which is where the J2EE Web services vs. .NET comes into play. Does J2SE lack the necessary API to interact with a service registry?
J2EE contains the API necessary to interact with UDDI registries. Are Web services only for 'read' operations?
No. Information about a Web service can be published and modified in a UDDI registry. The modification of a published Web service means the owner of the Web service can change information about the Web service. If I have registered a Web service on the UDDI registry, what should I provide my clients with in order to be able to access it from the UDDI? Can you please explain?
You'll need to provide your clients with the URL of the site that has the UDDI registry that you used to publish your Web services. And of course you need to grant your clients rights to the Web service itself, which you host. How do you compare .NET with J2EE in Web service application development?
From an application developer's viewpoint, .NET is a buzzword that Microsoft has attached to nearly all their development products (i.e. C#, VB). You'll find the necessary additions to the APIs of those products to handle .NET services. If you're a Java developer, you'll find all you need in J2EE to handle Web services. So to answer your question, I'd have to say that Microsoft developer's products have what you need for .NET assuming you are a developer using those products. And J2EE has the same for Web services if you are Java developer. What is the difference between J2EE 1.3 and 1.4?
The primary difference is that J2EE 1.4 contains specifications for Web services. What are your suggestions for Java Web services servers?
It really depends on demand for Web services within a corporation. This is why I suggest that a corporation undertake a feasibility study to determine its immediate long term needs. Selecting a Web services server is depended on the outcome of the feasibility study. How can I convert a Web service created on .NET to run on J2EE?
Good luck! I had heard of companies developing products that bridge both infrastructures, but my guess these reports are wishful thinking and vaporware. If you had to convert, then I suggest reverse engineering the .NET design, which could be straightforward depending on how well the .NET infrastructure was design. At that point, you would focus on designing the J2EE Web services infrastructure. What will stimulate the uptake of Web services or block it in the market?
Good question. I only wish I had the answer. Reports state there are over $40 billion of IT projects on hold until the economy comes back. Traders on Wall Street have a saying, the trend is your friend and three ticks is a trend. My guess that those projects won't be release until there is an upward trend in the economy, which might be three positive business quarters. How would you describe the state of security for Web services? Is it possible to authenticate access to UDDI registries and access to Web services?
I divide Web services security into two arenas. First, there is security to access the UDDI registry. A public UDDI registry has very limited security restrictions; otherwise the UDDI registry wouldn't be public. Existing intranet/extranet security procedures restricts access to a private UDDI registry on an intranet/extranet. The other arena is the Web services itself. A Web service is typically hosted in a private environment (intranet/extranet) that already has access restrictions in place. What is the role of other standards to define content of Web service communication? A sales order defined by one is not that defined by someone else. What will happen here?
Although companies might have different definitions for a sales order, the Web service that you create defines methods that require sales order information specific to your company. Let's say that your company creates a Web service enabling a customer to place an order. The customer uses an interface that you create as your Web service to place the order. The interface contains methods that require specific information that a customer must supply for the order. You specify the interface when you publish the Web service in the UDDI registry. Therefore, the customer having retrieved information about your Web service from the UDDI registry knows how you define a sales order. If I am on an intranet, what would I have to set up to run Web services? (e.g. UDDI registry, and how difficult / expensive is it?)
You'll need two things. The first is a Web service that is remotely accessible using an interface. Next, you'll need to publish the Web service in a UDDI. I show you how to do both of these in "J2EE, The Complete Reference." What is the major investment required to start Web service implementation?
First is a feasibility study to determine if Web services makes good business sense. The feasibility study must review major applications within a company to determine common tasks. The study must determine current and future network traffic patterns and a host of other critical factors. The result of the feasibility study should answer the question should the firm move to Web services and if so, an estimate of the investment necessary to implement a Web services infrastructure. Are Web services commercial users really using UDDI to find and contact services or are clients merely using direct interchanges with providers?
In the ideal world, customers would use UDDI registers to locate Web services published by potential suppliers. Those Web services would contain information (i.e. interface) that is used to access information about the supplier and possible enter into e-commerce. The reality is the Electronic Business XML (EbXML) effort that tried to develop such an electronic economic community hasn't had many takers. I discuss EbXML in a chapter of the "J2EE, The Complete Reference." Most companies will use Web services with their existing business partners. New partnerships will likely develop the traditional way -- phone calls and lunches. Which is better? J2EE or CORBA? Why should I use J2EE instead of CORBA?
It depends. I'm of the belief you don't fix something that isn't broken. Therefore, if you are using CORBA, continue to us it unless there is a good reason to switch to something else. And if it is time to switch, then conduct a feasibility study to determine if Web services are the best route to implement. How is the ROI measured across the enterprise in moving towards using Web services internally and to the external world?
ROI is one of the factors contained in the result of the feasibility study to determine if Web services is the best direction for the firm. One of the issues at hand is the manner in which a company allocates IT services. Some companies have a decentralized IT department where developers and ongoing support for systems is directly related to a profit center. For example, a trading desk in a Wall Street firm might have its own IT group that builds and supports systems for the trading desk. The trading desk pays the entire cost of this group. A Web services infrastructure changes this formula. Typically commonality among applications is formed into Web services that are developed and maintain by the central IT department. This results in the profit center (i.e. trading desk) losing direct control over an aspect of their systems while incurring new charge-back cost for Web services development and maintenance. Although the company's overall IT investment might be reduced and therefore return a favorable ROI, this savings won't be realized directly by the profit center. This is why a feasibility study is necessary to address all these subtle but material issues before embarking on developing a Web services infrastructure. Is an application composed from JSP's, servlets and JavaBeans still considered a J2EE application? (meaning that it does not involve Enterprise JavaBeans and a EJB server)
Yes. The term J2EE application has a very broad definition -- and one that changes depending who you speak to. I like to think of a J2EE application as being any application that uses advanced features of the Java language that is beneficial to an enterprise environment. Are there any training institutes for getting in Web services in Java?
Not sure. I know that this topic is lightly covered in an advanced Java course at Columbia University. Usually IT professionals use books like my "J2EE, The Complete Reference" to get up to speed on implementing new technology.