We're using a Web service for data access. But I'm confused on how to set this up.
Around page 80 of the book, describes a message object and the proxies. The way I read this is that the web service requires 5 methods:
Create, Fetch, Update, Delete, Execute
Each method uses a message object (the actual web method signature is not described) as part of its signature. Then with configuration settings in the client web.config file (web application), the CSLA framework is supposed to know it's to use a web service proxy for the Fetches...., on the client (bypassing the actual DataPortal_Fetch()), and then the DataPortal_Fetch() would be used on web service to access the DB.
But in the ProjectTracker asmx service you have defined web methods like this: GetProject(), ... which imples the DAL on the client side is instantiating the proxy and calling the appropiate web method in it's DataPortal_Fetch(), and so on.
Could you please clear up my confusion, and if method #1 above does work, provide some more detail about web method signatures and web.config settings.
Thanks
There are two very different concepts here.
The data portal is a client/server technology that supports the mobile object concepts used by CSLA .NET. It can (as one option) run over web services, though I recommend running it over WCF - assuming you deploy in a 3-tier model. Generally I recommend deploying in a 2-tier model unless you really need the security or scalability provided by 3-tier deployments.
A service interface (Chapter 21) is a whole other thing. With a SOAP or REST service, you are either the author of the service or the consuming app - but you must realize you have two apps, not one.
If you are the author of the service app, you are building an app that happens to have an XML interface (or JSON I suppose). This is what Chapter 21 is all about. You can use business objects as a business layer behind your service interface, allowing many other applications to interact with your service app through that interface.
If you are the author of what's called an "edge application", you are building an app with a user interface that happens to interact with a service (SOAP, REST, XML, JSON), instead of (or in addition to) interacting with a database. You can use business objects to create this application - it is just that your DataPortal_XYZ methods will call the service instead of talking to a database.
Either way you are building TWO SEPARATE APPLICATIONS that happen to interact with each other through a contractual message-based interface (often XML or JSON).
The data portal is not about being service-oriented, it is about being n-tier client/server. When using the data portal you don't need to create the client or server aspects of any services - those are already in CSLA .NET. You just need to configure the server endpoint and host, and you need to configure the client to call that server endpoint.
Thanks for the response. In our shop, we need to use 3-tier, and even though I prefer WCF, right now it has to be XML web services.
I was thinking that I could have a single assembly defining the business objects that I could reference in both the web service and web application servers. So, then the business objects would be coded to access the database on the web service server, and using configuration in the web application, tell the channel adapter to call an XML service instead of using the DataPortal create, fetch, ....
Then the xml service would have 5 generic methods: Create(), Fetch(),.... and using polymorhpism or typeof() checks coded in the generic methods, their code would call the appropiate factory method for the business object, which would then continue on and perform the dataportal call for the DB.
But it sounds like in a 3-tier design, that I need separate business objects, with the same properties, for the app and web services.
There is a web service data portal channel in CSLA .NET. Like all the data portal channels, it enables the mobile object concepts used by CSLA .NET so your business DLL can be deployed on client and server and your objects move between the two machines.
The behavior is exactly the same as with WCF, but obviously the configuration is slightly different.
The last documentation of the web service channel is in the Expert 2005 Business Objects book - which also covers the Remoting and Enterprise Services channels.
There's no sense trying to implement this stuff yourself when it is already built into CSLA .NET.
I'm not interested in re-inventing anything. I'm just confused with the projectTracker example instantiating the web service proxy and calling custom web methods, which I understand is one way of operation under certain circumstances. It would have been good for me at least to have an example that implemented the built in way of implementing a service. Also, I can't find any references that tell me how to configure/setup an XML web service. Unfortunatly we work for an origanization where non-technical people make descisions for technical people and we can't use WCF yet.
Thanks
I'm probably suffering from information overload at the moment, but I'm wondering how to deploy a plain old XML web service using CSLA. By implication it seems that I just need to create a web service project, which creates an asmx file and names the service, and then have it reference the dll with my business objects.
Then the client would be able to discover the WSDL and access the service, after setting the CslaDataPortalProxy to xxx.WebServiceProxy class.
I think I've seen it, but I can't recall how to set the URL to the web service in the client's web.config file. So, could you help me out with this.
Is it just that simple to deploy the service and client, or are there missing pieces I require?
Thanks for your help.
Let's take this one step at a time.
ProjectTracker shows a lot of things, different things. You should not care about the web service web site or PTWebServiceClient - they are not relevant to the data portal - they are all about building and consuming a SOAP-based web service interface for your application.
What you should look at is PTWin or PTWeb. In the config files for those client apps are numerous commented lines to configure CslaDataPortalProxy in various ways. You'll see that there's a line for the WebServiceProxy, and an associated line to set the URL of the web service host.
In either of those client apps, if you comment out all other CslaDataPortalProxy entries, and uncomment the two entries for WebServiceProxy and the web service URL then you've configured the client app so the data portal uses the asmx web service protocol to communicate with the server.
Similarly, if you look at the WebServiceHost project you'll see how the web service host is set up so the data portal runs behind asmx.
Of course the data portal isn't an "open web service". The data portal is a client/server technology that happens to be using asmx web services as a network protocol. The actual data flowing over the wire are binary streams. I discuss the design parameters and concepts in the Expert 2005 Business Objects book.
I must say that the asmx web service data portal channel exists only to support environments where some executive decision was made to "only use web services". It is not the best technical option, but it does work, and does enable people living in those environments to use the data portal.
But honestly, if you can't use WCF, you are probably better off using Remoting, as it will perform better than asmx web services, and has the same basic networking and .NET requirements. In other words, if asmx works, Remoting will too, just faster.
per this from Rocky ....
If you are the author of what's called an "edge application", you are building an app with a user interface that happens to interact with a service (SOAP, REST, XML, JSON), instead of (or in addition to) interacting with a database. You can use business objects to create this application - it is just that your DataPortal_XYZ methods will call the service instead of talking to a database.
My business objects are consuming data from ASMX (SOAP) Web Services ....
I'm having trouble finding anything that references this architecture in the 2005 or 2008 books or here on the site.
Is there a conventional way to code the DataPortal_ZYZ methods that takes advangage of .Net 3.5 CSLA 3.8.4 CSLA features .... anything to code in my .config files ( we may have to use some SOAP based authentication to access web methods on the 3rd party service).
Thanks ...
Steve
This is an area I gave less attention to in the book, as I've never thought it was terribly complex.
Basically, if you are creating an edge application that is going to talk to pre-existing services (of whatever type), then those services should be thought of as your "database" or your "stored procedures". They are a remote black box that does something interesting, but you don't know how. All you know is that you form a request, send the request, and maybe get back some results. Just like a stored procedure.
So you configure the data portal to run in local mode on the client. And you put your service calls in the DataPortal_XYZ methods. That code looks very much like doing a stored procedure call, except you are calling a service instead of executing a database query. But that's a pretty minor difference conceptually.
Back to my question about "best practices" for consuming a web service for a web application .....
Is there an good alternative to constantly creating and disposing the proxy on each data_portal call ... to the remote ASMX provider that has all of my application data ?
Should I try to persist the proxy beyond the scope of a method that makes calls to the service by making it ( the proxy ) a class-scope variable or even create some kind of custom data access component for serving all of my business objects for each session ... or even for all sessions happening on the server.
Put a WCF "wrapper" around the remote service and make calls to the remote ASMX Web service from my web app ??
I'm going to try it.
Thx,
Steve
You should probably read some of the WCF books out there - from Michelle and Juval, etc. to get a firm answer.
To my knowledge there's no benefit to maintaining a reference to the proxy object, and there are very real drawbacks to not properly closing the proxy object. Were you to maintain a long-term reference to the proxy object, you'll need to come up with a way to detect that the connection has faulted (which basically means WCF or asmx got confused) so you know to close and re-create the proxy.
I can tell you that the data portal does not keep the WCF proxy alive any longer than a single network call. Keeping track of whether the proxy is faulted, and ensuring that multiple threads don't try to use the same proxy was all way too complex - so I just create the proxy, use it and make sure to properly close it - all within the context of a single method call. Simple, clean, elegant.
o.k. ... "to your knowledge covers a lot of ground", sir ... I consider that a "best practice" ...
baggage from my MTS days ... tho I do understand that with WCF now there are "instancing" declarations that can be used to persist the component ... but that's on the server, right ??
Thanks, Rocky ...
Copyright (c) Marimer LLC