General Motors has launched far-reaching Web-services tests that, by year's end, should result in the company using Web Services to integrate its diverse internal IT assets, ranging from the company's 130,000-seat Lotus Notes installation, to multiple types of platforms, ERP packages and more. GM is currently evaluating .NET and IBM's solutions for the Web Services Platform.
This is great news, and completely validates the need and use-case for Web Services. Good luck to GM!
Read GM Hopes Web Services Turn The Key To Data Access
It is interesting to note the "internal integration" part.
I think this is going to be where web services are used the most... within large companies.
Since there is a lot of consilidation, some companies see themselves with multiple databases, and many many applications on varying platforms. WS can really help here.
Will they be all over the shop over the internet though (other than exposing the weather service)
Here are my observations....
The main aim using webservices should be to integrate the company with its suppliers and clients.
Hence the first step would be to mould the applications with in the organization as web services.
I think this would be the test for this evolving technology (Web Services) to prove itself as an alternative.
This test would drive other large scale companies to go in for this type of architecture, if this test is successful.
Thanks and Regards
Great news infact. General Motors is one of the biggest company in USA which is looking at this new technology 'Web Services' for Internal Intergration.
Infact, Web Services not only give flexibility for their suppliers and clients, it also gives them security.
Web Services is already a proven technology which is going take over all small and big Enterprises applications into its grip.
This is just a starting now, the present phase is just moulding all B2B, B2C and Enterprise applications into the Web Service models. Once this is done the real essence of Web Services will come into picture.
Using this technology is surely going to help General Motors and also other companies whoever is trying to implement this technology
Thanks and regards
While the fact that web services are XML based will help integration across previously difficult to integrate platforms, the key to whether or not the GM program works is going to be how they define their integration boundaries. And then how well they stick to those boundaries.
New technology is just that, technology. It doesn't solve your business problems for you, just your technology problems. They are completely different issues. A new technology could help make your business problem easier to solve but you still have to attack the problem from the business perspective to make sure you're actually solving a problem rather than just creating new ones for different people.
Hopefully people will look at GM's experience and do real analysis on what happens. If it succeeds, what were the keys to success and if it fails, why did it really fail?
"Infact, Web Services not only give flexibility for their suppliers and clients, it also gives them security. "
"Web Services is already a proven technology which is going take over all small and big Enterprises applications into its grip. "
"This is just a starting now, the present phase is just moulding all B2B, B2C and Enterprise applications into the Web Service models. Once this is done the real essence of Web Services will come into picture. "
Huh, this is not the miracle pill for all computer-related problems... In reality, WebServices and SOAP are just another name for stuff that already existed... Only this time MS is involved... We had XML-RPC for a while, then MS(and others...) came in, added a couple of things so that they could call it something else, and went ahead with lots of publicity. And we all know too well what resulted from it.
In fact, WebServices will be usefull for some simple integration problems. But only for very simple applications like sending an order for a part or something... But would you really use WebServices as the base technology if the response time is important? Like for interactive remote applications and the sort... Because remember, with WebServices, whatever you send is wrapped in a SOAP document so that it is standard and understood. But if the data you need to send is small, you still get a full SOAP document. So, worst case where you want to send a single byte, you're still sending a full document. If bandwidth is limited, it can be a problem... And furthermore, even if the bandwith is not limited, the response time is longer because you need to wrap that byte in a document, send it, parse it on the server-side, process it, wrap the reply in another document, send it, and parse the reply on the client-side to make sense of it... Surely you can see lots of cases where this is simply not acceptable...
You are right, but the only reason you are right is if you are basing your critique on the factor of *performance*.
What article have you read, what evangelist has claimed, and what platform asserts that Web Services are the best solution with regards to performance? None.
The hype that you hear is not due to the fact that companies and tool providers are ecstatic over the fact that Web Services is a performance enhancer. Everyone is really excited because Web Services has standardized integration.
The IT world has come to the point now where fancy little apps that connect one machine to another and one application to another are a dime a dozen. We need to put that to rest now, it's over. Been there done that. Now it's time to take our skills to the next level and demand solutions that do not require a keyboard. So when you say that XML RPC has been around for "x" amount of years so what's the big deal about Web Services, you are missing the point. XML RPC was not standardized across industry. When you say that you can make a wicked app that uses JMS or RMI/IIOP to do the same thing as a Web Service, you are missing the point.
I fully understand why some technocrats cannot understand what all the hoopla is about; but when the complementary technologies and standards such as ebXML and UDDI finally mature, perhaps we shall see the the gearshifts start to click together in harmony.
First off, I didn't say that anyone claimed WebServices would improve performance. What I said is in many cases performance issues will not allow you to use WebServices...
And about WebServices having "standardized" integration, well it's not a standard! How can you say it has standardized integration when it's not even out there yet?!? Actually, in my opinion, since they decided that the W3C process was too long for them and formed the WS-I instead, I will not consider this as a standard... I mean really, a standard invented by MS, approved by MS and promoted by MS?!? Ok, there are others involved, but most are MS dependent so...
Anyways, to wrap-up, in lots of cases, we'll still have to resort to other solutions then WebServices. And you cannot tell me that it's great because it's standard accross all the industry. Because in fact, there's not one real application using WebServices out there right now, simply because it's not ready to be used yet...
You make a good argument. But there are indeed many Web Services environments in Production today, they're just not that complex because of the reasons you gave concerning performance.
As far as the standards argument -- well, I concede that although the SOAP framework for Web Services is not the de facto standard for all XMLRPC communique, it is significant that all major players have agreed to promote it. It's not just MS --- it's SUN, CommerceOne, Ariba, etc etc etc...
Secondly, none of the standards for Web Services are geared towards stroking MS... in fact, that's the whole point of Web Services isn't it? Having an XML interface to code modules instantly seperates the reliance of platform compatibility to the said code modules. Why do you assert that Web Services is a MS vehicle?
Finally, I CAN INDEED tell you that the standardization ( or as you say, the informal standardization ) of Web Services is in fact the only reason that Web Services are great. Like you said, Web Services on a low-level functional point of view are simply XML RPC applications. The only difference is that all application server providers have agreed on ONE WAY to communicate via this XML RPC method. Ergo, it follows that the only real hype to Web Services is that everybody will do XML RPC the same way.
But I agree with you -- none of this matters until we start seeing some Web Services on Production frameworks. Before that can truly happen, the industry is going to need to agree on a standardized form of Business XML communication and also a standardized form of discovery and description of this communication. That's why Web Services will not truly take off until ebXML becomes a standard, and UDDI becomes a standard too. And if ebXML and UDDI are not good enough, then I place my hopes on Web Services' saving grace on any other standards that the industry deems fit to replace these two with. Realistically speaking, it is a pain in the rear to get together and decide on a standard, so I hope that ebXML and UDDI is allowed to push forward and mature. Otherwise, you can tack on another couple of years to the "finishing touch".
"...First off, I didn't say that anyone claimed WebServices would improve performance. What I said is in many cases performance issues will not allow you to use WebServices... "
Regrets, I did not mean to make it sound as if you had stated that. I was speaking rhetorically when I questioned where you had read this or that. :-)
"But would you really use WebServices as the base technology if the response time is important?"
Response can be improved with clustering. That is like saying online auctions are not worth it because it might take a server or two to handle the load.
"So, worst case where you want to send a single byte, you're still sending a full document. "
The point of XML is that all data is structured. To use your one byte example, what use/meaning would one byte have if it's context was lost? This cant happen with XML.
"Surely you can see lots of cases where this is simply not acceptable... "
Perhaps, but that is the cost of of a fully redundant and transactional system. If you send aroung CSV files and unformatted data, you must accept the documented and inherited problems with that format.
The question now is, does your application demand the integrity provided by WS or not? The answer is simple, yes if it's an enterprise system, no if it's not.
"Response can be improved with clustering. That is like saying online auctions are not worth it because it might take a server or two to handle the load. "
Talk about a MS philosophy... We don't need to worry about the performance, just get a better machine to do it! I won't even add on this...
If webservices are going to be the EAI holy grail, where next for MOM?
Amazing hype. A simpler RPC implementation with loads of unanswered issues...In fact, these "web services" need a serious backbone to run on. More than anything, just by having a "common language" does not solve the problem. It took years to develop proper integration methodologies using MOM or CORBA, I don't see how web services can reduce the complexity and suddenly all the applications will be able to automagically talk to each other. The phisical application integration was already a solved problem for some years now, COM-CORBA-Java bridges were available and using EAI tools companies could actually implement nice business processes. Defining these processes was actually the biggest part of the work.
What is the plus of the web services internally ?
What is the plus of the web services internally?
The plus side is that if you are using .NET or J2EE, your vendor will support your use of Web Services. It is probably their current theme. Previous technologies, whilst not being tied to either of these camps, were often perceived as being so. There maybe downsides to this incomplete technology but at least most vendors are appearing to support it.
The plus of web services internally is simplification of business processes and simplification of internal integration.
As an example: a product has a workflow engine that can be triggered by an HTTP request or a file being dropped in a folder via FTP. The workflow engine is embedded in an application server on the server side. So how should a client trigger the workflow engine on the server? FTP is insecure and is a clunky protocol with regards to notification. HTTP is better, especially since HTTPS becomes an option for serious business transactions. So you choose HTTP.
Now of course, you have to think about the client on the other end, the client side. The client will use HTTP to send business documents or other information to the workflow engine on the server side. What are you going to use over the internet when you want two vendors to perform this transaction? RMI/IIOP? JMS? You can of course use these technologies, but then there is less control on the client side if things should need upgrading, maintaining, etc. Web Services is therefore an excellent alternative. With Web Services, the only thing that the hundreds of vendors need to do is make an XML document and send it via HTTP. Any company can do this, even the smallest ones in the world.
Imagine that you own a company with hundreds of business partners of which you would like to integrate onto a workflow server such as WebMethods. Can you honestly see a scenario in which you will send off hundreds of JMS or RMI/IIOP enabled client software to each of your vendors in order for them to participate with your B2B system? Nobody would give you the go-ahead on that one, because you would be asking for A LOT of trouble. Instead, the solution is to tell each of the participating vendors to make an XML document that will comply with the SOAP requirements in a Web Services post. Any computer and therefore any company can do this. Minimum fuss. Minimum hassle.
That's exactly what I meant: use web services as integration point. I don't see exactly the entire back-end workflow integrated in "fat" clients that for example know that placing an order means sending a request to the fulfilment system, another one to billing and another one to CRM and all in one transaction...You still need these integration engines somewhere running something performant enough.
On the edges, it could be web services. I got your point regarding multi-vendor support, that could be a cost-saver.
Yes, you've got it -- the practical usage of Web Services heavily depends on the design of your application and your business processes. This is why you get some people writing here who see absolutely no benefit to Web Services, and others who post opinions that Web Services is a God-send.
Our design over here is to embed the routing intelligence *within the workflow engine*, and keep the clients as "thin" as possible. We do this because we have no desire to get involved with our vendors' system issues, integration issues, blah blah blah. We would rather just tell our vendors, "If your transaction is of type 'A', then specify that in the SOAP. If it's type 'B' dependant on 'A', that's also specified by SOAP." With this kind of design, you can see how Web Services can be positively leveraged: our vendors simply need to generate a valid XML-SOAP document containing the proper parameters, and our workflow engine does the processing, logical routing, etc etc.
We were kind of stuck before Web Services came out NOT BECAUSE we did not have the talent here to make some super-duper JMS or RMI/IIOP client; but because WE DIDN'T WANT TO. Although the idea of having a world-wide pub-sub system set up was tantalizing to the engineers and developers ( disclaimer: those developers that *could* understand the concepts of a messaging system ), it made absolutely no practical sense whatsoever to the business folk. I tend to agree with the business side on this one: Web Services made complete and utter sense to us because we were dealing with hundreds of different vendors with hundreds of different systems and ways of doing things. The last thing we wanted to do was make a really cool B2B system based on JMS or something, then suddenly have to hire a large Help-Desk staff just to deal with the problems that this project would have spawned.
Anyone who has worked inside large corporations knows that they have many disparate systems that when they interoperate do so through a variety of proprietary mechanisms and hand-coded one-off solutions. That's where they inter-operate at all.
Take this to the next stage of systems that operate across countries, in many regulatory environments, interoperating with many 3rd parties - the internet as a platform for applications. Its *not* possible to build these systems using conventional monolithic application building approaches. A new paradigm is required to develop these kinds of applications in a flexible incremental way. The paradigm we have come up with is service assembly/composition. Note the absence of 'web'. To me web means just crossing the firewall. Its not a very interesting part of the problem. Whether you use SOAP is even less interesting! Although, a common invocation mechanism is of course important.
The important change is in viewing applications and components as containers that provide services. These services will be assembled into business transactions, many of which will be long-running. Assembly will occur at the producer side, the consumer side and by intermediaries.
When I have a discussion on web services, I always establish what the other party means by web services. I then try and separate the web part from the services part. They are completely different discussions and services within enterprises and behind the firewall has to be where web services start. You *must* have a service based approach to developing applications before you can participate in web services.
I happen to think that SOAP (as synchronous RPC) is not a good solution for long running asynchronous transactions, which seems to be where web services will start to make an impact. But everyone is behind SOAP, so it will be the predominant mechanism for a while, but replacing it will not be big issue.
That's just as good an analysis on Web Services as I've ever heard.
Just curious: What about SOAP is it that you do not like with regards to asynchronous processes? Is it the idea of the HTTP protocol of which the common Web Service lies on top of, or is it the XML format that SOAP uses? Or is it both?
In addition, although I have never used Web Services on any other protocol other than HTTP, I have researched some great articles on this very website that go to pains to remind us that Web Services can be used on a different protocol other than HTTP. What are your views on Web Services in this regard?