Is there a industry standard way of packaging and deploying web services which can cater to following contraints/Complexities
Web services are developed in different location and ultimately deployed on common site
This should take care of versioning ( Side by side web service deployment)
Client side versioning issues
There are none.
Ok, "standards":
UDDI for finding them.
otherwise have a look at http://servicesengine.codeplex.com/
This basically is a publishing front end for internal web services. So, you expose them all on one server / url (services.xxx.com) and basically can register them there, including versioning of different versions.
Related
I don't have any code yet as I don't know where to start! I see on the web that I'd need to select
on the Access toolbar external data >> more >> data services. Then it asks to point to a xml config file. Which I don't have and would need to create. I have the connection string from a VB.net application.
sWIPConnString As String = "SERVER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=fake3465-vip.ent.agt.bb.ca)(PORT=41521))(CONNECT_DATA=(SERVICE_NAME=fictitious_service_name)));uid=APP_getinfo;pwd=thispassword;"
I'd have to convert that to an xml version. Any help would be appreciated!
Thank in advance
Pete
But those data services are not just any old plane jane web site. They are web sites that have installed, setup, and the developers of those web sites setup that data service connection. And these custom connections are NOT general web sites, and they are not general web services that many sites have. And they are not a web API written around say SOAP or some REST standard.
So unless that web site decided to adopt this Microsoft specific means and method to expose data, then you not be able to use this feature to simple connect to any old web site out of the blue. If you have a existing web site that exposes some web services? Then you have to use MSXML and consume that web data yourself. That option in Access is not some general purpose setting or feature that allows connection to any old web site - only ones that have created that web service written to the business connection options that Microsoft created.
It not clear if you planning to create some web services on the target web site (that would assume you're the developer of that web site), or you trying to consume existing web services that the given site exposes. Even in this 2nd case, those exposed web services or even REST calls has ZERO to do with the feature in Access.
so that feature is of only use for connecting to web sites that offer specific created connection based on that standard from Microsoft - it not a general web service consuming feature built into access and you can't use that feature as such.
How to make a web service call from Access? Well, it has ZERO to do with that feature. Here is a MSXML exmaple:
How to use XML web services in Access2007 which are built on Visual studio (2008/2010)
I have an ear with quite a few web services. I'm now at a point where I need to expose a couple of them to a 3rd party. To manage the connectivity I was going to create a virtual server however it seems I have to make the entire ear available.
What I'd like to do is create virtual server and say it only has access to these few / specific web services.
Using Glassfish 3.12
You must implement an authentication & authorization mechanism in your web services, so only allowed parties can access them.
I need to create a web service to collect data from my customer’s applications.
Those applications are programmed with different technologies and they all have one thing in common: they can consume plain SOAP Web Service.
I already have a WCF Service that could be exposed but as it was built for internal purpose only, I never had to secure it.
I did read a lot of articles on how to secure WCF service and how to consume it from a Microsoft client application. However, I'm really concern about the customer’s non-microsoft applications abilities to implement a standard WCF Service security. I must keep in mind that some of them might be stateless and unable to hold on to a session or anything that might be required by a secure WCF Service.
So here are the options I have right now.
1) Add username/password parameters to each WCF function and perform a credential check on every call. (I do have an SSL certificate... is it enough to consider this option as secured?)
2) Drop my WCF Service and create a plain SOAP Web Service with username/password parameters as mentioned in option #1 to be closer to my customer’s applications capabilities.
3) Implement standard WCF security and let the customers find a way to deal with it on their own. (The real question here: is WCF security simple enough to be implemented by any SOAP client?)
4) Change my name and move to Jamaica with my customer’s money before they find out that I’m a Web Service security noob.
5) Something else…
So what is the my best option here?
Yes, I can offer the option we use. It sounds like you want basicHttpBinding.
We have a WCF web service using basicHttpBinding and set IIS to use basic http authentication.
Therefore non-.NET clients can consume it easily (basicHttpBinding) and we can give them an Active Directory domain account that allows them access via IIS. No usernames / passwords to constantly send back and forth through the web service and it runs over HTTPS for security.
It's currently being consumed by PHP, Java and .NET clients. Yes, .NET clients can still import this as a service reference which makes thing like trapping FaultExceptions easier.
No solution is perfect for everyone but works great for our needs.
Yes, but certain configurations favour certain vendors. See the WCF Express Interop Bindings project on CodePlex:
http://wcf.codeplex.com/wikipage?title=WCF%20Express%20Interop%20Bindings
They offer settings for interop with:
Oracle WebLogic
Oracle Metro
IBM WebSphere
Apache Axis2
The Oracle Metro (previously known as SUN WSIT) stack is by far the most advanced as regards the WS-*/Oasis standards.
Say I'm building two applications:
1) A public website
2) A service
The website can be accessed, of course, by users.
The service can be consumed through a web API, but will also be consumed by the website.
This means that common functionality can be put in the service only, rather than having it duplicated in both the website and the service.
Now, when deploying this solution, there seem to be two options:
1) Have the website directly reference the web-service, and deploy both binaries to the web-server, running in the same process.
2) Have the website reference the web-service through the web API, just like all the other consumers. Have the service run in a separate process.
Option 1 would probably be faster for performance, but would require having the two DLLs deployed separately.
Is there any way I can have option 2 (separate processes) but still link the Website to the Service directly, to avoid network latency, serialization, etc?
What technology are you using for your web service? If you're using WCF you can use the NetNamedPipeBinding for your website which is almost as quick as using a dll directly.
I've very new at WCF, and I'm creating a prototype application to learn, which might turn into a commercial application. I understand the very basics of WCF, and I have my application WCF functional, at a basic level.
What are some tips experienced WCF users can give regarding pitfalls and steps I can take to make the app rock solid, at least regarding the WCF layer?
Couple of points to ponder:
make sure to implement rock-solid exception handling on your server side - implement the IErrorHandler interface on each service, define proper fault contracts
make sure to enable WCF tracing on the server side - those message logs are eminently useful when diagnosing problems!
make sure to think about versioning - make sure to use namespaces for both your service contracts and data contracts that will allow you to distinguish later version from the older ones (by means of the contract namespace)
think hard about your production hosting - IIS seems like a logical choice, but it's typically plagued by too many issues and problems that you don't have if you self-host. It's a bit more work yourself to create all those hosts - but it pays off with increased stability and better control on your side
Use security for your web service, particularly those bindings that support digital certificates.
Ensure your web service is interoperable with other web service frameworks, so that potential clients do not necessary need to be created using .NET and WCF.
Allow for endpoints (methods) to be retired in case they become obsolete. This allows clients of your web service to be informed of these retired endpoints so that they can be updated accordingly. Your retired endpoint could inform callers of what endpoint they should be using instead.
i am new to WCF but i learn this recently and thought to share with you.
if you are hosting your services on IIS then its best practice to make this a new account that you can control the direct privileges too, since NT AUTHORITY\NETWORK SERVICE
uses the default and can have a bit higher level of permissions. You can change this under the Application Pool in IIS that your website hosting WCF is running as.
my2cents