Just building a new site, we will be building a .net soap service to supply the data to a php site.
I used a fair amount of .net soap services in php, some of which you need to map classes and some that you just provide an array of php data to the service.
Our .net developer has only ever built soap services with class mapping, I would prefer it if we just had to supply a simple array of data to the service. As it will mean making changes will be a lot simpler.
What needs to be enabled on the .net side to allow this, and what are the benefits / pit falls of doing so?
PHP as the Soap client will best work if a WSDL ressource is provided, but apart from that, no further classes are needed - you can use any construct of arrays and/or stdClass objects for the parameters.
But it will make life a lot easier if you use the classmap feature of the SoapClient, e.g. your IDE would complete the names of properties for you, and when debugging you know which part of the object you are dealing with. But it is entirely optional.
The server part has nothing to do with it. But be aware that using the more fancy stuff in SOAP might make it a lot harder for PHP to be the client. If you want this to be easy going, I'd stay away from more complicated structures like XML attributes.
In a response, <element>value</element> will be fine, <element attrib="value"/> might not. But don't take my word for it, I'm just using Java Soap services a lot in PHP, and we don't have attributes.
Related
We are trying to interact with a SOAP server written in .NET. One of the parameters for one of the calls is a serialised, base64 encoded .NET object:
<parameter>base64Binary</parameter>
Although I do know the rough make up of the .NET object, I’m at a loss of how to serialise a PHP array/object appropriately for the SOAP server to handle. Obviously PHP and .NET’s serialisation methods are not the same so it’s not going to be as simple as that. The .NET object is also quite complex and is made up of a number of child objects to make things more fun. We have no control over the .NET code either.
Does anyone have any advice on how to handle such a scenario?
I have searched and everything I get looks to be about a PHP app consuming an .aspx web service but that's not what I'm looking for.
I may be overlooking something obvious and would be happy to hear that but that doesn't mean I haven't tried.
I'm a .Net developer by platform, a developer by trade 20+ years and will admit that I'm spoiled by the ease of .Net
That said, an ASP.Net .asmx web service is quite literally a single file that might be pure soap (but it's so well hidden that I don't know) but I can use them with jQuery AJAX calls effortlessly. Methods exist that have parameters (basic types or complex objects defined by classes in my project) and I can call those methods at a single url, pass in my JSON and .Net gives me an object to work with. I do what I need, then return an object matching the methods return type and all the HTTP/JSON/ENCODING/DECODING is done for me so I only need to worry about the JSON client-side, working with my classes server side, and treating the methods like any other server-side method.
Does a library/framework exist for PHP that provides that same sort of ease? From my reading, I think that 'routing' is a related concept but that term isn't one I know in the .Net context so assume I know nothing but basic PHP skills (nothing but server side syntax, operators, data types, etc..)
I want to learn to love PHP but this could be make/break for me because everything I do now ends up being client-side JS/DOM and server-side data management. Very little use for actually manipulating the HTML returned to the client (Call it Google-style web apps).
If it helps define what I'm looking for, I use Telerik Kendo DataSource a lot and need the easiest way to focus on my client-side code with Kendo and actual business logic/db server-side.
Slimframework.com looks to be the closest thing I've found so far but it's not clear to me if it's intended for what I'm needing or if it's perhaps just a common tool that would help get me there. I'm hoping for something clearly more complete.
As part of an App i'm developing there's a requirement to create a conversion between our RESTful JSON API and a number of other formats. The intention is to allow output from our API to be converted to make further requests to API's that use different formats such as SOAP, or other REST based API's with different requirements.
A few examples of the kind of things I think this might need to do:
manipulate the JSON output to use different keys (and maybe only a subset of
data
convert to an XML packet/document
convert to a valid SOAP request
output data as a specific filetype/structure (such as csv)
I'm interested really in what approaches should I be looking at here. It would seem to me that this should be a fairly common request so i'm interested if there are specific libraries I should look at, or existing services perhaps. If such a service doesn't exist then ideally I want to create a common structure whereby the 2 disparate services can be mapped using a universal set of tools that are just then configured to work together. This will be within a Laravel PHP application so any Composer compatible library would work.
Following on from my comment:
"I am not aware of any such library to do this, but as a rough guide I think you probably want to create some kind of adapters which all use a common interface. These adapters can then be written to deal with the conversion you are trying to achieve via some open-source library. Manipulating the output might be a good excuse to use the decorator pattern :) Sorry I could not be of much more help."
An example of what I think you are after is the following:
An interface for your adapters
interface DataConvertor
{
public function convert(DataInterface $data);
}
An interface for the data you are passing around (the data will be an object also with a common interface to work from).
interface DataInterface
{
/**
* returns a json string
*/
public function asJson();
}
Then you can create your adapter for use with some 3rd party library.
class SomeThirdPartyNameAdapter implements DataConvertor
{
public function convert($data)
{
//some logic here to make my data object with a known asJon method
//suitable for use for some 3rd party library, and use that library.
$rawJson = $data->asJson();
//manipulate this as needed ($compatibleData)
$thirdPartyLib = new ThirdPartyLib();
return $thirdPartyLib->thirdPartyMethod($compatibleData);
}
}
Obviously this is just a rough guide and there may be other parts of this you can make abstract (e.g. have the adapters implement the DataConvertor interface but also extend some abstract class to inherit some functionality, or other method to add to your interface).
Hope this helps
Carl is right that a great approach is to create some adapters using a common interface. Then you can provide implementations that convert JSON to XML or JSON to a CSV, etc.
However I would strongly recommend looking into Mule ESB as a solution as well. http://www.mulesoft.org/
It's a Java based, open source project that allows you to do pretty quick and efficient integrations. For example, you could create a "flow" (a Mule term) that makes a RESTful call and then converts the data and pumps it out to a specific destination (CSV, SOAP call, XML, etc.)
The real selling points of Mule (things that have worked great for me):
Very easy to deploy. It works similar to something like Tomcat, where you can deploy a package and it runs on a server.
Tons and tons and tons of boilerplate code already done for you.
Free and stable. They have tons of high profile customers so it's pretty battle tested and we've been able to get their free version working in production with no trouble.
I've been asked to help a friend's company to bring up a web application. I have very limited time and I reluctantly accepted the request, at one condition. As most of the logic goes on in the back-end, I suggested that I would finish the complete back-end only, allowing a front-end developer to simply interface with my backend.
I plan to do the back-end in Java EE or Python (with Pylons). It does not really matter at this point. I plan to have my back-end completely ready and unit-tested, so that my input will hardly be needed after my work is done.
I know they have a PHP programmer, but as far as I could tell he is a real rookie. I want him to basically interface with my backend's services in the easiest possible way, with no way of him "stuffing" it up. It's basically a CRUD-only application.
I could implement the backend as accessible through a webservice such as XML-RPC or SOAP. Even a RESTful API could be possible.
However, my main objective is to make something that complete "noob" PHP programmer can easily interface with without getting confused. Preferably I do not even want to talk to him because I generally have an extremely busy schedule, and doing "support calls" is not something I am willing to do. Which approach should I choose? I would welcome any suggestions and inputs!
I would personally choose a REST API, probably with a JSON response. SOAP and XML can be a bit heavy-handed for simple services, and even the most novice web developer understands the concept of accessing a basic URL, even if they don't grok the overall concept of REST. There are myriads of ways to work with URLs in PHP, so I'm sure they'd be able to come up with something, even if it was a hack job instead of a nice client package.
I would also likely choose JSON encoding and decoding, as it's generally fairly straightforward, while XML parsing can be a bit more daunting.
I would also write up at least some basic documentation on the service, no matter what formats you choose. Otherwise there's no way you will escape support calls. Your target consumer must have a reference of the remote actions available to him, or a method to discover those actions. It would probably take you 10 minutes to whip up some example code when it's ready, and those 10 minutes could save you a lot of emailing.
Definitly go with a rest-like implementation, and return query string formatted output.
Just remember that php will turn array like variables into an array on the php side.
Take a query string for your parameters
Input:
p1=v1&p2=v2....
Output:
output1=var1&output[0]=var2;output[2]=var3
Accessing this in php is then a simple as
<?
$request['myparam1'] = param;
...
$webService ="http://path.to.service?".http_build_query($request);
parse_str(file_get_contents($webService),$response);
// response is now an array with you response parameters in it
// $response['responseParam1'], reponse['responseParam1'] etc
?>
parse_str
http_build_query
Been there, done that.
Backend in Django, frontend in PHP by a 'we do pages' contractor. i whipped up a REST-like API using JSON, provided them with a couple of 5-line PHP functions to access my service as a key-value store.
After a couple of false starts (where they tried a contrived and redirections scheme instead of using the functions i sent them), they got it and everything went smoothly after that.
I am trying to make a decision whether I should use a REST service or a SOAP service for some web facing functions that I am producing. This decision is based on whether I can easily use the REST service in implementation. I would prefer to use REST, though I don't want to spend days coding the object model in PHP.
The services are being developed in .NET but will be consumed mainly by PHP.
Basically it has come down to one point: Ease of integration. Using SOAP in PHP I can use the NuSOAP library, which will generate the object model.
However with REST I cannot seem to find a way to easily generate that model, if this is possible I would use REST services as they are easier to document and extend, and also have the JSON abilities as well.
Can I generate an object model in PHP from an XML file/schema that I could then serialize with the REST service?
You might not even have to go the class route. Simply ingest the data using simplexml and then traverse it as if it were an object. Or if you have json, json_decode($data, TRUE) would do the same thing (without attributes in brackets).
$ch = curl_init("http://example.com/some/rest/endpoint");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);
$data = curl_exec($ch);
$obj = simplexml_load_string($data);
print $obj->some->data->you['need'];
That would print here if your XML was something like
<_>
<some>
<data>
<you need="here" />
</data>
</some>
</_>
I had some trouble getting SOAP to work between diffent languages (PHP <> JAVA and PHP <> .NET)
If your going with SOAP, you might want to check out WS-I (Web Services Interoperability)
Based on your described requirements you should stick in the SOAP world. Remember, REST is just a style of architecting a distributed interface. It says nothing about how the functionality of that interface is implemented. There certainly is no need for mapping schemas to objects.
Having said that, if you look at the client tools in the WCF REST Starter kit you will find functionality to paste XML as a CLR type. This will do a best guess at creating a serializable class based on an XML instance document.
Also, from what you are describing ADO.NET Data Services would provide you a quick way of exposing RESTful data services to your PHP site.
....
Here is a question for you? If the .Net services are going to be consumed by a PHP site then why would you describe the .Net services as "web facing". From your description, these services sound more like a private implementation detail of your web site.
If I were you I would:
investigate if NuSOAP tools can be used on just XSD. In the .NET world, you have svcutil (or in the ASMX days, wsdl.exe) to digest .wsdl files to produce proxy classes. But if you have only .xsd files, you can use the xsd.exe tool, or the "aftermarket" XsdObjectGen, which is like a supercharged xsd.exe. Are there similar tools in NuSOAP to do the same? Maybe this is obvious and you've already done it.
if that doesn't pan out, produce a dummy WSDL, and stuff the XSD you have into it. Then, process the .wsdl file with the NuSOAP tools. Grab the generated code, and remove the soap envelope and communications stuff, but retain the object serialization stuff. Not sure if this is possible, the way the PHP (or is it C?) code is generated by the NuSOAP tools. In .NET, it's easy to break the different pieces out.
The whole idea behind rest is that you do not use it with hackish "object models" like with SOAP. The problem is you're trying to use the system wrong :)
If you want object models, use SOAP.
If you want web-friendly APIs, use REST.
For ease of integration, I'd go with a REST API. Since there is such a strong convention, integrating should be relatively straightforward for anybody's who's worked with REST before.
So i think this could be something that i am looking for. but i would like to know if there is some sort of automation system out there for it
found it at http://devzone.zend.com/article/1713#Heading11
Extending Classes
While the above examples were all
doable with PHP 4 and the domxml
extension (only the API was a little
bit different), the ability to extend
DOM classes with your own code is a
new feature of PHP 5. This makes it
possible to write more readable code.
Here's the whole example again,
re-written to use the DomDocument
class:
class Articles extends DomDocument {
function __construct() {
//has to be called!
parent::__construct();
}
function addArticle($title) {
$item = $this->createElement("item");
$titlespace = $this->createElement("title");
$titletext = $this->createTextNode($title);
$titlespace->appendChild($titletext);
$item->appendChild($titlespace);
$this->documentElement->appendChild($item);
} } $dom = new Articles(); $dom->load("articles.xml");
$dom->addArticle("XML in PHP5"); print
$dom->save("newfile.xml");