• Post Reply Bookmark Topic Watch Topic
  • New Topic

Exposing API  RSS feed

 
Marco Bertotti
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When i need to expose an API for clients for a set of business operation that are modeled as methods over a stateless session bean that needs to posses ACID semanthics what's the best technology to implement it ?

JCA? seems false, it's used to connect to an external system in a transactional way
RMI? may be true, using ejb3 with @WebMethod it could expose such api
JMS? it should be false.
XML using http?

Any suggestion ?
 
L Foster
Ranch Hand
Posts: 225
12
Android AngularJS Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, Marco.

If it were me, I would assume these calls are synchronous, that the transactions are beginning at the EJB, the clients are external. and that you want to make things lean. It would either be the WebMethod annotation, or another layer of Services to call them.  Assume is a big word.  Read on...

First, let's attack that requirement.  Let's take it apart.
expose an API for clients for a set of business operation that are modeled as methods over a stateless session bean that needs to posses ACID semanthics


NOTE: when I write "distributed transactions" below, I mean distributed between the server running the EJBs and some caller.  What happens with transactions on the server itself could be distributed or not, and the client need not care.

* "API" is an interface with methods.  APIs are "out there", so you may have to worry about maintaining them.  They're like a contract.
* "Expose" reminds us that clients need to access this. It has to be open, available, secure enough for them to get to the API.
* "Stateless session bean" and ACID go together pretty well.  Stateless beans can be annotated to deal with transactions, and indeed if they are called in distributed fashion, they can handle distributed transactions as well.  "business operation" goes along with this, too.
* "client" is the tricky part.  If the client is another bean, a web application or anything else internal, just expose the EJB itself.  It can be injected into a lot of things nowadays, and just used.  However, if 'client' is external, EJBs will have some encumberances, such as the need to punch that (non HTTP/S) protocol through the firewall.  However, even external clients may be able to play in a distributed transaction, and EJB clients are good for that.  They can be secured and the credentials can even be passed around. 
* The other side of that 'if': if the external client does not need to be in a distributed transaction, and just needs a transaction going on at the API, there is no need for an EJB client. Another option might be the use of services--be they SOAP or RESTful.

You can make annotations on EJBs and expose them as SOAP services.  SOAP can get heavy (the protocol with XML can be fat and the messages can slow communication), and SOAP seems to beckon toward a high level of organizational discipline.  They do give something back for that: security is at least implemented; there is exposure through WSDL, and lots of other tooling.  One drawback with just annotating EJBs, is you still have to have something "API like", and EJBs to "just get things done", might not be organized well for that.

Still another possibility: RESTful is very popular right now because it is much lighter than SOAP (using JSON instead of XML), but it is not as powerful in some ways.

You mentioned XML over HTTP--that sounds Custom if you don't mean SOAP.  It may be a bit lighter, but not as much as RESTful.

You mentioned JMS: you only need JMS if you want to do asynchronous calls.  Call it, go away, check for a result.  Further, since there is no "true" client of JMS (you start sort of another server, sending messages), and the thing could execute at any future time, you won't get distributed transactions.

As for JCA, that has a very specific place.  It is for legacy systems of a special type, like Siebel Systems and SAP, etc.  These are in the category of "Enterprise Information Systems".  Rule of thumb: if they mention these things, it's JCA. Not otherwise.  Used the wrong way, JCA implies implementing a huge ball of code to get all the (or the interesting) interfaces set up.

I hope this helps.


 
Marco Bertotti
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So RMI is the answer??

XML over Http seems a good way but it's a custom solution and not seems to fit totally with the requirement,
 
L Foster
Ranch Hand
Posts: 225
12
Android AngularJS Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Marco:
I think I was writing, "given the assumptions, the answer is Web Services over HTTP."  If your assumptions are of internal (same server) clients, then EJB is the answer.  Remote EJB use can operate over the RMI protocol (if memory serves).  Local EJB use, however, may not be using any 'protocol' at all, because none is needed.  You should be careful not to confuse EJBs with "Remote Method Invocation" by itself, however.  That technology is more about calling methods (treating them like procedural functions), than it is about OOD, despite its being implemented in Java.  It also is not going to have some of the niceities of EJBs.  I recall it being more work to set those calls up.

I sort of don't like the way the original question is phrased, because you have to make assumptions in order to decide.  But I think there is a fair amount of that on the test, too.


Good luck.
 
Marco Bertotti
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
well, clients are remote. So reading at you xml over http (no Web Services over HTTP between the answer) should be the answer. however the "operations" exposed as stateless session bean are not on the samse server but reading at docs seems rmi-iiop should be able to call them.

I'm still a bit confused  then... cant use webServices (just XML over Http) .
 
L Foster
Ranch Hand
Posts: 225
12
Android AngularJS Java Netbeans IDE
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, Marco,
I hope I am not confusing you.  Perhaps I think too much about these things.

If you are limited to just those answers you have presented in the question, then let's start over:
* You can eliminate JCA because no one mentioned an EIS.
* You can eliminate JMS because no one mentioned asynchronous processing.

That leaves RMI or XML over Http.  XML over HTTP could be thought of as SOAP or some custom implementation.
You can dig into RMI a big.  Learn what its strengths and weaknesses are.  Then come to your own conclusion.
 
Marco Bertotti
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
went back on the cade/sheil book and also on the bambara one... rmi-iiop seems the way to go.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!