I need my VS2005 / LLBLGen 2.0 webservice to be reachable from non .NET web platforms like classic asp and php for example. Since the service uses entities as parameters of its method calls - similar to the illustration in LLBLGen docs - I am concerned that other environments / platforms may not be able to deal with anything beyond primitive types being passed as parameters.

Thanks Thomas

etechpartner wrote:

I need my VS2005 / LLBLGen 2.0 webservice to be reachable from non .NET web platforms like classic asp and php for example. Since the service uses entities as parameters of its method calls - similar to the illustration in LLBLGen docs - I am concerned that other environments / platforms may not be able to deal with anything beyond primitive types being passed as parameters.

Thanks Thomas

Why don't you expose only simple types? Besides this, client can create entity skeletons, so the entities passed can be deserialized to that skeletons.

According to the docs in LLBLGen I should be able to do this:

[WebMethod]
    public bool SaveCustomer(CustomerEntity toSave)
    {
        using(DataAccessAdapter adapter = new DataAccessAdapter())
        {
            return adapter.SaveEntity(toSave);
        }
    }

That's what my question was about.

I think you should use primitive dataTypes when consuming a web-method from a non dotNet client.

yep, something like [WebMethod] public void SaveCustomer(int id, string name, ...)

Two things come to mind. First - I think a small addition to the product documentation would be great. Something that points out the examples listed there are specifically meant for usage with an LLBLGen based client app. It would have most likely prevent thios thread.

Secondly, and this is not stictly an LLBLGen question so feel free to ignore it Now that I understand the intent of the examples listed, I am wondering if anyone has seen any classic asp script based examples of invoking a web services WITHOUT the benefit of some intermediary dll. So going straight from asp to web service without the use of old school vb, vc or even more recently interop. I have a legacy asp app that uses no VB com dll's. That app needs to talk to a .NET web service backed by LLBLGen. My concern is that I have not seen such an app be able to deal with complex return types - getting passed the question of complex params for a second. Granted this is ancient stuff and I dont expect anyone to still remember how this was done but its worth a shot asking.

TIA Thomas

Webservices are based on XML, so everything that goes in or out a webservice is a XML. So, if your app knows to deal with XML then you are fine. Actually, XML is a text afterall thus you can always read it somehow

etechpartner wrote:

Secondly, and this is not stictly an LLBLGen question so feel free to ignore it Now that I understand the intent of the examples listed, I am wondering if anyone has seen any classic asp script based examples of invoking a web services WITHOUT the benefit of some intermediary dll. So going straight from asp to web service without the use of old school vb, vc or even more recently interop. I have a legacy asp app that uses no VB com dll's. That app needs to talk to a .NET web service backed by LLBLGen. My concern is that I have not seen such an app be able to deal with complex return types - getting passed the question of complex params for a second. Granted this is ancient stuff and I dont expect anyone to still remember how this was done but its worth a shot asking.

Hi Thomas,

a while ago, Microsoft provided the SOAP Toolkit which allowed you to consume web services from VB (and as far as I remember classic ASP as well). However, the toolkit is deprecated but you can still download it (http://www.microsoft.com/downloads/details.aspx?familyid=c943c0dd-ceec-4088-9753-86f052ec8450&displaylang=en).

We are still using it in production so it might be a viable solution for your problem.

As far as your return types are concerned: It's all XML so just use MSXML4 or MSXML6 to parse them

Cheers

Stefan

etechpartner wrote:

According to the docs in LLBLGen I should be able to do this:

[WebMethod]
    public bool SaveCustomer(CustomerEntity toSave)
    {
        using(DataAccessAdapter adapter = new DataAccessAdapter())
        {
            return adapter.SaveEntity(toSave);
        }
    }

That's what my question was about.

There are a dozen ways to skin a cat, and this is one way. The way .NET converts an object into XML is through Serialization. The problems that occur with clients not being able to consume web services, in my experience, occur because the tools we use lean towards a certain platform.

The promise of web services (cross platform software as a service) is really only realized when you use a "contract first" approach. This means creating an XSD Schema for the expected request and response documents, then creating a service that exposes these operations as a web service. Under the hood you can transform the request (XSLT) into a serialized LLBLGen object, then deserialize and process the object as desired (i.e. call the Save method or whatever the operation should do), and finally send back the response doc with the results.

sbroenne - yes indeed I've also come across the Soap Toolkit. Thanks for mentioning it, in case another user has a similar question. The irony of the toolkit is that a lot of its documentation point to using other languages and platforms as intermediaries. Be it C++ or VB to wrap the web service and provide an interface that a scripter would have an easier time with. I'm saying ironic because VB6 for example is apartment threaded and runs slower than just plain old asp script.

Chester - you are right on the money with "a dozen ways to skin this cat". I am gravitating toward the use of wsdl since as the name implies, its supposed to define what a web service can do - the contract so to speak and ,unless I'm wrong, by using VS2005 to build the file I can avoid building the xsd documents by hand. Of course, there is a way to have the best of both worlds by referencing xsd schemas within the header area of the wsdl, but that makes the file non-compliant with WS-1 Basic Profile Rule R2001. So thats at least 2 of the 12 cats right there

One thing you could try is creating an XSD schema, use the xsd command line utility (I think it comes with VS2005) to generate a corresponding C# class (edit - which you would expose as a webservice), then in your C# class instantiate your LLBLGen objects. This gives you the contract-first approach, which greatly increases the chances of your service playing nice with other platforms.

Chester - as I understand it contract first is a very popular approach. On the other hand I could also create some DTO's in a facade on top of the LLBLGen entities and use the implementation first approach to create the service and wsdl. Either way works pretty well in platforms that can take advantage of the schema information contained in the xsd or wsdl to generate proxies. Thats very cool especially in strongly typed environments. Alas the poor maintenance programmer who has to talk to my service can only do it via asp/vbscript which I believe (now I could be wrong here) can't take full advantage of proxy classes even with the Soap Toolkit. At the moment I'm crossing my fingers that I dont have to deal too much with that part of the implementation - I love my C# too much ....