Web Services are clearly in the minds of most technical architects and developers, and as general issues about the use of uniform protocols and contracts are being settled, more specific questions arise. In this article, Johann Dumser considers differences between internal and external Web Services, and attempts to suggest answers to questions such as: What are the respective effects of implementing internal and external Web Services? And which type of Web Services will dominate in the future?
- Posted by: Kristin P?lsson
- Posted on: August 15 2001 11:27 EDT
Read Article Here
- I think internal first by Billy Newport on August 16 2001 10:26 EDT
- Internal or External Web Services? by Brian Connell on August 20 2001 08:17 EDT
- Internal or External Web Services? by Andy Grove on August 23 2001 03:40 EDT
I don't agree with the article, I think internal use will lead rather than external for now given the complexity of external ones (not technical, I mean legal, paperwork, contracts etc, the hard stuff). Although, some times getting two depts to work together in a company can more difficult that getting two seperate companies to work together!
Web Services (RPC+BPM) looks like an attractive way of approaching integration in a .Net/J2EE agnostic fashion in biggish companies. The biggest inhibitor is companies figuring out or being educated that workflow/business process management can help them integrate applications rather than the common perception that it's only good for the traditional use of helping automate paper pushing. It's quite a leap for developers used to a synchronous way of working to get their heads around.
I really think that this integration/internal market is the one it'll thrive in initially, but hey, if I had a crystal ball I'd be rich :-), I guess it's a case of "wait and see".
I am by nature a skeptic, so my opinion of Web Services might be overly pessimistic. That said, it seems to me that , though I am sure that many people will be using this technology for internal projects (as well as external), I don't see what web services provides that is not already available to developers. For a long time, programmer's could use edi files to send information back and forth and expose remote services(whether they be internal or external) irrelevant of what language they choose to write them in. How often is this done? Though web services makes this process easier to some degree, I don't believe it makes things that dramatically simpler that, hype aside, people will use them much more than they have used flat file based services.
Most of the systems I have worked on are independent programs that primarily interact with a user, not other existing programs. There is a need for systems to work with each other, but these integration tasks are a smaller part of what most systems developers do as compared to developing new independent systems. For example, if I am a company build an e-commerce site, perhaps I would interact with a credit card authorization service through SOAP, whereas before maybe I would have used an edi, but for most of the rest of my app I would not consider using it. Why? Because there is no good reason to to use a distributed service where clustered web servers talking to a database over odbc/jdbc will work just fine. If I were to write my web sites entirely in web services, I would just be adding a huge amount of overhead with no tangible benefit. This view applies for the use of EJBs as well, which to use on any regular old website (such as theserverside.com) would simply be unnecessary and adding needless overhead. Once all the hype dies down, I believe most developers will return to what they are doing now: building JSP-Servlet/ASP/CGI-perl based websites. SOAP is another nice utility, but it will be more of just another tool in a developer's box rather than their primary architectural platform.
I actually agree 100% with most of what you're saying. I think we'll see two types of component being developed going forward. Homogenous components such as J2EE applications, .Net Applications and legacy ones. These are applications built on a single platform, i.e. all J2EE or all .Net. Legacy applications are included in this set. Web Services does not invade this territory for me (except for .Net where MS seem to have bet the farm on it). I see most comms in these applications being RMI/IIOP or what ever the native transport happens to be.
I also see hetergenous applications, applications composed from a set of homogenous applications. This is where I think Web Services aka Service Brokers are useful and will find a place.
Most developers will only have limited exposure to web services, i.e. they will know how to use their platform, say WebLogic/WebSphere to expose their application using a set of WSDL endpoints but largely, except for this 'adapter/bridge' the application is unaware of web services.
Integration staff will be the ones taking these applications and assembling them together as a larger hetergenous application. This is the value add of web services. If it's just another form of RPC like I see most people saying then it's fluff, there is nothing in that we didn't have before.
I think by mid 2002 we'll start seeing a choice of products from the major vendors that may allow this hetergenous applications to be built much easier than before.
A company that hooks up it's suppliers in a supply chain etc is just another larger example of a hetergenous application within a company. It's the same thing really, just comms take place over the internet and not an intranet.
Or maybe, I'm just making a lot of hot-air, who knows.
In my opinion, internal Web Services will dominate initially, and not just in the larger organisations either. This is because it will be incredibly easy to develop and use Web Services, and much attention will be given to ensuring that the correct standards are developed and adopted, without being abused by large organisations or made proprietary.
Having lurked on the edges of many articles and conversations, I have the impression that a lot of people are missing the point about Web Services. I believe that the 'Web Services Breakthrough' is the fact that the industry has a simple interface definition language (WSDL) that is flexible and removed from any particular technology, application or operating system. Using a standard interface definition across multiple technologies means that it is easy to connect systems together, no matter what technologies are being used.
In my opinion, the delivery protocol is of much less importance, and especially SOAP. SOAP (+XMLP) is being touted as a brilliant delivery protocol, mainly due to it's ability to pass through firewalls without any heavy-duty configuration tweaks. And that it is based on XML, although I am less sure of the concrete good reasons why this is percieved as 'a good thing'. Again, the best thing about SOAP is the fact that it too is removed from any particular technology, application, or operating system.
That makes two abstractions :- Definition and Protocol.
But they don't depend on each other. Why would I use SOAP within my organisation? It's far too slow and cumbersome. I'd rather only use SOAP when I need to pass through a firewall to the external internet, whereas within my organisation I'll stick with something else like RMI/IIOP. But I want to have a choice too .. for example I don't want to create a Web Service that can only be delivered over SOAP. I want the same Web Service to be delivered over multiple protocols, including IIOP, RMI/IIOP, SOAP, XMLP, ebXML, etc. And I want the behaviour of the Web Service to be easily managed, regardless of what technologies deliver the Web Service, or do the work behind the interface.
That's the third abstraction: Behaviour
And I think that the fourth abstraction may be: Web Services
That is, it's not a technology, but a service that is managed and delivered completely independantly from a particular technology.
WEST Global http://www.westglobal.com
"mScape - The Web Services Management Platform"
At Cape Clear, we see the majority of our customers implementing Web Services internally today although once the technology has been proven, we expect an uptake in deployment of external services.
The value proposition for using Web Services internally is that it is a much simpler way to integrate applications. Existing J2EE and CORBA systems can automatically be exposed as Web Services and then leveraged from Microsoft-based technologies, such as VBScript, .NET, etc. This allows companies to make better use of widely available skills (there are plenty of VB programmers out there).
We have started to post case studies of some of our customers to our web site. This may be of interest:
The next release of our product, CapeConnect Three, includes a full private UDDI repository allowing the full benefits of Web Services on internal networks.
Cape Clear Software, Inc.
email: andy dot grove at capeclear dot com