Absolutely.  Though StrataFrame provides a lot of UI functionality, the core of the framework is from the middle-tier back.  So web services is a highly used and supported function of StrataFrame.

First, as an aside here, StrataFrame has an Enterprise Server that can do all of this for you in regards to managing data.  However, if you already have XML coming and going and just want to stick with what you are currently doing, then you can just import the XML file into a BO once it comes in and conversly you can take the contents of a BO and dump it into an XML document.  So yes, you can do this out-of-the-box.

Obviously there would be your application logic and elbow grease to parse out the XML information as there is not going to be aby "pre-defined" logic within SF to know how to map that inbound data and traffic.  So what I would do in this case is create a single factory class that parsed the XML data and then placed that data into the appropriate "bins" or in this case BOs.

Like any application, you are going to have to create your application logic.  But the benefit of pulling that information out of an XML table into BOs would be that your data would then be scrubbed and managed properly once in the BO.  You would then gain all benefits of a tiered environment at that point.  I hope that is at least going in the right direction of where your questions are.

Whether or not Enterprise Server will work for you depends on whether or not you have control over both ends of the application (both the server side, and the client side.)  If that is the case, than you can publish an enterprise server on your own publicly accessible server, then use that enterprise server as a data source for the client. This allows the client to communicate with the remote server just as if it were a local data source.  In most cases this accomplishes the same task as a web service, but uses a proprietary communication protocol (similar to serializing the data back and forth, but much more efficient.) In the situations where it fits, Enterprise Server is very effective, simpler to implement than web services, and much faster in operation.

By the sounds of it, however, you are providing a web service which your customers connect to. If that is the case, than they (your customers) would have to purchase strataframe to encorporate enterprise server support within their own applications. If this isn't what you are looking for then yes, standard web services would be the best answer.  Strataframe does not require additional functionality in order to work in a web services environment, so implementing that portion itself would be the same as implementing a web service using standard .NET. There are quite a few docs out on the web that do a great job of outlining that process.

Once you have your web service published, and are parsing the necessary information out of or into the required XML files, that is where StrataFrame can come into play to help marshal that data, using BOs and business logic to keep everything organized and clean on the backend. This is what Trent was getting at in his earlier post. You would create a factory class (just standard .NET) to grab and interpret the received XML file, and that factory class would be where the integration with StrataFrame would begin. We'd be happy to give some specific direction here if you can share some more specifics of your application itself (i.e. what data you are expecting, what you want to do with that data, etc.)

If you do have control over both ends of the application (server and client side), then I would definitely recommend using Enterprise Server rather than trying to implement web services. As I mentioned, it is quite a bit simpler to implement, and is much faster (and potentially more secure) in operation.

Hope it helps

Dustin

First, our ES server was created in the interest of performance and scalability.  As you have probably learned by now, we also have a very large high-end medical application that we sell and distribute that sits on top of StrataFrame.  So our entire framework (ES and otherwise) was created for scalability and taking advantage of remote data sources including the use of web services from the very beginning as this is a primary tool for creating a centralized data exchange or application server...depending on the needs of the app.  Additionally, it was created for extremely high volume and load balancing so that the size of the application can grow and be load balanced and all that has to happen is add servers to the farm.  This is something that becomes far more complicated with just dealing with WCF and standard serialization mechanisms...though, for smaller environments where this need will never exist, SF can do the very same thing that you referenced in your MM comment.  The only difference is that we do not have a template, which we could add, but is not something that is overly complicated to setup which is why we never have created this template.

Again, I highly recommend actually creating a sample application to make sure that your needs get met.  That is where the "rubber meets the road" versus a lot of talk and discussion anyway.

We appreciate you taking the time review StrataFrame and we look forward to helping as you work through your trial.