Getting to grips with Biztalk, but still a newbie. What is best practice on when and why to create a new application?
As way of an example I'm creating a connector which syncs between a CRM and a web based marketing tool. I'll be polling the CRM and polling the webservice checking for updates in each to keep both in sync. Should all this be deployed in 1 application with independent orchestrations running, or as 3 applications one for CRM one for the webservice, and one to reference the common schemas between both?
My recommendation is to organize the app along the lines of a Deployment Unit in both BizTalk Administrator and Visual Studio.
So, there would be a 1:1 relationship between the Solution and Application and your normal process would be to Deploy the entire Solution to the Application every time.
This also goes for how the Projects are organized. For example, I'm not a huge fan of shared Schemas because of the Deployment obstacles.
Keep in mind though that BizTalk Server Standard Edition has a 5 Application Limit.
Seems this is not straightforward. See
http://multishoring.info/corporate-news/biztalk-application-%E2%80%93-what-is-it/
Biztalk Applications structure how-to
Also in the excellent Pluralsight course BizTalk Server 2013 from Ground Up: An End to End Scenario the author MH separates EACH project (already split by business process / artefact into a separate Biztalk application. For 1 'solution' there are ~20 separate Biztalk applications.
It seems logical to split by artefact in the VS solution, but then to deploy into a common Biztalk application, whereas deploying one application per project could quickly become unwieldy or impractical (especially as stated a 5 application limit). Thoughts on the pros / cons of each method?
Related
Are there any good books or websites on this subject covering subjects like:
different migration scenario's (big bang, module for module, function for function) pros and cons
do's en dont's
tooling
handling customer expectations
We have a rather large winforms based product which we would like to migrate to the web. Migrating in a 'big bang' scenario would probably take at least two years. We're looking for alternative scenario's.
I'm especially looking for ways to handle the inbetween scenario, what options do you have to keep customers happy.
Let them use the windows application at the same time as the new web
application?
Let the windows application use the new features from the web
application via a service interface?
Accept the cost of double maitenance for a while to keep customers happy?
You are more likely be doing a complete rewrite. Because web is conceptually different from windows forms, there would be a lot of changes.
Your best bet is stop new development on windows forms app. Start writing a new app for the new features. Then start moving one isolated feature at a time to web.
You have two options for the UI
webforms - matches closely with windows forms model. If you are
using any 3rd party controls like devexpress, you can find the
equivalents in webforms.
mvc - It is more like re-architecting the whole presentation layer.
If your UI layer is already separated from business layer, then it
would be a good choice to go down the path of MVC. However the
development experience is totally different from doing windows
forms.
State
Maintaining application state is comparatively simple in windows
forms. In webforms you have viewstate to do that for you. But you are going to run in to rude shocks as you run into limitations of viewstate, especially when it gets too large.
In MVC, you are completely responsible for maintaining the state.
New skills
You require new skills to mimic state-full scenarios
Strong understanding of javascript, ajax, at least one javascript
framework like jquery. 3rd party commercial tool kits can ease some
of these pains.
Depending on complexity you might need web application frameworks
like Backbone.js /Knockout
Expectations
It would be very expensive to achieve the same responsiveness as windows app, as you will be messing with multiple technologies. Probably your users are going to hate the new app initially. Having skilled web designers on staff is very important
Based on our own experience with moving applications from desktop to web: carefuly inspect the architecture of your winforms applications and if possible - try to provide a web interface at the service or persistence level so that your windows applications use web services instead of directly talking to the database. Then you can let your users launch desktop modules from the application server using clickonce.
Such approach let us move to web quickly and users got the same GUI and a new way to access the application. In fact, it took like 3 or 4 months to redesign existing applications so that they use web services.
Then, we were replacing modules one by one, implementing them as web applications and maintaining both (clickonce and web) for a short period of time so that users were able to get used to new modules.
The migration of consecutive modules from clickonce to web was prioritized in an obvious way - we've started from modules that were used by most users. In fact, the initial release of the system has only one web forms module ready and remaining modules are being replaced for over 2 years now, one by one.
Can I convert a non-MVC asp.net application to be Azure compatible ? Or If i want to create an Azure web application, should it be MVC one ?
The other answers answered your question about converting your app to MVC for deployment to Azure (you don't need to).
If you're creating a new web application and go with ASP.NET MVC (which I'd recommend), just remember if you go with MVC3, you may have to make some of the MVC3 DLL's CopyLocal for your deployment, as it won't be part of your web role instance. At least that's how I still understand it. The 1.4 SDK of the Azure SDK doesn't have a MVC3 Web Role template yet.
See this post on steps to get your MVC3 app Azure-ready.
Hope this helps.
You may take a look at the following blog post for migrating an existing ASP.NET application to Azure. It should not necessarily be an ASP.NET MVC application. Any ASP.NET application will work.
azure has 2 roles
1. a webrole
2. worker role
web role is nothing but an asp.net app. so no need to convert it into an MVC app just any asp.net thing will do fine
Yes, you can. But you need to be aware of certain limitations too, none of which were mentioned in the answers already given:
Your application should be stateless, unless you are running a single instance (for most apps 99,9% reliability is OK, but there are some where you want 99,95%, so you need at least two instances + it gives you additional benefits of a load balancer, etc.). The reason for this is that if you have more than one instance, the load balancer will deliver the request to a different instance. You can use AppFabric Cache to solve this.
You don't have a file system - this is not entirely true, but in reality you should never rely on having local files. All you image uploads (e.g. user profile pictures) should be uploaded to a blob storage and linked to there. How you do this is another matter, and one that can be approached differently depending on the architecture of your existing application. You can get away with files, by using Azure Drive, but it's slow as hell.
No Event Log / RDP - this is also only partially true, but you should rely on other ways of getting diagnostics information from your role. While you can RDP to your role instance, there are better ways (e.g. Azure Diagnostics storage).
Database should be chosen carefully. Sure, you have SQL Azure available, but it's expensive (1 GB = 10 USD/ month). If you can get away with stuff like Table Storage, you may save on some costs. Again, this depends a lot on the architecture.
As for the second part of your answer. MVC as a pattern is nice. It saves you a lot of time, it's much more adapt for the Web as WebForms ever will be. The event based system was designed for Desktop applications, and it was forced onto the web. However, going to Azure does not imply a requirement to go to MVC. What I suggest you do however, is treat it as a nice jump-start opportunity to look into MVC and see how it could help you write your apps better & faster.
As with any other case involving architecture of apps, it depends. If you used common patterns (e.g. IOC, Repository), you will have a really easy time moving any app to Azure.
I have a pretty specific scenario that I want to do and wondered how you'd go about making the decision on how to proceed with an ASP.NET solution.
The info:
The existing application is in Classic ASP.
The application runs on IIS on a Windows Server 2003 against a SQL Server 2005 database.
The application serves 3,000 students per semester; they submit papers at certain dates, which is when the peak load occurs.
The application needs to support roles that are determined by semesters. Steve may be an instructor for fall, but not in the spring.
The server runs ASP.NET 3.5 in addition to Classic ASP.
I'm the sole developer.
I know Webforms, and the development cycle is tight so it precludes me from learning MVC. I'd like to continue with webforms.
The major activity of the site is receiving submissions, grading submissions, and getting them back through instructors to students.
The focus of the system going forward is tracking and reporting and monitoring.
I'm the sole developer, dedicated 100% to the job. The last major ASP.NET project I did was in 2.0 with C#.
We don't have a tools budget, though I have Visual Studio 2008 and some older Red Gate SQL Tools running.
Given this scenario, how would you go about determining whether customizing an existing open-source CMS, pulling a framework from elsewhere, or building up something simple from scratch is the best solution?
You can mention possible frameworks in your answer, but for the sake of longevity of the question, I'd also like to have thought processes and determination be the important part.
Point 7 - wrong approach. You will likely spend MORE time for your first complex form in webforms than to learn MVC ;) Going through the same here at the moment.
11.We don't have a tools budget, though I have Visual Studio 2008
What budget do you need? MS pretty much gives tools away for nearly free to education entities.
I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.
For clarity when I mention tiers in my question, I am referring to physical tiers (i.e. different servers for presentation, application and database)
My company has a public facing website that is currently built as a typical 2 tier system (web server and database server).
Soon a project will start in which we will be re-writing the whole site. We are required to split the project across 3 physical tiers. Actually, when you consider the browser then you could consider it 4 physical tiers.
In my experience most asp.net applications are built on 2 tiers. The web application itself may have several layers but physically it is deployed to two servers (web and DB).
I have searched for examples but it seems that layers and tiers get confused. I see a lot of multi-layer examples but no multi-tier examples.
In a nutshell it would seem that the web application makes web service or WCF calls to the application layer that marshals data to and from the database using ADO (or L2S or EF).
Does ASP.MVC help achieve this? Does it make it any easier or just different?
Is there a good reference or example of this somewhere?
I don't think adding another tier increases security, but it definitely slows down performance and significantly increases development cost and complexity.
In the end, you can partition your application with an additional tier anyway you want. If it were me, I'd probably create the dumbest pass through tier I could if I was given this "interesting" requirement.
In fact, managing security around another tier implies significantly increased opportunities for security holes to be accidently exposed.
ASP.NET MVC should have no impact, but you will likely end up using something like WCF. For marshalling data back and forth, you probably want to use DTOs which are not tied to any particular database or ORM.
This is not a situation I'd be happy to find myself in. Increased complexity does not lead to increased security.
Gday Rick,
I work for a company that has the same multi tiered policy due to security.
I have an ASP.NET MVC web application on one tier that connects to a application tier that a web service sits on and is basically a facade for the database and a mainframe. Pretty much exactly the same as your setup.
ASP.NET MVC makes it really nice and easy to use this setup because you can easily build a validated object model in your ASP.NET MVC application. Once the object passes all top end validation you can easily transfer it on to the application tier via a web service.
I suppose this would be easy to do with a classic ASP.NET application however I think MVC makes things a lot easier!
Check out my blog for an example of how I have validated my models before sending to the application server.
Cheers,
Michael
In my opinion ASP.NET MVC isn't going to help, or hinder this scenario. Basically you'd going to have your model exposed not as Linq2Sql, the Entity Framework or any other ORM but from the middle tier, probably by WCF.
This presents the usual challenge around authentication and authorization - namely how does authentication flow between tiers., but that's are unique to MVC, a WebForms solution would have the same sticking points You'll also lose the model validation bits that an ORM may supply and will have to provide that yourself in your web services repository, but that's just a matter of implementing the right interfaces.
This is an odd requirement. Did it come from the customer? It is possible that some customer education is needed.
I know J2EE systems can be split over three tiers, with web server on the first application server in the middle and a DB on the back end but I havn't heard of this with .NET.
As mentioned before... MVC won't really matter in this situation. The closes analogue I have is we had a financial client separate out their web services into tiers...
so something like
1) public facing load balanced web services
2) web services
3) application code
4) database code
I don't remember if layer 3 and 2 were physically separated (been a while) but essentially layer one was fairly thin and just threw the requests over the dmz to the inside service.
So you could probably do something similar with the web site... potential for bottlenecks, but would get you the physical separation you need.
Good Luck!