Hi list, my apologies for the long mail, but I thought it best to ask all my questions in one go ;-) I've been working on integrating OTRS with a java application via SOAP. After a few experiments with the included SOAP::Lite interface, I've had to abandon using rpc.pl as autodispatch does not result in "rigorously" formed and typed SOAP messages, something that's essential if I'm going to use apache AXIS (for example) as the client. I've got some proof of concept code and WSDL that I want eventually to package, but I could use some advice. The modules aren't really core and they aren't really frontend (it's HTTP, but you wouldn't use them via a web browser and they probably don't require localization). I've put them in Kernel::System for now, does that sound about right? I did think about a new structure (say Kernel::System::WebService) but I'm not sure of the implications. I'm initially interested in Ticket and Article objects. From those objects what are the minimum set of fields that are required to create a valid object? I need these so that I may create schema types for ticket and article with optional elements that may be used in a short form for creating those objects, but in a longer form for retrieving them. For example can I create a ticket with QueueID _or_ Queue and later retrieve it with both QueueID _and_ Queue populated? Are there definitive docs out there on this that I've missed? I have the developer docs (very nice BTW, and a _big_ help ) and the ITSM database docs from the website already. Oh yeah, and I _can_ read the code ;-) Finally, does this broadly sound like the correct approach? I'm somewhat concerned about causing problems down the line by encapsulating a few methods such as TicketGet and TicketCreate in other objects, but it seems to be the most obvious way of adding this capability without unsustainable messing around with the OTRS core. The purpose of this is to start integrating OTRS::ITSM with OpenNMS (they seem to complement each other nicely). If I can get them to interoperate in this way, there are a lot of very cool possibilities. I could, of course, make the interface using SMTP, but I think that is rather a dead-end. Cheers .... Jonathan. (and thanks, if you've read this far)