|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 13
Messages: 13
Messages: 13
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
"Web services will have to wait?"
An article in CIO Today points out that with the release of the Basic Profile this year (and verification tools just this month), there's a lot yet to be defined in the Web services space. Is it really prudent for corporations to be making big bets on something this new?
Obviously this is a concern for any new technology; companies that invested heavily in EJB in 1999, for example, found themselves learning the hard way what today's EJB practitioners learn from books and articles, and the same was true of COM adoptees in 1995.
From the article, "Right now, there is a genuine sense that we are not quite where we need to be with regards to having a complete stack of Web-service standards," Forrester Research vice president Uttam Narsu told NewsFactor's CIO Today Magazine. "I think we are going to be looking into 2005 before we will see a relatively stable set of specifications." The article goes on later to say, There are potential advantages in "stepping out and being on the leading edge in linking up people to data on a more automated basis," echoed Yankee Group senior analyst Dana Gardner. To discover whether there will be "a clear payoff with respect to productivity, I.T. managers will need to conduct cost versus benefit analyses on a case-by-case basis," he told NewsFactor's CIO Today.
Read the CIOToday article for more.
|
|
|
Message #115697
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Web services will have to wait?"
I agree that there are a number of issues regarding the maturity of a common set of web service standards. for example, eventing microsoft and ibm have different standards. UDDI. we need a pervasive implementation.Additionally, it's not easy to implement an X509 security model. i know the examples tout the ease of it but i really don't like the idea of storing x509 certificates in relative plain view on the client....and many organizations don't have the bandwidth to act as Certificate Authorities and act as a 3rd party intermediary b/w client application and server.....but these are my greivances...
BUT WITH ALL THAT SAID, there are huge benefits to leveraging web services. especially on an intranet where have a mixture of platforms but you still have good control over the protocols in your environment. the low hanging fruit is not integration between companies but integration between divisions in a company by creating a common set of business functionality to support the different media outlets of a company. For example, Telephony, Kiosks, Internet applications, etc.
Service Oriented Architectures such as web services enable an organization to break out of "Silo" development that is so pervasive in large companies and provide the means to think holistically about their corporate business software needs.
My 2 cents anyway.
-Mathew Nolton
|
|
|
Message #115741
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Web services will have to wait?"
I agree with what Mathew said. Though web services standards are not quite ready, the design they enforce is the way to go, so why wait? In my opnion, even if some things change, they will very probably change in the layers managed by your framework, .NET or Java, your code won't change much, and most important, your application design won't change. And design is the most important thing, the only one you can't mess with.
My 2 cents :)
Francois
|
|
|
Message #115774
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Web services will have to wait?"
Same here, the specs will be seamlessly implemented in the .Net platform that there is no real reason to wait to implement SOA based on WS within a corporation. When we start to reach outside of our LOBs or corporations, then schema standards, security, reliable messaging, BPEL and interoperable WS platforms will become more important. We will then have start building some industry standards around message schemas and service contracts, to reduce the amount of custom intergration.
As for .Net, Indigo, Longhorn Server, BizTalk, will go a long way to help get us there, yet J2EE can't be left behind if WS is fullfill it's promise.
|
|
|
Message #116020
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The difference between EJB and WS
Ted, you mentioned EJB as an example of a technology that held some surprises for early adopters. Will the same thing befall early adopters of Web services?
No, I don't think so. Web services are delivering capability (As Mathew described) as they are deployed. there is instantly a pay off. Many people have said - "look, I could do all this before SOAP. I had RMI, I had DCOM, or whatever. And those protocols were more efficient, too! What is different about webservices? It's fatter, slower, and redundent! Pshaw! "
Ok, I'll give you that. xmlws has all those weaknesses. But the strength is the platform neutrality of xmlws, which does 2 things: #1, it means new connections are being made now with xmlws that were not possible, not without lots of effort, before. Yes, you could connect 2 Java systems via RMI, or 2 corba systems via IIOP, or two MS systems via DCOM, but you could not mix and match those. Despite the gaps and weaknesses in the standards today, the basic connectivity is there. It is a leap up from where we were 3 yrs ago, and it is easier to do, as well.
And #2, the platform neutrality is leading to ubiquity. More investment and effort is being put into xmlws than ever went into Corba or RMI or DCOM. It has reached a tipping point, where it will be the first choice for many systems. Not to say that other options won't continue, but they will not be the primary connectivity approach.
I agree that as the industry gains more experience with deploying this stuff, we'll all get smarter. We will learn things, and 24 months from now, the choices you make and the designs you use will be different from the ones you are using today. Let's hope the changes are not radical. But this is a natural learning process. Despite those changes, people will still be satisfied with the investment they made today.
Looking back, they'll be satisfied that they invested in XMLWS today, because they realized an immediate payoff. Is the same thing true of people who adopted EJB 3 years ago? (I distinguish between EJB and J2EE, probably in agreement with the spirit of Ted's original comment.) Did those EJB people get their payoff? Would they say they are satisfied? I'm not so sure.
Yeah, I know, I sound like a "true believer". Like I drank a few pints of the xmlws kool-aid. I have tried to maintain skepticism, but in this case, XMLWS is working.
One last thing... Ted askedIs it really prudent for corporations to be making big bets on something this new? It has been 3.5 years since the tech preview shipment of the .NET Framework. At that time it was called the NGWS toolkit or something. It has been 2 years since the release of .NET 1.0 and ASMX web services. A bunch of other offerings have been available for a similarly long time. I don't think it's so new at this point.
-D
|
|
|
Message #116073
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The difference between EJB and WS
But the strength is the platform neutrality of xmlws, which does 2 things: #1, it means new connections are being made now with xmlws that were not possible, not without lots of effort, before. Yes, you could connect 2 Java systems via RMI, or 2 corba systems via IIOP, or two MS systems via DCOM, but you could not mix and match those. Dino, I must disagree w/ you here. The current state of the market is such that you can connect a Java system/CORBA system and an MS system over IIOP. There are products/technology out there that make this process quite seamless. This means that you instantly get the efficiency and maturity of IIOP as a protocol to work for you. You get this in a platform neutral way in addition to it being far simpler than w/ the current crop of tools for XMLWS.
Having said that...And #2, the platform neutrality is leading to ubiquity. More investment and effort is being put into xmlws than ever went into Corba or RMI or DCOM. I must agree w/ you on this point. What WS has going for it is universal adoption and a heck of a lot of investment and effort poured into it. Across the MS/non-MS camps, which is the most crucial part. In addition, the argument that I make earlier falls apart when you talk about connecting to an SAP system for example (which does support WS, I believe (if it doesn't pick a system that does..)). And that's where the universal adoption helps.
The problem though is that WS is being touted as the one solution for all connectivity problems and that's absolutely not true (and will likely not be the case for quite a while). It is great for certain things, but is simply not designed to support certain use cases.
Like all engineering problems, you need the right tool for the right job.
|
|
|
Message #116153
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The difference between EJB and WS
Vijaykumar,
I agree that the current state of the market enables you to find a tool that enables you to connect otherwise disconnected systems. However, as you point out, your argument starts to fall apart when looking to another systems that doesn't play the same game. To continue this line of thinking, both camps realize that one-off tools aren't a long term solution for a pervasive implementation. Instead the fundemental building blocks must be created and/or rearranged for us all to play in the same sandbox which is what web services provide. It may not be perfect and it may not yet have the maturity we demand but it is a whole lot better then anything prior. The only thing that might kill it is if IBM and Microsoft continue their seperate strategies in more areas then just the eventing model. I believe the issue comes down to IBM's investment in MQSeries and/or Microsoft's need to dilute IBM's strength in this market (but that is complete and biased conjecture on my part).The problem though is that WS is being touted as the one solution for all connectivity problems and that's absolutely not true.... I couldn't agree more. Webservices should only be used to expose business logic that you want to encapsulate for all to use. Too often I see people and companies touting it as another implementation of a data access layer. That is silly. If you must do that, each platform can natively connect to a datasource better, faster and cheaper. What benefit is there to exposing it as a webservice?
-Mathew Nolton
|
|
|
Message #116194
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
WS is not a panacea
Yes, XMLWS doesn't replace everything, Vijaykumar. Extending Mathew's point, here's the way I look at it. Given N distinct systems each with its own connectivity approach, and the challenge of connecting (potentially) between each pair. If you use a specific bridge for each pair, for example, an .NET-to-IIOP bridge, and then an RMI to MQSeries bridge, then a iDoc/ABAP/RFP-to-DCOM bridge... etc. you can see that this is an o(N^^2) solution. Each particular bridge may be highly functional and tunable and efficient, but the cost of managing the set of them is prohibitive. To restate: having a special-purpose bridge for every combination is cost prohibitive.
XMLWS is a least-common-denominator approach. It removes cost because it is an o(N) approach. Though, I would agree that xmlws should not replace every bridge. For example, there may already be a highly optimized and highly leveraged RMI-to-.NET bridge in use in a company; maybe the company needs the low latency and high throughput offered by this bridge. In this case, by all means keep it. But use XMLWS for everything else.
I am curious about your statement though, that the bridge technology (eg, .NET-to-IIOP, or .NET-to-RMI) is far simpler than the current crop of xmlws tooling. I'd like to hear more on that; my experience is different than yours perhaps.
Also I agree with Mathew that XMLWS can be over-applied.
|
|
|
Message #116196
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What could kill it?
The only thing that might kill it is if IBM and Microsoft continue their seperate strategies in more areas then just the eventing model ... I don't think the back-and-forth negotiation over the various protocols will kill web services. Every stakeholder in the web services standards discussion (each vendor, every customer group, etc) brings a vested interest. Everyone has something they want to protect or support. There will be a more or less chaotic evolutionary process as the higher-order standards are shaken out. The base standards were easier to agree on (for example, no one was proposing an alternative to XML as a data format! ...), but as we move higher in the stack, things will get more contentious. But I have high hopes that eventually solutions will be reached.
For example, look at WS-ReliableMessaging. This went through several evolutions before being approved recently. To me the MQSeries-vs-MSMQ weighs much more heavily in this piece than in WS-Eventing. But in any case, there is now an agreed standard. We move on.
The thing that keeps the process itself on-track is customer involvement. Customers will keep all the vendors constructively engaged. In some cases large customers can have direct impact, in other cases it is user groups that will weigh in. I think WS-I membership is still relatively cheap, in terms of dues. But there is a time/resource cost to attending and participating in the process.
|
|
|
Message #116244
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The difference between EJB and WS
However, as you point out, your argument starts to fall apart when looking to another systems that doesn't play the same game. To continue this line of thinking, both camps realize that one-off tools aren't a long term solution for a pervasive implementation. Instead the fundemental building blocks must be created and/or rearranged for us all to play in the same sandbox which is what web services provide. It may not be perfect and it may not yet have the maturity we demand but it is a whole lot better then anything prior. I think you misunderstood what I said. When I talked about tools that let you interconnect these systems w/ IIOP, I meant to emphasize IIOP and not the tools themselves. The real issue is playing the same game. What WS has going for it is the fact that everybody has agreed atleast at the basic level to play the same game. Had they chosen to support IIOP, then it could have been the connectivity technology of choice.
In other words, while these tools may be one-off, the IIOP protocol is standard and essentially could have been the fundamental building block and it is mature and is a whole lot better the WS when it comes to synchronous stateful communication.
Note my little caveat at the end here ;-) ("when it comes to synchronous stateful communication". If you take the majority of the current crop of WS solutions, all they tend to do is wrap such classic synchronous communication with WS(exposing an EJB method, java method, .NET method). In this case, all WS (and here I'm equating it to WSDL/SOAP/HTTP) is, is a protocol stack. It needs a protocol engine on the client to make invocations and receive responses etc (which is no different from a CORBA stack).Webservices should only be used to expose business logic that you want to encapsulate for all to use. Too often I see people and companies touting it as another implementation of a data access layer. That is silly. If you must do that, each platform can natively connect to a datasource better, faster and cheaper Couldn't agree more.
Vijay
|
|
|
Message #116254
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
WS is not a panacea
To restate: having a special-purpose bridge for every combination is cost prohibitive. XMLWS is a least-common-denominator approach. Agreed. As I mentioned earlier, my point was that WS (atleast as practiced today) has no significant advantage (it has many disadvantages) over IIOP as the LCD. This is especially true when you are connecting two synchronous RPC models. Note that we are not talking bridging here. .NET is a platform not a protocol. When I say tools, I am talking abt native IIOP implementations on .NET, which means no "bridging" is going on. But use XMLWS for everything else That's a blanket statement and you just mentioned in the previous sentence an exception to that statement. I suspect there are quite a few exceptions like that.I am curious about your statement though, that the bridge technology (eg, .NET-to-IIOP, or .NET-to-RMI) is far simpler than the current crop of xmlws tooling. I'd like to hear more on that; my experience is different than yours perhaps. Also I agree with Mathew that XMLWS can be over-applied. I agree that bridging technology is a no-no. That leads to the problem you highlight (The O(N^^2) issue)(although companies have made a business out of it). Further it leads to the problem of compromises made due to the translation and the differences in the communication models.
With WS, you have similar fidelity problems, especially when using it to link to a communication model that's very different (say EJB or CORBA). Those models are synchronous and stateful and optimized for fine grained (high throughput/low latency)interactions, whereas WS is designed for asynchronous, stateless coarse grained interactions. Apply WS here and you have a problem.
You may want to give a quick spin of
Janeva (WARNING: Shameless plug. Now you know the real reason behind my position (that's a product I'm involved with) ;-). Of course, it's all very objective. I promise. Really. <grin/>) to see what I'm talking abt.
Vijay
|
|
|
Message #116338
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
WS is not a panacea
I think you misunderstood what I said. When I talked about tools that let you interconnect these systems w/ IIOP, I meant to emphasize IIOP and not the tools themselves. The real issue is playing the same game. What WS has going for it is the fact that everybody has agreed atleast at the basic level to play the same game. Had they chosen to support IIOP, then it could have been the connectivity technology of choice. If we are talking about a traditional OO paradigm then I agree with you. If you are talking about SOA, then no I don't agree with you. Correct me if I am wrong but IIOP is answering a different fundamental question and is closer to DCOM, CORBA and .Net remoting; so applying IIOP to what WS is trying to answer wouldn't be fair to either paradigm; however, another quote you made in your most recent comment lends itself better to discussing SOA (i think)...With WS, you have similar fidelity problems, especially when using it to link to a communication model that's very different (say EJB or CORBA). Those models are synchronous and stateful and optimized for fine grained (high throughput/low latency)interactions, whereas WS is designed for asynchronous, stateless coarse grained interactions. Apply WS here and you have a problem. Are you saying that it's not fair to compare the two paradigms? Then I agree with you with one minor tweak. WS can work synchronously if you so choose. In fact, I would bet most people (including myself) do deal with ws synchronously....even though you can set it up to work asynch and get significantly better throughput.
Or are you saying that you should not mix the two paradigms? What about the case where you provide a service facade over EJB/CORBA/.Net BLL components in order to provide a stateless interaction with clients?
-Mathew Nolton
|
|
|
Message #116396
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
WS is not a panacea
<blockquoteIf we are talking about a traditional OO paradigm then I agree with you. If you are talking about SOA, then no I don't agree with you. Correct me if I am wrong but IIOP is answering a different fundamental question and is closer to DCOM, CORBA and .Net remoting; so applying IIOP to what WS is trying to answer wouldn't be fair to either paradigmI think we are in violent agreement ;-) W.r.t SOA, WS is certainly a better choice, not only because of its wide adoption but also because (as you indicate) of its ability to support more than the synchronous communication model. I am not suggesting that IIOP be applied where WS is appropriate. I see the problem when WS is touted as being viable where IIOP can solve the problem much better. Are you saying that it's not fair to compare the two paradigms? Then I agree with you with one minor tweak. WS can work synchronously if you so choose. In fact, I would bet most people (including myself) do deal with ws synchronously....even though you can set it up to work asynch and get significantly better throughput.Or are you saying that you should not mix the two paradigms? What about the case where you provide a service facade over EJB/CORBA/.Net BLL components in order to provide a stateless interaction with clients?-Mathew Nolton I am saying you should not MIX the two paradigms, but use one or the other as the situation demands. While WS can work synchronously, it is not appropriate for stateful high throughput/low latency communication. Like you suggest, when exposing a service facade, you ought to use WS. Implementing that facade, on the other hand (note that the service could be implemented as a distributed application rather than some monolithic functionality sitting on the WS host) should consider using more appropriate protocols.
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
