J Dirksen

Author
+ Follow
since Sep 04, 2012
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by J Dirksen

Might this help:

http://www-01.ibm.com/support/docview.wss?uid=swg21279327

Seems to be a somewhat related problem, where a certificate is missing from the client truststore.
11 years ago
I don't really understand the question, since RPC is a style you can use to do webservices. OFten webservices (the SOAP ones) are divided into two styles. RPC Style webservices and document style webservices. In the early days of webservices RPC was most often used, but this caused all kinds of performance and interoperability issues. Microsoft was one of the first to start with document/literal way of webservices. This provided an easy way to map webservices to server implementations and also allowed for easy interoperability.

The JBoss webservice documentation has a more extensive explanation: http://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/Web_Services.html
11 years ago
Yes you can. The basic idea behind rest is that resources are identified by an unique URI and a specific media-type / content-type. Based on this URI you can use the basic HTTP methods to modify or retrieve the resources. If you create a REST api you can create a resouce that provides a list of files with their associated media-type. Your client can then just use HTTP GET to retrieve the file.
11 years ago
True, there is no standards based authentication/encryption/security framework available for REST, such as WS-Security for SOAP services. A lot of people say that since we got https that's enough for the encryption and integrity part and that with HTTP authentication we could handle the rest. You can probably fulfill most scenarios with these two technologies, but often https just isn't feasible or you want a different authentication method than just HTTP authentication.

It all really depends on your scenario. For integrity and authentication, for instance, you can add a simple HMAC to your message, calculated based on a shared key. If it's an API you're creating for third parties you can give out API keys that are sent with the request and tied to a specific host name. So for the authentication part there are a couple 'roll-your-own' solutions that are easy to implement. Encryption isn't something that is often done on the message level in JSON over REST, the only real option is using HTTPS. You could, if you really would like message based encryption use XML as the payload and use the standards for XML encryption.
11 years ago
Both XML and JSON are plain text formats. So there won't be much difference in parsing performance I guess.

It really depends on what you call "very large data". Most of the latency will probably be in the network, not the parsing. I've worked with services where the JSON response messages were a couple of MBs, and that doesn't really pose any problems.

And usually JSON/REST doesn't require very large messages. With REST you just use the basic HTTP methods to retrieve resources. So for instance when you're working with large images or video files you normally don't encode these directly into the JSON response. What you do is, you add a link to the image/video in your json response. You client can than retrieve this data by following this link, just like a browser does.

With XML, on the other hand, it's much more common to encode binary files as bas64 and add them to the SOAP Message or use specs like MTOM. This, however, will likely increase the message size significantly and will probably also have an adverse effect on the performance.
11 years ago
Depends what you mean with web service. When using SOAP you're pretty much stuck with XML, when using a REST approach you can define the content-type yourself (most often XML or JSON based).

If you do have to use SOAP you could, in theory, just encode your json and return it wrapped in XML, but I wouldn't recommend that ;-)
11 years ago
Ulf is right, both can be determined as being webservices. Normally, though, when you talk about webservices in teh enterprise world, people immediately assume your talking about SOAP/HTTP webservices. Webservices defined by a large number of specifications.

I don't really know whether most development is really done in the traditional WS-* space. In large organisation SOA is equivalent with SOAP/HTTP, and I agree, they still do a lot of SOAP/XML/XSD/WSDL type development. When you look outside the enterprise environment, however, you see people moving away from the often complex traditional webservice approach. Most 'services' on the internet are more often than not developed using a light-weight REST/JSON approach.

Both approaches have their advantages and disadvantages of course.
11 years ago
That's the advantage of using WSDL2Java. In the WSDL the endpoint where the service is running on is defined. So if you generate a client from this WSDL the default configuration, usually, is that the endpoint from the WSDL is used as default. So that's how axis knows where to send the message to.

The mapping to and from XML is also generated from the WSDL. Depending on the configuration with Axis2 this will be either done using adb or jaxb. What this does it uses the annotated generated classes from the WSDL and uses that information to map from XML to Java and back again.

I don't know the dependencies axis has, but it probably uses the default Java URL connection to make the connection with the server. Since SOAP is just plain XML over HTTP there is usually no need for additional frameworks for creating this connection and invoking the endpoint.
11 years ago
If you only want to expose this API to a logged in user the easiest way to do this is by adding basic/digest HTTP authentication to the rest call. There are many examples / steps how to do this. The basic steps are outlined in this stackoverflow post:

http://stackoverflow.com/questions/8073193/secure-access-to-authenticated-rest-server-through-backbone-js
11 years ago
What kind of web services are you talking about? Are it webservices in the traditional sense with XML and SOAP or do you use a RESTful approach.

The most basic approach for both scenarios is using basic authentication on the HTTP request, this will allow you to at least restrict access to authorized users.

You talk about "anybody can see the data", what are you looking for; a way to restrict access to your API or a way to encrypt the data?
11 years ago
Short answer:
No

Somewhat longer answer:
Even though UDDI in itself isn't used anymore the concepts behind it are still very relevant. The goal of UDDI has always been to form a sort of phonebook / central registry where you can look up services and from there start interacting with the service. This never really took off, but what you do see more and more is a more pragmatic kind of registry. All the large SOA suite vendors offer their own registry, where consumers can find the details of a service and providers can register their services.

This, however, usually uses a more simple approach through a REST interface or even a basic web interface since more often then not, this kind of information is used for human consumption.
11 years ago
SOA Governance suffers from a serious PR problem. Most people when they hear the words governance or SOA immediately relate it to large enterprise projects and environments. While that is an important situation and environment to use SOA Governance, it isn't just meant for that domain.

The goal of SOA Governance should be to make sure that your services are build consistently, following the standards and principles set out by your organization/department/team. Having SOA Governance allows you to easily reuse services, and see how is using your service and how. This is as important for a single department as it is for a complete enterprise.

As a 'one man band' you're probably stretching it a bit when you go full blown SOA Governance. However, if you have a centralized set of services you reuse over applications and projects it might still be a good idea to use a standard way you define your service contract (WSDL, JSON plain text description), and handle authentication and authorization.

Using service registries and introducing service and policy lifecycles might be a bit much
11 years ago
Hi all, great to be here.

I'll be lurking about here this week and try to answer questions you might have about the book, webservices, SOA Governance or REST.

Jos
11 years ago