propose adding a "service" property to the request object.

[Travis Hein]

In section 4 of the 1.2 proposal where the properties of the request
are identified,

The Request is expressed as a single JSON Object, with the following
members:

jsonrpc A String specifying the version of the JSON-RPC protocol.
MUST be exactly "2.0".

*[new]*
service A string containing the service name for which the method
can be invoked. optional
*[/new]*

method A String containing the name of the procedure to be invoked.

params An Array or Object, that holds the actual parameter values
for the invocation of the procedure. Can be omitted if empty.

id A Request identifier that MUST be a JSON scalar (String, Number,
True, False)


where the "service" attribute could be optional, if not present then
would require the explicit service name in the target endpoint, as it
likely does already. This should not likely cause existing
implementations that work well without it to break.

The motivation for adding a service property is applicable to both
HTTP and TCP socket based transports, the latter being the main focus,
as to invoke more than one 'service' over TCP would require different
TCP endpoints, or a means to aggregate all methods together into a
single service aggregation, perhaps with method prefixing. clearly
the service could be specified by the URL path components in the HTTP
based invocation, but it is also sometimes convenient to have a single
JSON-RPC receiver servlet to be able to route or dispatch requests to
'services' configured inside the webapp, such as in a plug-in type of
manner, without requiring a new servlet defined in the application
deployment descriptor, and a unique URL endpoint for each service.

Consider the example of a general service registry. in my example I am
using a Java based client and Java based web application, where a
single servlet is the receiver for all json-rpc requests,. The request
object is received, the "service", property is decoded and used to
look up the java object instance from a map (such as a map of service
names to java object instances, perhaps configured with a bean factory
such as spring framework). once the handle to the service object is
obtained, the "method" is used to reflectively discover the method to
be invoked. This allows for POJO (plain old java objects) to be
exposed as 'services' through the JSON RPC mechanism.

More over, the ability to send JSON-RPC messages over TPC sockets,
where the socket server simply replaces the HTTP servlet, allows for
the complete reuse of the server side request processor (in my case,
using the Java programming language), the mechanism of looking up the
service object from the map of service name to Java objects, and the
reflective invocation of methods is the same, we simply replace the
HTTP servlet with a TCP socket server..

So in this situation, adding a new service object, is an exercise of
having the service POJO instantiated and added it the server-side
mapping to service names, which depending on the deployment
environment, could possibly be hot-deployed into a live system, or an
administrative mechanism could be constructed to dynamically disable
services in a running system.

I was considering defining a convention of a dotted prefix notation in
the method name, as this is likely the intent of the current method
field (as the recommendation of the "rpc." method prefixing and due to
the lack of a service property already?)

For example, if I had "Service1" and a method inside it "method1",
then the JSON-RPC method could be "Service1.method1",

And in this prefixing of the method name, it likely would be possible
to parse the method on the delimiter (dot in this case), and extract
the service name from the first token and the method name from the
second token.

but I thought this was kind of a work around, and would prefer to see
the explicit definition of service and method name as exact properties
in the request object.

By extension, I guess the specification could be evolved to articulate
internal RPC methods by making service name="rpc." and the method name
being the method, but an additional benefit of the separate service
request property in this case could be to combine the conventions, to
allow for a metadata kind of introspection of the service methods.

For example, if i have Service1 and methods method1, method2,
method3, how would I "ask what methods Service1 has" ?
in the current way, i could do invent a method = "rpc.showMethods" ,
but this would require i specify the service as a parameter. ?
Where as if I had "service=Service1, method="rpc.showMethods", this
clearly is understood to mean, interrogate the Service1 and reply with
the list of valid methods [that are accessible at this time].

I am still working out some details of how this could be implemented,
and while implementation details are not likely relevant to the JSON-
RPC 1.2 specification, I would be happy to provide sample
implementations if that helps to clarify the use cases. Specifically,
I was thinking of a Service interface, that would allow articulation
of methods [in the POJO being exposed as a service] are allowed to be
invoked through the JSON-RPC, and possibly extensions to limit method
invocation depending on user roles.

Well, thats probably enough for now, I am eager to hear your thoughts
and discussions on this.

[Burak Yiğit KAYA]

I second this. Nice point =)

Burak Yiğit "BYK" Kaya - http://card.ly/BYK
GROU.PS - JavaScript Consultant - http://grou.ps
aVJSlib - Lead Developer - http://code.google.com/p/av-jslib

[Travis Hein]

.. oh I forgot to add to original text, we would likely also need to
add an error message, something like


-32500 Invalid Service. The service specified in the JSON-RPC
Request is not a valid service.

and this could likely also map to HTTP code 404, for the JSON-RPC over
HTTP extension. ?

[Matt (MPCM)]

I think it is an interesting topic, but would need more discussion
within the group before consideration. For now I would put the
behavior in an extension spec, implement it in your client/server, and
document it out with the choices you make/made. But it may be a good
topic for future revisions. 2.0 has been a long time coming, and
should not be taking on new features at this point (IMO).

For the moment having multiple end points or prefixed methods names as
wrappers would be a way to achieve this within the current spec. (i.e.
"serviceone.add", "servicetwo.add")

--
Matt (MPCM)

[Omi]

I second Matt's opinion. The service extension could make a good
candidate for 2.1 or later revision.

[Alexandre Morgaut]

New feature:

I agree with Matt that any additional feature should be considered as
extension before being potentially included in a future version

My sentiment would have also be to extract the batch feature in an
extension.
(it wouldn't give less value to batch, as HTTP Authentication,
cookies, Content-Disposition and much more are defined outside of the
HTTP spec)


HTTP status code:

I also want to warn that the 404 HTTP status code means "bad URL"
which won't be the case in those POST requests (the bad parameter
value comes from Body).
The 400 HTTP status code should be used instead (see discussion on
JSON-RPC over HTTP)

RFC 2616 :

10.4.5 404 Not Found

The server has not found anything matching the Request-URI.

[Travis Hein]

These are all valid points. When considering the effort to get 2.0 out sooner than later, and the work around using prefixed method names is functional for now as well. I will keep documentation on my implementation for now and bring it up some time later if the need should come ip.

I appreciate the feedback.
--
Travis.

--

You received this message because you are subscribed to the Google Groups "JSON-RPC" group.
To post to this group, send email to json...@googlegroups.com.
To unsubscribe from this group, send email to json-rpc+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/json-rpc?hl=.