Apologies if this is not the correct forum for this question...



I am evaluating app frameworks for our dev team and SF is one of the current front runners. However, try as I might, I can't see any discussion anywhere about creating web services using SF - it all seems very UI app focussed.



A large part of our business is providing web services to our clients for data exchange and for purchasing our products; these web services rely on passing XML documents containing the required data. It would not be practical to expose a web service serving up serialised SF business objects - this would be meaningless to the consumers of our services.



Does the SF toolset provide the ability to easily create XML web services built on the SF business layer in the same way that it facilitates the creation of Win/WebForms apps, or would such web services need to be hand coded?



Thanks.

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.

Actually our web services are not that simple, which is why simply exposing business objects as a web service simply can't work for us. Sorry if my original question was not explicit enough...



The data we exchange with our clients might end up mapping (and not neatly) to a dozen or more business objects. Some manual parsing of the XML, BO instantiation and orchestration of the BOs into a business process will be required. So - I guess I am asking can SF help us with all of that? If so where can I see some doco or functional descriptions to help me understand this functionality?



Thanks.

I guess I wasn't very clear either.  Sorry.  I wasn't suggesting that you expose BOs in any respect.  You mentioned that you were expecting an XML file on the inbound and I also assume outbound responses and requests.  You can take these XML files that I assume that you are required to use, and then redirect that XML data into BOs. 

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.

Thanks Trent. So if I understand you correctly, SF provides the business layer via BOs but it would be up to us to build the actual web service that uses them by hand?

If you are not using the Enterprise server, then yes.  That is correct.

And if we are using Enterprise Server? My impression was that ES serves up serialised BOs to consuming applications and provides data connection pooling... not sure how that provides us with RAD tools to write a web service?



Trooly rooly, if you can point me to some doco or something I can stop pestering you with these inane questions. I'm more than happy to read up on this, I just can't find what I need. Perhaps you have a developer's guide illustrating your approach to building a web service on Enterprise Server?

Just to jump in here,

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

Excellent - thanks Dustin, you've hit the nail on the head exactly. We do not have control over the web service consumers - this would be our customers, using whatever applications they please to exchange data with us. The web service is the point of exposure to the outside world.



It's great that SF takes care of the business layer so neatly... I was just hoping for a little more on the web service side. Imagine having the power of your tools that create Win/WebForms to create a public facing web service - now that would be really cool (and something I really want)... I'm really tired of hand-crafting these suckers.



If you are interested in looking any further at this (for product development say) the Mere Mortals framework from Oak Leaf seems to provide just such a toolset; this may help you get a feel for what I want out of a framework from a web service perspective. So far I've only had a high level look at their product and will be drilling down deeper shortly. Not that I'm knocking you guys - you appear to do what you do really well, but this is a big hole for me. If you had an offering in this space I reckon you'd blitz the market.

Instead of going on a item by item break down of all of the differences here and trying to understand your application.  I will just say this and recommend actually creating a web service through the trial so that we have a more concrete discussion instead of theory and charts.

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.