I'm a newbie at SOAP and web services (2 day experience).
I use Bonita Open Solution as a BPMS in which I have a 'WebServer SOAP 1.2' connector. I need to get and write data from/into a database using SOAP. I don't want to use the 'SQL Server' connector which is based on JDBC because the system will be tightly-coupled.
Is there any already implemented SOAP web service in SQL Server 2008 to do that or should I develop my own? In case I should develop my own, I'm guessing the best way to do so is using ASP.NET, am I right?
Before you do anything, you need to decide exactly which data is required by the BPMS system and what access it requires. For instance, it may need read access to some data, but read and write to other data. Your service should only expose the data and operations which are actually required, and nothing more.
Your data is precious - don't expose more of it than necessary.
I recommend that you use Entity Framework in a database-first mode, but only add the required tables to the model. Then, simplify the model by removing columns which are not required, simplifying relationships, etc. Thus, you are exposing a conceptual model of your data which makes sense to the consumer, rather than having to expose every implementation detail of your database (do you really need to expose every junction table, for instance?)
It is then pretty simple to write a WCF service that uses Entity Framework to do the hard work of data access.
Even if deprecated, Sql Server 2008 has native SOAP web services (see Native XML Web Services: Deprecated in SQL Server 2008).
You need to balance the risk of a Sql Server upgrade against the cost of developing (and maintain) a custom service.
Related
My company is planning to turn an older Winforms application into a WPF/Silverlight Client/Server app.
The idea of having a small server app is to have a list of the accessible data bases combined with the user type that may access each of the databases, instead of having to manage databases in each client's admin control. Additionally, it would be great if the SQL request would be handled by the server which would then return the result.
The app is supposed to work on a arbitrary set of databases which will be "registered" with the server and users get a list of databases according to their authentication rights. They can then do practically everything on those databases what one can imagine. The system should be able to handle up to 2 million rows.
The databases are very different, there can be many of them, they can be MS Access, Oracle, SQL Server etc., so no way for me to specify them all before. On top of that, communication with a SQLite cache is needed.
I already have everything I need for the SQL queries from the Winforms app.
I was thinking:
1) A simple WCF server specifying in a config file the available databases per user type.
2) Interface that specifies all necessary SQL queries that can be made to the server.
3) Client...
The idea is:
a client-server application, where the client uses WCF services to execute SQL queries (INSERT, UPDATE, SELECT, etc.) on tables by invoking services methods.
The service should ideally be consumable for both the WPF and the Silverlight app.
Is that the way to go? Which exisiting technologies might I want to make use of regarding formats, communication, services etc.
If that is problematic, I would consider going back to a desktop app, but then how to ease the user type/database access problem for each client?
I would stick with ADO.NET and start with the DbProviderFactory class. This will let you determine the proper database access based on information supplied by the provider using the Factory Design Pattern. So instead of having to create a specialized objects for each database type and database, you can abstract that logic with the DbProviderFactory.
Here's a link that shows some examples: http://msdn.microsoft.com/en-us/library/wda6c36e(v=VS.100).aspx
We have been using a web application framework to build apps that need to be able to query a SQL Server database and get the results as XML.
In the past, the framework provided that capability. But that capability is now deprecated.
So we were thinking, the framework allows us to easily query a REST service over HTTP, so why not use a SQL Server HTTP Endpoint. However, we then read that HTTP Endpoints are deprecated, as of SQL Server 2008. Not a platform on which to design an architecture for the future.
Azure (formerly SQL Data Services) was going to offer similar services, but now only supports the TDS protocol, not http. So no REST to be found in Azure.
The suggested alternative is to develop a custom app using WCF Data Services (formerly ADO.NET Data Services). But that would mean a whole additional app to develop, deploy, and maintain, presumably with its own authentication setup separate from SQL Server's, and its own source code repository... using a technology we have no experience with, therefore with its own pretty deep learning curve.
Can you suggest any other way to query a SQL Server database via REST/HTTP, that is not deprecated, and that would return results as XML?
Thanks for any help.
Read here: Creating an OData API for StackOverflow including XML and JSON in 30 minutes. Basically, the road forward is for REST to be offered by app layer (WCF powering EF that provides the OData mapping). IMHO straight HTTP access into the engine was a very bad idea to start with, nobody liked the HTTPEndpoints of SQL Server 2005 and they were as misguided as it gets. One cannot map the HTTP error model, security, type system into SQL and expect a smooth interoperability. Having the HTTP layer live in a dedicated app pushes the responsibility of handling the HTTP ecosystem into a component specialized in that (WCF), and the logic of mapping the REST model to the DB model ina component specialized in that job (EF).
It sounds like you may be wedded to an MS stack but if you're not, you can use restSQL in a Java EE container (Tomcat, WebLogic, etc.) on top of MySQL or PostgreSQL. restSQL has a full HTTP API with JSON or XML encoding. It offers two twists: updatable composite views and hierarchical composite views. The framework is extensible to other databases and addition of SQL Server is in its supported evolution. Check out http://restsql.org.
Another option is something like Dreamfactory. They have a SOAP to REST solution that allows you to connect to any database or service. I have used their free hosted solution in the past for projects. They also have an open source solution available. The cool thing about the service is that they use Swagger 3.0 to create service definitions in a nice front-end solution so you can test and create new endpoints.
I have used the OpenAPI 3.0 definitions to connect to 3rd party SOAP and REST services as well. They also support stored procedures and server-side scripting in the SQL Server environments.
Anyways, might be another option for you.
I have decided to learn Silverlight, but apart from knowing how to write apps, I also need to know how to connect to a remote server to fetch data. I have seen some examples of database connection in .NET, but I am rather confused by which way to go.
My generic question is how do SL applications connect to remote servers? You could post a subjective response if you like, but this question should be objective in that I want to learn about the possible ways of creating a connection to a remote SQL server.
Where do these (WCF, XML, Ajax, Linq to SQL, Entity Framework, data access providers, and so on) come in handy? If one wants to establish robust and secure connections, which one of those (or others) are a must-learn? I'd like to grab a book and learn stuff, but before I do that, I need to know what to invest my time in.
Silverlight, being a browser technology, doesn't do direct SQL Server connections. Most SL apps speak HTTP to a server (REST, SOAP, POX)- other options are available, but much more limited than with the "big" .NET Framework.
Probably the easiest way to go for a beginner is .NET RIA Services. It allows simple exposure of various kinds of models built off databases (LINQ to SQL, Entity Framework, etc). LINQ to SQL is the simplest on the model side if you're talking to SQL Server, though EF is fine too (a bigger, more complex hammer). RIA Services will allow you to expose table objects from your model over a web service, and the Silverlight client can consume data through LINQ queries that are remoted back to the server (very efficient- the query criteria lives on the client, while the data filtering happens on the server, and it's all compile-time type-checked against the model, so it's much harder to screw datatypes and queries up or expose yourself to SQL injection attacks). RIA Services will also let you apply various security options and data validation on both ends, and the full power of WCF is available to you if you go lower level and do something RIA can't.
This question is an updated version of a previous question I have asked on here.
I am new to client-server model with SQL Server as the relational database. I have read that public access to SQL Server is not secure. If direct access to the database is not a good practice, then what kind of layer should be placed between the server and the client? Note that I have a desktop application that will serve as the client and a remote SQL Server database that will provide data to the client. The client will input their username and password in order to see their data. I have heard of terms like VPN, ISA, TMG, Terminal Services, proxy server, and so on. I need a fast and secure n-tier architecture.
P.S. I have heard of web services in front of the database. Can I use WCF to retrieve, update, insert data? Would it be a good approach in terms of security and performance?
A web-service tier is pretty common for smart-clients as a layer between the user-client and the server. This allows:
simple networking (http only)
you have an app-layer in which to put validation etc without upsetting the db
you can have security that isn't tied to the db
the db can run as fewer accounts (app accounts), allowing greater connection pooling
you can "scale out" the app layer
you can cache etc above the db
you can have a richer app layer, with more services than sql server provides
the client has a known API, and never knows about the db (which is an implementation detail)
You can use WCF to talk to the app layer, but you shouldn't think in terms of "INSERT", "UPDATE" etc - you should think in terms of operations that make sense to your domain model - the "CreateOrder" operation, etc. ADO.NET Data Services allows an API more similar to your "INSERT" etc, but it isn't necessarily as controlled as you might like for a secure service.
Performance is really a factor of "what queries am I running?" and "how much data am I transferring?". As long as you keep the operations sane (i.e. don't fetch the entire "Orders" data over the wire just to find the most recent order-date), then you should be OK.
We upload sales transactions from our stores to the headoffice server. At the moment, we use DTS (SQL Server Data Transformation Services), but we’re planning on replacing that with Microsoft Sync services for ADO.NET, as this seems to be Microsoft’s preferred solution for this type of setup and we want to follow the standard (that will be hopefully be around for a long time).
Here are the details of our setup and what we’re planning. I’m looking for some advice, especially about whether Sync Services fits into our solution.
Situation
Each store has a 3rd party EPOS system which stores sales in a Microsoft Access 2000 database, which we can access. Our headoffice database is SQL Server 2005, but will be upgraded to 2008. The headoffice is not on a VPN with all the stores, but we can open up our firewall to the stores’ IP addresses, so that they can send data directly to SQL Server. The stores are always connected to the internet via ADSL, although they do lose connection and we don’t want to lose sales data.
We are only uploading transactions from the store – definitions do not need to be downloaded.
Current solution
We have written a Windows service that runs on the store PC. This service downloads a DTS package from the server (which contains all the details of the upload) and runs it in the store – and this will upload sales to our server.
We chose DTS, because it is free when you install MSDE. We can’t use SSIS, because that would require a SQL Server licence at every store.
Another reason we chose DTS is that the details of the upload (i.e. which tables and fields to include) are stored on our headoffice server, so if we need to change things we can do that centrally and don’t need to install anything new at the stores. This isn’t a showstopper, but would be nice to have this ability in our new solution.
Potential solution - Microsoft Sync services for ADO.NET
We are currently building a proof of concept with Microsoft Sync services for ADO.NET. The idea is to put SQL CE (SQL Server Compact 3.5) in each store (client) and sync that to the headoffice SQL Server 2005 database (server). We’ll get the data into the SQL CE database either by (1) syncing it with the Access 2000 database or (2) getting the EPOS system developers to write sales straight into the SQL CE database – probably (2). But our main concern is getting the data from the store to the headoffice server. This method seems to be Microsoft’s preferred solution for occasionally connected systems and that is what made us look seriously at Sync Services.
I’m hoping that using this will mean that most of the work needed to upload the sales will be built into Sync Services and we won’t have to re-invent the wheel.
Potential solution - Upload to a custom webservice
There is also the possibility of uploading the sales transactions to a custom web service on our headoffice server and then into our SQL Server database. This means that we will have to build our own mechanism for determining which rows are new, and as well as caching for when the systems are disconnected. Also, we might be missing out on other functionality that will come built into Sync Services.
Please let me know if you have any advice that will help, especially : “Is Sync services the right solution!”. The problem that we are trying to solve seems very generic (uploading sales from stores) – and I’d like to solve it with a generic solution.
Microsoft Sync services is more than you need, but it will certainly do what you want, and it was built with your type of application in mind.
As with most new technologies out of microsoft, (caution: generalization!) you may find that it's not as mature as you might like. It'll do what you need it to, but you may run into issues that aren't easily resolved because it hasn't been put through the ringer. As an early adopter, though, you may find that the Sync developers are eager to help you out when you get stuck, so this isn't as big a problem as it might seem.
Make sure you read through all the literature on it, some of which is here, or linked in the following sites:
http://msdn.microsoft.com/en-us/sync/default.aspx
http://msdn.microsoft.com/en-us/sync/bb887608.aspx
http://en.wikipedia.org/wiki/Microsoft_Sync_Framework
Given your one-way flow of information, though, and centralized layout I expect you should have few, if any, issues setting it up and using it.
Be sure to report your experience back here!
-Adam