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.
Related
In OutOfProcess hosting model, there are 2 web servers i.e. one internal web server and one external web server. The internal web server is called Kestrel and the external web server can be IIS, Apache, or Nginx.
When Kestrel is the cross-platform web server for the ASP.NET Core application, and support request from all platforms, then what is the use of external web server?
The IIS or apache contains a lot of advanced feature. For example, advanced logging, GUI ,failed request trancing and other feature. It is very easy to configure and find the logs more easily.
The Kestrel need all settings by the codes and if you need special feature, you need to develop by yourself or changing the codes.
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 a number of WCF 4.0 rest services on an internal application server which are accessed from a DMZ'd public facing web server. Essentially I am looking for the simplest way to restrict access to the services to calls from the web server and select internal accounts. It seems like a simple task of which I can find no simple answer.
Info:
IIS6 for both the web server and the application server
.NET 4
Web Server is not a part of a trusted domain
REST Services are 100% code.
Client calls are passing credentials via System.Net.CredentialCache.DefaultCredentials ( not sure if this is the way to go )
For the network part, you can disallow all IP's except the one of the ones you trust in IIS.
I have two questions I hope I can get an answer for with regard to my service oriented application
I am creating a service oriented application where controls have no events, it's all done by calling services... that means the service url is written in my jQuery code, but this seems somehow not nice.... It's like what is the best option to save service urls?! I feel it's hard to maintain and not secure when it's written inside the page or inside javascript referenced file.
I am talking to a hosting company and they told me that I can host this application services on cloud server and the application on another servers.... not all in the same server, but my application services are self hosted, I mean the services are inside the application.... so to make things work as my hosting company wants, shall I host the restful services in IIS or how exactly?
Service URL must be in your page or script source file. It can be local address unless you are using cross domain calls and JSONP - cross domain calls requires absolute address. It is the same as any other web technology. If you want navigation to other page, you must provide URL. If you want some picture or css file you must provide URL. Security is up to you.
This will be the problem of cross domain calls. Normally JS calls can be done only to the same domain where the page is exposed. Once the application server is exposed on different domain name your calls will not work. To avoid that you must use JSONP (WCF 4 has support for that). Exposing rest services consumed by your application from self hosted application is strange. REST services are consumed by your clients - they are front-end services and should be part of your application hosted on front-end web server. Your back-end application server should not host anything directly accessible by your clients.
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.