Understanding Web Services
Web Services. Do you get/use them?
I kind of get them. When we're talking about the kind where a site opens up its services to other websites, such as weather.com letting you fetch the forecast for the coming day(s) based on a post/zip code. Or Google mapping and Amazon web service for finding products. Those kind of scenarios I get.
When it's one website dealing with another website I can see the point and understand the use of Web Services. But what about when there's only one website involved? Are Web Services ever of use?
Although I've consumed Web Services in the past I've never had call to provide a Web Service or consume one from a site I've worked on. Hence the gap in my understanding.
Yesterday I came up with a use for a Web Service that would make my job as a developer easier, so that's got to be a good thing, but I'm just not sure whether I'm perverting the use of Web Services.
Take a look at the Flex Accounts app and you should see I've added a flag icon in the right-most column of the view. You can toggle the flag on the backend document by clicking the icon. Each time you click it a Web Service is called to toggle the flag field's value.
Tomorrow I'll talk a bit about how I came to be doing this in first place.
For now I just wondered if it's wrong to use a Web Service in this way?
Skip to the 
You can subscribe to an individual
My understanding of web services (and I've never actually created/published or used/consumed one) is that it should be used between web sites, or from an application to a web site. The application could be a Windows/Linux/Mac application run on a "customer" computer, that needs to access information from a web site.
In that regard, your Flex application qualifies, since it's a separate application, even if it's run in the browser, and loaded from the web site.
I'd say that you are using web services as they were intended.
Hi Jake
I have written a simple Web service in Domino (in a Land Property Notes app) to be called from a Geographic Information System (arcGIS), to retrieve from Domino status of a property - whether the owner has been consulted about construction work nearby.
Imagine arcGIS as a Google Map with pins, and each pin has an address, then the arcGIS app developers will "consume" the produced information from Domino that it requests by property address (unique match in both) and Domino will "webservice" the arcGIS tool with XML data about status, date of status report, etc.
Mainly, I can see web services for integration in Domino.
Paul
Hi Jake,
I've worked on a large Domino project for an insurance company where we had a Domino web front end application that needed to go and get quotes for (very large) policies from a central quote engine that ran on a JBoss server. This is exactly the sort of thing that web services are intended for. We call the service provided by the J2EE application, provide to it all of the required information for an insurance quote and we get back the premium and conditions etc.
From the user's point of view they do not know about the other quoting application running behind the scenes.
Then we also provide a web service for external insurance brokers to request an insurance certificate on an existing policy. It means that those external companies can run their own internal systems and just interface them with ours without the users having to go and re-key lots of data just for the purpose of getting a piece of paper.
Web services are a great way of talking between applications that would not naturally talk to each other. But as with all technologies, they have their place and can be over used. The old adage of "if you only have a hammer, then all you see is nails" holds true.
Matt
Paul, Matt. It sounds like you're both suggesting I'm mis-using Web Services then?
Hopefully tomorrow you'll see how I ended up using them and agree it's an allowed perversion...
Jake, in my opinion you are not mis-using it.
Today I recommend to all my customers to move to web services as an approach of interaction between business processes. When you change the flag in your entry using a WS it can be seen as mis-use of the feature but the simplicity of the feature, but your solution is correct. Now you can thing on the possibility of updating or changing more complex information with the same clean pattern.
This becomes specially useful when your application start to interact with another system (enterprises have lot of systems :-D ) and for some reason you need to update information iin your app, depending on an external workflow, the right way to go is consuming a WS just in the way you are doing it.
.::AleX::.
Web Services are great for integration with SAP, using Lotus Notes web services to SAP Xi that then transports the messages between SAP and Notes services... Hope that all makes sense. Write me if you want to know more.
I've had to create and consume a few webservices in the past three years. Generally speaking, they are meant as published (meaning public and or reusable) integration points. So, using it within a single app you can take the view that you are preparing for the future when that feature might be externally consumed.
Having been in and out with them, I think they are a slight bit overkill in most circumstances. There are published but evolving standards, and many IT organizations will adopt but customize these standards to fit their own needs, making a standard approach that works everywhere a rare thing.
At it's core though, you're creating a web service when you create an agent that accepts a parameter and returns a result. Sans grandiose standards, you've been doing it all along. Adding the flowery and formal "web services" definitions used here and there and what you effectively have is just more layers. This can be good or bad, depending on your needs. In some cases, such as a large financial company with many IT groups around the world, more formality and standardization is going to be critical. In smaller shops, it's a time and money waster.
my 2p
@Jerry Carter
"At it's core though, you're creating a web service when you create an agent that accepts a parameter and returns a result. Sans grandiose standards, you've been doing it all along."
That's pretty much the way I've always seen it, too.
Though, I now know to include "web services integration" on my resume, as well!
Jerry: "you're creating a web service when you create an agent that accepts a parameter and returns a result".
Which is exactly what i'm trying to move away from/replace. More tomorrow.
Jake, as I see it, the main difference between a Domino web service and the "agent-parameter-result" approach is the standardized, publishable API that a Web Service leverages. Of course, with XML, you can be a lot more flexible in what your web service accepts and returns, but the basic concept is the same.
Hi Jake ,
did you ever post you account.nsf db ? i can´t find it. Does it have a diff name . Keep you the great work
I agree with Matt and Paul. I think that to some extent you are misusing the web services.
I was trying to think, what would be the value to integrate your 'toggle' services to another application (see Matt comment). The only value (that I can see) is for your account app. So whilst, you have decoupled the backend and front end (which is good for future proofing - like if you want to write an iPhone app), the agent is not really providing a reusable service outside of the context of your application - it is merely a point to point solution.
For this very reason there seems to be a move away from a Service Oriented Architecture (SOA) to a Web Oriented Architecture (WOA), primarily because most of the time, what is really needed is the point to point decoupling and not the whole UDDI and routing parts of traditional web services, which does impose quite a large overhead.
I guess its horses for courses !
In either case, I don't think you are alone and I'm looking forward to the next post.
Jake, as far as I understood you are consuming your webservices localy instead of making it between servers or different "platform environments". In such a case a simply Domino agent would not fit your needs?
Jake,
Web services were created to simplify comunication between different applications. At their simplest use, they are just a standard that allows you to call a function from a different app, programmed in whatever platform, and located in whatever server, just as you would call another function in your code.
On top of that, there are standards created so that you can publish your functions, so that other applications can access them and use them. The great advantage of web services is that if you create one, I add its reference URL to Visual Studio (for example) and I just get a new class with the methods that I can call. Much, much better than having a URL that accepts methods and a Word document telling me what it accepts, what it returns, etc.
If you intend to let other apps call your web service, then the answer is clear, you did well creating it. If not, should you be using a web service just for communicating your flex app with Domino? It depends on the tools. Was it faster to develop? If it took more time, does it hava advantages that compensate for the time?
From a pure conceptual point of view, you are using it for a correct reason... just as it would be equally correct to call an Agent that returned values in JSON/XML/plain text format.
There's no direct answer as to which solution is better (agent vs web service), it depends on the context, so it's up to you to decide which one to use! :)
@Merc - I think that sums it up perfectly.
Hi Jake,
I don’t think it’s wrong no, but I agree with Jerry as they can be overkill in some circumstances. Is there a performance overhead by using them when the service is consumed internally?
I tend to work on the basis that I only expose methods as a web service if there actually is a requirement for it to be consumed externally.
As an extreme example, I’ve worked on a financial application whereby much of the data access tier was exposed as web services - this felt slightly odd as to start with all the services were consumed by the application itself, but as clients and users wanted to do more with their data (pull them into their own third party applications, build their own user controls, use within reporting services etc) the services allowed them to pull (or us to push on a schedule) the data in and they could use it as they needed.
(I work on a .NET platform most of the time but I guess the principles are the same. Been lurking on this blog for some time, but never posted – Jake I think our wives work together! She mentioned what you do and I looked you up).
Mitul
Hi Mitul. I recognise your name. Are you Nim's other half? Nice to meet you finally (even if it is virtually). Hopefully we can meet in person at some point as I don't know many techies in the real world and it's always good to talk shop with real people. I'll get Karen to arrange something...
Yep I am. In fact I think you guys are coming round next weekend for our little ones 1st birthday.
Anyway, slightly off topic, but we'll catch up then...
Cheers,
Mitul
First I've heard of it Mitul, but then I never get to know what I'm doing until the last minute.
I always factor in the necessary SOAP encoding/decoding necessary to process a web service.
Typically, I only offer up Web Services when other non-domino groups ask for my data or request calendaring and scheduling functions.
hi Jake,
My answer on this: it depends. It depends on the architecture of your application. For example, it is perfectly common in the J2EE and .NET world to have the UI of an application talk to a web service within that same application, which then talks to the data access layer which then talks to the database. It is kind of a heavy approach, but for a big application that is also integrated into other applications it can make sense. In "lighter" platforms such as Domino and PHP this is not so common at all, yet definitely possible.
In short I think it definitely is not a misuse of web services. It's just an abstraction layer or extra protocol through which you expose functionality or data. Misuse comes into play when you have "leaky" abstraction, meaning that you provide multiple entry points into your logic or data (for example one via a web service and one via an agent directly) that behave differently or bypass things like validation.