I am a .NET developer and I have developed a software for an organization in which there are 2 other different software applications. All these 3 applications are isolated and they don't send and receive data to and from any other software.
The organization's manager asked me to integrate these products.
After some research on the internet I found that I have to use BizTalk. Now I have some basic knowledge about BizTalk (like what are Schema,Maps,Pipelines,Orchestration etc).
The problem is that I don't know the changes I have to make for my own software and the change I have to ask the other developers (of the other software) to make in their own software to be able to integrate them via BizTalk.
Shall we make web services for our software?
Is that possible to connect directly to databases? Is that a good practice at all?
Any other suggestion or resources will be very appreciated.
Since this a very broad topic, I'll stick to answering your specific questions:
Sure, this is frequently called a Web Service Facade. It's most useful when many different apps will be calling into it.
If you own the apps and their databases, yes, this is a perfectly valid solution. BizTalk connects natively to SQL Server and Oracle as well as other databases through an ODBC Adpater.
You could also program your existing apps to emit and consume Xml messages.
Related
So I'm pretty green to the industry, please excuse what I'm assuming is huge swaths of ignorance. I'm looking to develop an ASP.NET webapp (with a SQL Server db) as a kind of in-house tool for our employees, accessible from anywhere. We're a company with virtually no IT infrastructure, so these employees (~100) will be accessing this application from all around the country on what are basically personal computers. I don't ever expect there to be any more than 10 users using the webapp concurrently. The web app is going to be the frame for a series of tools I've been making for the head office guys, but from a central point that's easy for me to maintain.
We have our own domain, so that's taken care of.
I'd like to find a cloud-based tool that would pretty much just involve me deploying my code to it, and that's about it. I've take a look at Azure and that seems like the way to go, but I know if I present a price too high the bosses won't exactly be thrilled.
I was hoping some of you guys had some experience in setting these kinds of things up. Here's a series of questions I'm having a hard time coming up with an answer for:
Looking at the Azure cloud-based webapp, What da heck specs do I get? Is Standard S2 too much power, or nowhere near enough?
Do I need to purchase an Azure SQL Server thingo seperate to the Web App hosting, or does it come bundled in?
How the heck do I deploy my dang code?
I've been getting off pretty easily as I used to have a team behind me, and now I'm alone at a new company, there's not many people whose brains I can pick. I've had a call or two with a Microsoft employee, and they were helpful, but not entirely helpful enough. They keep assuming I know what I'm doing - I don't. So any help from anyone would be greatly appreciated!
You need to learn two services of Azure:
1.Azure Web app service:
Azure App Service is an HTTP-based service for hosting web applications, REST APIs, and mobile back ends. You can develop in your favorite language, be it .NET, .NET Core, Java, Ruby, Node.js, PHP, or Python. Applications run and scale with ease on both Windows and Linux-based environments.
This document will teach you develop web app with Azure SQL and deploy your app to Azure.
2. Azure SQL database:
Azure SQL Database is a general-purpose relational database, provided as a managed service. With it, you can create a highly available and high-performance data storage layer for the applications and solutions in Azure. SQL Database can be the right choice for a variety of modern cloud applications because it enables you to process both relational data and non-relational structures, such as graphs, JSON, spatial, and XML.
Azure SQL database is a cloud database. If you have the develop experience with SQL server, you will be familiar to it.
Azure App Service and Azure SQL database are independent, in Azure, which service you want to use, just pay for it.
You need an Azure Web app service to host your app, and you also need a Azure SQL database. Then you can develop the app with Azure SQL database.
Each service has the different price tier to meet the performance requirements of the user. You need to choose the most suitable for your company to save the money.
Hope this helps.
I have a Delphi Application with a Client-Server Architecture. Now, I want to write a Web-application for this Delphi Client-Server Application.
To write a this Web App I don't want to use Delphi - I want to use a "modern" Web Architecture like a PHP Framework, ASP.NET, Ruby on Rails etc.
So far i came to one possible Solution with RemObjects (http://www.remobjects.com/ro/) and ASP.NET:
In this approach the Delphi Application communicates with an ASP.NET WebServer over RemObjects where the Delphi Application is the REM Objects Server and the ASP.NET App is the Client.
My questions are:
Is this approach really a good idea and if not why?
What are other possible approaches to solve this problem?
Thank you for your help.
Edit:
Thank you for your answers so far!
How about establishing a neutral link like a Database?
You need a two-way messaging / inter process communication solution. Typically SOAP, REST and other web services (RemObjects) are synchronous, request-response style communication.
A messaging middleware can be implemented in a way which totally decouples the applications so that you can restart any part of the system (for example for maintenance and update installation) without disturbing the others.
Popular open source products in this field are for example Apache ActiveMQ, Open Message Queue and RabbitMQ, which offer cross-platform/cross language clients.
An alternative could be SOAP, or a RESTful connection.
R/O is faster than SOAP, for sure, and well integrated to both sides (Delphi and C#).
And, since you are already using R/O between Delphi client and Server, it will be the first option to consider.
IMHO any RESTful connection between Delphi Server and a C# client may do the work also. And will probably be faster, so is to be considered only in a second phase, if you find any performance or stability problem with a R/O connection.
I have to write an app for iPad that would take data from SQL Server and post it to the iPad. I looked up on this over the Internet and found that i have to write a web service to expose the data from SQL server using ASP.NET. I did an app previously in android that would take data from my dropbox a/c and display it to the user. I made use of the drop-box api available. I was wondering if anything like that exists for SQL? Also, i have to code in Obj-C for the iPad, so how will
i write ASP.NET code? I have more doubts.
Thanks in advance.
There are many options for web services. If you are developing in ASP.NET and don't want to invest to much time in just accessing the data I would suggest some software that will help you generate the source code.
WSSF (Web Service Software Factory) is software that will assist you in creating a SOAP web service and it generates source code for you. I do recommend however working through a tutorial first before just jumping into using this. WSSF uses visual studio as well.
Once you have a web service that packages your SQL data for communication through http requests. You will need to parse the data communicated in Objective-C. For this you'll find SudzC to be very helpful.
SudzC generates all the source code for accessing your web service in Objective-C, given the WSDL.xml file of your web service (a file that lays out the design of your web service).
Although these software will save you a lot of coding, I wish I could tell you that this will be a short and easy process. However this is vary rarely the case, developing this will take you a couple of days.
I do know that people often use RESTful web services when dealing with the iOS enviroment, although I do not have the same kind of experience with them as I do SOAP web services. I hope that this information is helpful to you.
I've done this. The best way is to use .NET 3.5 or higher to create a WCF (Windows Communication Foundation) project. These projects will let you communicate with your mobile application using REST or SOAP. They also let you send data in XML or JSON format. You will then need to create a REST or SOAP client in your IPad application to communicate with the server.
Use OData. See Creating an OData API for StackOverflow including XML and JSON in 30 minutes for how to publish your SQL Server data as an OData service. See Consuming OData using Objective-C for how to consume the OData service from your iPhone app.
I'm a (relatively new) developer using asp.net with VB.NET. Currently all my applications are developed on my PC and then are built and moved onto the web server. I'm going to be working remotely for 3 months in which time I'll be connecting to the company network via VPN. What is the best way to access my projects? I need to have the projects stored on the company network so that others can access them too. So simply copying the projects to my laptop, working on them, then copying them back won't suffice. I tried to just open the projects off of the network share but am getting application trust problems.
I'm just wondering what other developers do in this situation?
You will need some kind of source control solution, probably best if it was web based. Something like git which is very popular maybe useful for you.
WinMerge is pretty simple to use.
I have a partly developed asp.net application, but now the client wants it to be developed in azure. How much of the existing code can be used in developing the application in azure.
What challenges could we possibly encounter when we try to port an existing asp.net application to azure? Are there any other alternatives to azure in cloud computing?
For an asp.net application, you can certainly port that to Azure. Your core logic will port in a relatively straightforward manner, and you'll gain the many benefits Azure has to offer. With the June 2010 release, you'll also have .NET 4 support, along with IntelliTrace for debugging.
However, as you begin to plan your Azure migration, there are several considerations you'll need to think about (none of them insurmountable, and several relatively simple to deal with):
You have to deal with ASP.NET Session State management across your web role instances (which isn't supported out of the box, except for inproc). You'll also have to set up and use the role and membership providers (see here for more detail). EDIT: You now have access to both AppFabric Cache for session state as well as SQL Azure, part of the Universal Providers included with the Windows Azure SDK+Tools.
You have to examine your SQL backend for incompatibilities with SQL Azure (such as scheduled jobs,since there's no SQL Agent support). SQL Azure differences are documented here. You'll also need to consider the SQL Azure size limit of 50GB, which might require you to offload content to Azure blob storage. EDIT: You can run your SQL Server database through the SQL Azure Migration Wizard for compatibility-testing.
You need to configure logging and diagnostics, preferably with Trace output, so that you can retrieve this data remotely.
You need to think about how you'll monitor and scale your application. All information you might need for scaling is available to you (performance counters, queue lengths, etc.). Check out WASABI - the auto-scale application block, part of Enterprise Library. You can also subscribe to a service such as AzureWatch.
You'll need to think about caching, as there's currently no out-of-the-box caching implementation that runs across instances of your web role which is now provided as a service. Read details here, as well as an FAQ here.
Do you need SMTP support? If so, there are details you should read about here. SendGrid recently announced a free-tier promotion for Windows Azure.
Are you hosting WCF services as well? If so, check out this site for further details (specifically the Known Issues).
So: yes, there are some things you need to concern yourself with, but Azure is a great platform for hosting an asp.net application and you should strongly consider it.
It should be very easy to port your application to Azure--especially if you're using a SQL back-end. The code could run almost without modification. You'll need to create an Azure installation package for the project and configuration file.
If your application makes use of persistent storage (other than SQL Server), you may have to rework that code somewhat. However, the platform now has drive storage, which simulates a file system, so this should be fairly easy.
Another issue to watch out for is web.config. If you make heavy use of this for runtime customization, you'll have to rework that too. You can't deploy single files to your application in Azure, so the recommended approach is to migrate these sort of settings to the Azure config file.
The hardest thing you're likely to encounter is external applications. If your app relies on launching other processes, then this will require some serious redesign.
Azure now supports Web Sites as a deployment type. Basically this allows you to publish any standard Asp.net (and other supported like PHP etc) application to Azure and have it as a scalable server. See this article http://blog.ntotten.com/2012/06/07/10-things-about-windows-azure-web-sites/
Many of the benefits of Azure without having to introduce Azure specific code/Project to your existing application.
Also this question here What is the difference between an Azure Web Site and an Azure Web Role