|
|
||||||||||||||||||||
| Home > SOA News > Part II: Rushing to the .NET | |
| SOA News: |
|
||
Our .NET Web Service Giving it about 10 minutes of thought, our development team came to conclusion that it would be faster and easier to develop a Web Service using Visual Studio.NET to let the Partner interact with the system. A big question was "Will the Partner agree?". It took about 5 minutes to get a response from the Partner to say "Sure, let's do it". The Partner's developers were actually surprised that another firm would offer developing a Web Service for them. Our payment web service allows the client to create and populate Order and Customer objects, then pass these objects as parameters if a Web Method to our server via SOAP. Most of the properties of these objects are String and Double data types and the order line items are in a String Array. Reusing some code and logic from the website and creating about five VB.NET classes, it took about a week to put a prototype together and within another two weeks we were ready for testing. Orders are passed into our order processing web service from the partner. Credit card information is validated and authorized if needed, and a status object or nice error message is being passed back. We did have some problems with an array we were passing but switching from the old-style VB 'UBound' function to the new OOP style 'Length' property solved most of the problem regarding this issue. In the process I rebuilt our test client using C#. A rather simple task, but it was the first time I had to use this new language and the biggest problem was finding information and sample code for a Web Service Client in C# (which we never found but after a couple of hours had everything working). Since the code is object oriented and compiled, we have run into a few very minor bugs but other than that, things have gone very smooth. We also hope to offer order status, shipping and possibly an order tracking web methods as well to provide the partner with greater functionality. Eventually, the e-tailers own web site and accounting programs can use this Web Service and all order processing can be done in one place or at least with one code base. For stability and performance issues the .NET services are running on another server not to tie up the regular web servers with additional processes. Security, authentication to be precise, is still an issue but with strong application security and SSL, I feel our application is very secure and scalable, offering partners a means of submitting orders without worrying about the 3,000 anonymous visitors browsing the web site. Copyright 2001, Reprinted by permission. FOR MORE INFORMATION: Talk back or comment on this articleThe Best Web Links for Web Services Free Tutorials for Web services, SOAP, UDDI and more
'); // -->
|
|
|||||||||||||||||||||||||
| About Us | Contact Us | For Advertisers | For Business Partners | Site Index | RSS |
|
|
|
|||||||