I have a 3 tier structure in my office and my dll (in GAC) in business tier is already installed in my business component server .
Method 1: Remote GAC
I'm trying to build a light-weight application and the application will reference the dll in the remote business tier server, but I don't know how.
Method 2: old way DCOM or COM+
But I do find an old way by using DCOM (no more GAC).
http://www.kepware.com/Support_Center/SupportDocuments/DCOM_Secure_by_default.pdf
It seems relatively achievable, but after i follow the steps, I always get some security alert, such as no access.
Method 3: Web Service, too slow!
I do not want to use web service because I need fast access within LAN. web service is just too slow as it has to go through IIS.
Method 4: .NET remoting using TCP
This method seems to be faster than web service, but it seems to have a lot of overhead.
I don't mind use old technology as long as it works.
GAC make my dll more secure as it cannot be copied and used by other unauthorized people, so it is preferred.
Please advise.
I research quite some articles and it seems in order to have most of the benefit included(version control, security, convenience, pooling etc.), then
the best way is to GAC the dll in remote machine and then use Regsvcs to register the dll as COM+ service.
some people don't want so much trouble as convenience is their top priority (fast deploy, security, version control are not that essential) then they suggest I can just XCopy the dll to remote server and then just Regsvcs it.
Related
I need to migrate an ASP.NET application to Azure. The application needs database access and access to temporary files and also using out-proc COM objects. Turns out there's "Full IIS" mode that offers some rather vaguely phrased advantages (from here):
However there are a number of useful capabilities that only exist in IIS, including support for multiple sites or virtual applications and activation of WCF services over non-HTTP transports through Windows Activation Services.
Now obviously using Full IIS forces me to deal with the ASP.NET part and role part working in different processes and that's a big deal so I need to know whether I need Full IIS mode in the first place.
How do I decide if I need Full IIS mode? Is there a full checklist?
I think your default answer should be use Full IIS in Windows Azure capabilities. The hosted web core offering is really there for backwards compatibility as it was the original model prior to 1.3 SDK. Full IIS is the default and you must explicitly opt to go back to HWC.
The reasons that most people wanted full IIS were around a few, but important limitations:
Better support for IIS extensions (e.g. Smooth Streaming, Web Farm, ARR, etc.). HWC did not always support the modules and combined with a missing admin permission, made it really hard if not impossible to use all the modules that folks wanted to use.
Support for multiple web sites, vdirs, and application pools. HWC is a single app pool (the hosting process) and no way to support multiple web sites. There was a serious concern about needing to dedicate 1 entire role to a single web site. With Full IIS, you can have multiple sites and use host headers to get more bang for buck out of web role (especially with small web sites)
Support for standard tooling - Web Deploy, AppCmd, etc. don't work really well (if at all) with HWC. Anything that modified the applicationHost.config usually had issues with HWC.
WAS support. This allows you to use WCF with IIS as a host in non-HTTP transports.
In general, with Full IIS you have parity with what you do on-premises so it makes it much easier to configure and setup.
Regarding the RoleEntryPoint/HWC process model versus the RoleEntryPoint and separate Full IIS process, I am not sure that is really an issue. There were a few quirks perhaps initially, but what concerns you the most about this?
I need to consume an out-proc COM server from both a worker role and a web role in a Windows Azure application. One step I'm almost sure I'll need to do is to alter the access permissions for the COM server - grant "local launch" and "local activation" permissions for the predefined user under which roles code executes.
So far I found there's DCOMPERM utility in Windows SDK samples which contains code that I guess would do that. So I could write similar code and package it into either a separate executable or into the COM registration code of the COM server and run that code from a role start-up task. That's not trivial, but certainly doable.
I only have one major concern before I start.
Are there any reasons why I can't do that? Maybe using out-proc COM servers is not allowed on Windows Azure or something? Are there any such limitations?
Are there any reasons why I can't do that? Maybe using out-proc COM servers is not allowed on Windows Azure or something? Are there any such limitations?
It's not something I've personally done, but if you can install a COM+ server running in a shell exe, then I think you should be able to do what you want - see this recent blog post http://michaelwasham.com/2011/05/15/deploying-a-com-servicedcomponent-to-windows-azure/
I don't think you will hit limitations - but I think you will hit a fair few problems along the way - good luck.
I am trying to understand exactly an AppFabric in Windows Azure, What is the difference with Worker Role and Web Role and How to create a project of AppFaric in Visual Studio 2010, i mean which kind of project ?
Thx.
Adding a bit to vtortola's answer:
There are three core areas of the Windows Azure platform:
Windows Azure (which provides virtual machines and massively-scalable storage through Blobs, Tables, and Queues
SQL Azure (which is a large subset of SQL Server), offering a full relational database up to 50GB
Windows Azure AppFabric (a set of services that you can opt into, currently comprising access control, connectivity, and caching)
When you construct your Windows Azure application, you can really pick and choose what pieces of the platform you're interested in. For instance, Windows Azure provides Web and Worker roles (both essentially identical virtual machines running Windows Server 2008 or R2, but Web roles have IIS enabled). If you need a relational database, you can very easily set up a database. And, then there's AppFabric:
If you need to connect to a set of web services on premises, for instance, you can use the AppFabric Service Bus (a secure way to connect without having to open up a firewall)
If you need to actually connect to an entire computer on-premise, use Azure Connect (a software VPN).
If you want to cache data (such as asp.net session state) between instances of your virtual machines, enable and use the AppFabric Cache (currently a Community Technology Preview, so no pricing yet).
If you need to add access control to your application, use AppFabric's Access Control Service, which essentially lets you outsource your identity management.
There are quite detailed examples in the Platform Training Kit that vtortola referenced. Additionally, there's a complete Identity Management training kit.
Azure AppFabric is a suite of middleware services and technologies to help you develop and manage services/applications that use Windows Azure. Middleware is typically defined as software that helps connect other pieces of software, and this definition is pretty accurate for the services appFabric provides.
You don't create an App Fabric per say. AppFabric services are used by your other applications as needed, so setup is typically configuring certain items in the Azure Portal, then implementing libraries of config entires in your web/worker roles that leverage the resources.
Essentially AppFabric provides certain resources that you need when composing complex applications as services, vs. you having to implement and maintain these resources yourself.
The basic offerings are:
Service Bus: A message relay that can be consumed by other .NET technologies (and others). SB helps you connect different cloud services as well as "hybrid" services. The hybrid is a big deal, as SB helps you easily connect on-premise web services with services you run in the cloud, w/o having to mess around with VPN, protocols, server setups, certificates, etc etc.
Access Control: An authentication and authorization service, helping you manage user-level access without having to extend/implement Active Directory, LDAP, and custom user authentication modules throughout Azure.
Caching: an in-memory distributed caching layer for your applications. This is typical to memcached or the Windows Server version of AppFabric
Integration: a PaaS service of EDI/transport technology like BizTalk server
Composite App: allows the composition of complex applications using a compistion language versus just putting a bunch of code together. You basically define your application using a designer like you would a EF.Net data model or a Windows Workflow
So basically AppFabric provides you with a lot of services that you likely need, but the typical cloud developer may not want to "mess with" at least at first. This way you have these great building blocks to help you focus on your core logic/needs during development cycles while not limiting what your application can ultimately do. This "focus" is one of the core benefits to cloud computing, especially Platform as a Service, and is one area where Azure really shines compared to other offerings.
Some of these technologies are still in beta. The AppFabric site makes this very clear, but its important to be aware of.
Great place to start is the Azure AppFabric site itself, which breaks a lot of this down, gives you great examples of how to use, and some sample code for you to get your feet wet.
http://www.microsoft.com/windowsazure/AppFabric/Overview/default.aspx#top
Basically:
WebRole : similar to a web
application.
WorkerRole: similar to a Windows
service.
AppFabric: Group of services that
allow you interconnect applications inside and outside Azure.
Download and read/do the Azure training kit, it will solve those questions and tell you how to create that project in Visual Studio step-by-step.
I got a lot of theoretical answers from Google that WCF is better than Web Service etc. etc. But I want to know from the programming and implementation point of view. I am very new to coding and want to know that how do we implement all three of these technologies? How are they different and in which scenario we should used which technologies?
Thank you in advance.
A web service is an API that is hosted for access via a network connection - often the internet - and usually accessed over HTTP (or HTTPS).
WCF is a Microsoft .NET development framework that can be used to implement web services. That is, WCF-services are a subset of all web-services.
Windows services are a separate beast entirely: they are long-running programs that run on your local Windows machine, typically with no user interaction and on system accounts. They are used to handle many things in Windows, from low-level driver functionality to software updates.
You're really comparing apples and oranges. A web service is simply a program that you can "call" using the HTTP protocol. Typically, HTTP requests sent to the service contain some XML describing the method called and any parameters. The response from the service likewise contains XML with the return value and any output parameters. It's a little more complicated than this, but it gives you the basic idea.
Windows Communication Foundation (WCF) is a framework for building network services. You can use this framework to build web services if you wish. I suspect that what's tripping you up are the various Visual Studio project templates. You have one for WCF services and one for web services. The web service template builds a web service that runs inside of IIS. The WCF template gives you far more flexibility (you can make a web service as a stand-alone application, for example), but it is far more complicated.
If you're just beginning, I'd start with web service template and IIS-based web services.
MSDN is always a good reference:
Web Service Tutorial:
http://msdn.microsoft.com/en-us/library/8wbhsy70%28VS.80%29.aspx
WCF Tutorial:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
I think its always easier to learn by doing.
Good luck
I have a few WCF services that are currently being self hosted, in a very basic NT Service. I want to expand my application to add provisioning of WCF Services, and updates, as well as isolation (I want each WCF Service to be in its own AppDomain). These WCF Services contain logic that needs to be run on a regular basis, pinging the database, and getting information from external devices so that when a request comes in the data is readily available.
I'm thinking about trying out Windows Activation Service, because i really like the provisioning, and isolation that comes with a managed services infrastructure. If I didn't use WAS I would essentially have to write the same code myself.
From what I understand though WAS does not really support the model of having a service that is running before someone actually calls a method on the service. the article I read here
MSDN Article Link
states "That means in essence that out-of-the-box WAS hosting is not something that is really suited for sessionful or singleton services. It is more suitable for stateless per-call services."
it does say that "Out of the box" so I'm wondering if anyone has used WAS to host a WCF service that really behaves more like an NT Service (starting and stopping independantly of having a method called upon it).
Or any other ideas would be great. I was planning on writting this infrastructure myself, to host WCF services in a custom ServiceHost, and put their execution in a seporate AppDomain, as well as allow for provision of these services after initial installation, along with updates. However, I would MUCH MUCH MUCH rather not own that code if I don't have to.
thanks
Joshua
If you want to use WAS, it will be tricky to support a proper Singleton instance of your service.
It sounds lie what you really need to do is create a scheduled task. You could run your database update utility every 5 minutes from a scheduled task and should not have to sweat the singleton.