Regarding architecture...

Since LLBLProGen generated TypedLists and TypedView are Typed DataTable objects, they are not natively supported in .Net XML Web Services (as DataSets are). I'm wondering how to properly use LLBLProGen objects to create Web Services.

Any ideas? Thanks.

Jeff

JMichelson wrote:

Regarding architecture... Since LLBLProGen generated TypedLists and TypedView are Typed DataTable objects, they are not natively supported in .Net XML Web Services (as DataSets are). I'm wondering how to properly use LLBLProGen objects to create Web Services.

You can add them to a dataset and return that one, or you can use (prefered) remoting.

Webservices are great to communicate with clients on other platforms and / or when the communication is done using a predefined XML format. If your clients are .NET clients, it's better to use remoting, since this is much faster and you can return entity objects using soap serialization, webservices use first the XmlSerializer to create XML and then transport this XML to the other side. Because the XmlSerializer in .NET 1.0 and 1.1 is hard-wired to DataSets, every object is considered a dataset OR is tried to be migrated to Xml using reflection (and a slow code generation method : it actually generates files which are merged back together). MS has made IXmlSerializable undocumented (the interface I have to implement to make the XmlSerializer work together with for example entities) because every object which implements this interface is seen as a dataset. This is of course not workable. Furthermore, if you create a webservice client using vs.net (add a web-reference) it redefines the types, you have to manually specify all the types you want to import OR hack the generated file vs.net generates for you. Not that pleasant.

If you still want to use webservices and want to transport entities, you can first serialize the entity/entity collection to a memstream and return the string inside that stream and at the other side construct the object back from that stream. This is much faster than when you use the traditional webmethod way and return an entity type plus you don't have a redefined type at the other end. An example is below:

// Server. 
[WebMethod]
public string GetCustomer(string customerID)
{
    SoapFormatter formatter = new SoapFormatter();
    MemoryStream writeStream = new MemoryStream();
    CustomerEntity myCustomer = new CustomerEntity(customerID);

    formatter.Serialize(writeStream, myCustomer);
    return System.Text.Encoding.UTF8.GetString(writeStream.ToArray());
}

// client
SoapFormatter formatter = new SoapFormatter();
MemoryStream readStream = new MemoryStream(System.Text.Encoding.UTF8.GetBytes(myWebService.GetCustomer("CHOPS")));
CustomerEntity myCustomer = (CustomerEntity)formatter.Deserialize(readStream);

However I'd suggest to use remoting. Some succesful applications have been written already using remoting and LLBLGen Pro.

Edit: if you want to transfer entities in XML, you can call its ToXml method (or call the ToXml method of the entitycollection class)

Hi, Talking about web serivce using Remoting, when will we have an example using LlblGen Pro, like the Northwind one written for Windows? That would be an invaluable resource for us to deploy web service with remoting.

Uy

I have a rough example here, requesting a customer entity from a server, and getting it back and displaying it. It requires some work to get it running (it relies on an existing Northwind assembly generated by LLBLGen Pro, but that's not such a problem).

I'll upload the 2 zip files now, so you can have a look. It's very small, basicly I used the remoting example in Programming C# to get it up and running.

Ok, uploaded the small remoting example to the customer area. Check the examples section.

In regards to web services (remoting is not suitable) is there way to recreate an entity from XML? I'm looking for a simple/convenient means of creating a class file which may be serialised and passed over http as XML then reconstituted. The end-class does not need ORM functionality. So I guess the question is, is there an easy (non-manual) way to create a class that might act as a carrier across the wire? I'm wondering if the templates may be configured to generate such an object that may be passed in and out. Second to this, an entity constructor which accepts an xml node might also suit (i.e. toXML > fromXML). Or is SoapFormatter approach the only option?

There is no method at the moment to reconstruct an entity from Xml directly. THe problem is that the Xml has to be in the exact format as the Entity it has to be transformed in, plus you have to instantiate the entity (empty) before this.

If you call the ToXml() method you get the entity in Xml. You can pass this acros the wire and re-interpret this xml to fill a class at the other end. However the soap method is far more easier, it takes a few lines of code, produces Xml in the Soap format, you pass it to the other side and recreate the entity using that string of Xml in soap format, including entities inside the entity.

I'll look into a FromXml() method.

Wouldn't it be possible to create typed datasets from entity collections and return those througth webservices ?

[WebMethod] public TypedEntityDataSet GetStuff() { ... create collection ... return EntityCollection.ToTypedDataSet(); }

??

• Oddur

The 'typed' issue is that the class will be redefined on the client's side.

You can however get the entity collection as a datatable, use the GetMultiAsDataTable() method of the entity collection. You can then add that table to a dataset and return that dataset.

The problem is that Microsoft screwed up with the IXmlSerializable interface implementation: it always thinks the data is stored in a plain dataset, when it comes to complex types OR it sees it as a simple type. For example, I can implement IXmlSerializable on the Entity class, then produce XML in the WriteXml() method, and the XmlSerializer object will still think it's a dataset. This is fixed in Whidbey but that's not available now.

Bottom line is: if you want to offer a service to a wide range of clients, probably not .NET, use Webservices, but use pure XML, not types like MyComplexClass. If you want to offer a service to just .NET clients, use remoting.

I'm almost done with the code for a full XML serialization cycle so you can export a full class hierarchy to XML, return that, and reconstruct the complete class hierarchy using the XML at the client. That code will be ported back (it's now in Adapter) to SelfServicing once Adapter is gone gold. But that's also not available now, so the workaround today is you can serialize to SOAP, return the string, or fetch in a datatable, add it to a dataset and return that. But it's not solid, due to the hardcoded codepaths for datasets in xmlserializer, which is ALWAYS used in a webservice: the returned type is transformed into XML, that XML is transformed into SOAP, and that is transported. At the client, this SOAP is deserialized to XML and that XML is deserialized to an instance.