I read that JCA is for legacy EIS integration. Is this spec geared towards vendors and not the application developer? I am curious to know of use cases where developers wrote JCA adapters to solve their technical or business problems.
I've written JCA connectors for all sorts of end systems (FTP, SFTP, File, financial systems).
This is mainly in the investment banking sector where I need to send trade and/or static data to various systems inside and outside the bank. Anything from RESTFul JSON/XML web services to socket calls to a mainframe can be involved in a business transaction.
So JCA comes in real handy is it provides a uniform programming model and can be managed by Application servers which help you with transactionality, pooling etc.
Want the FTP file containing the very expensive trade to arrive (transactionally guaranteed)? JCA is one technology you can use to tackle that.
<blatant plug> I'll add that I currently work on an open source project called Ikasan which has free JCA connectors </blatant plug> as do several other projects such as Mule and Spring Integration. So it's not often the average developer has to write their own.
The JCA stands for J2EE Connector Architecture, it provides means for connecting components run on a J2EE Application Server with the outward world, many existing heterogeneous systems.
In J2EE, you can write presentation layer code running in web container, and enterprise bean in EJB container, but your application is not in a vacuum, you need access other systems and your application also need to be accessed by other system. JCA just provides a standard API for accessing external systems, or being accessed by external systems.
If you are a EIS system vendors, that is Ok, because you want you system be accessed in a J2EE Server.
If your are a application developer, you may also need JCA, because you may need access other system without out-of-box JCA resource adaptor in your application, just write the resource adaptor for your own.
JCA is a collection of connection, thread, transaction, security and lifecycle contracts. By adhering to these contracts, you can offload most of your connection management, thread management, transaction management, security, packaging, deployment, activation, deactivation etc... to the container (JCA compliant application server). Jca also provides an optional cci(common client interface) that allows applications to access the adapter.
Now whether to write a jca compliant connector or not really depends on your applications's requirements.
People generally write jca adapters to access file systems, jms, database, ldap, email, mainframes, packaged applications and just about any other EIS. It really is the developer's prerogative to figure out if writing one is necessary but it's essentially non-trivial to write one.
Related
From a systems integration perspective, is it common practice to use ESB (enterprise service bus) middleware technologies over EJB for mid-to-large sized applications, or is the use of ESB middleware mainly reserved for BPM (business process management) applications?
ESB is mainly used as an integration layer for the purposes of enabling integration of systems talking different message formats, for proxying, routing, message transformation, load balancing, talk different protocols etc. some or all of the above or much more.
An esb may be a full fledged commercial/open source system or just a proxy or router application, which could be implemented using ejb if required.
To comment on ESB and EJB, they are not related and they serve different purposes.
BPM usually involves message orchestration, interaction among different services, message formats and systems and as such an esb tends to come into picture for the purposes of integration. To comment on your point, ESB is neither reserved nor mandatory for BPM.
In my humble opinion, ESB is not just for BPM.
Using ESB allows you to create a distributed architecture.
Benefits of distributed architecture are well known (for example - scalability).
Of course, ESB is not the only solution out there to achieve this,but one of the solutions available.
Pay attention that if you need a distributed architecture , which does not have lots of services + differentiation of protocols (i.e - usage of HTTP, JMS, and more...) you should consider another solution.
ESB can help you when you have many services, which use different protocols (for example, imagine a component that accepts, and another component listening on JMS queue - you might need to send a message which is "logically" the same, but should be once said to the first service, and later on should be sent to the second service - an ESB will help you to perform this task).
I would recommend you to read more on this subject at this blog.
Is there a possibility having transactions across multiple systems?
For exeample:
layer 1 - exposes web services (Deployed to weblogic)
layer 2 - .NET front end (Deployed to IIS)
Can we have transaction commit or rollback for multiple web service calls initiated from .NET?
If so, can someone point me any resource or document? And is there any special requirement for each of the layer comply to participate in transactions?
Yes, it is possible. WCF allows for the consumption of web services that utilize the WS-Atomic Transaction standard, assuming you have System.Transactions.TransactionScope available in your .NET client (Silverlight, for example, does not have this).
There is an excellent example on CodeProject that shows both how to produce and consume transaction web services in .NET using TransactionScope.
casperOne's mention of TransactionScope is an excellent solution if it is available in your scenario. I have fallen in love with the simplicity and power it brings to the table.
However, I note that you have a Java tag and mention Weblogic as the web service tier, so the TransactionScopeRequired property would have to be implemented via WS-AT (Web Services Atomic Transaction) or a similar transcriptional protocol.
See here: http://publib.boulder.ibm.com/infocenter/wsdoc400/v6r0/index.jsp?topic=/com.ibm.websphere.iseries.doc/info/ae/ae/cjta_wstran.html
Its definitely possible, but could prove to be harrier than you'd think. You need control to modify the execution environment of those web services to augment them such that they can consume the WS-AT headers. In addition as with any distributed transaction environment you probably will incur a performance increase because of the substantial administrative overhead.
SOA-WORLD had some great articles that explain Web Service transactions and all the related OASIS standards. Here is the one on WS-Coordination if I can find the rest I'll add them.
Why do we need Application Server in Java like JBoss or WebSphere. Is it possible that we develop large scale website only with Java (Apache Tomcat). Where thousand of user connect on site at a moment. An example is a website like b2b.
What is the cost of a Application Server? I will be thankful if you compare price among different application server and if there is any free version kindly highlight it.
Application Servers are mostly used if you want to use advanced features like transaction management, hot code swapping and advanced persistence.
There are application servers that are open source. E.g. GlassFish and JBoss.
I don't think you need an application server for building a popular web site, you'll also be fine with a servlet container like Tomcat or Jetty.
In short Application Servers provide you with few services like
Transaction Management
Load Balancing
Security
Threading
etc.
You have to take care of these things yourself in a Web Server.
There are few Open Source Application servers which are free of cost.
I have used Glassfish.
Apart from answers given above, App Servers are required for EJBs.
You need Application Server as follow:
It provides you useful services like automatic transaction,Authentication,Authorization,Lifecycle management.
To remember large user data across pages using ejb's pertaining to a client.
Load balance the user request and buisness logic.
To interact with different Client UI like Java Swing,Browsers.
It is possible to handle the httpheaders yourself. We have done socket servers in java for 20 years. You do not need a container for java swing.
Persistence can be done through databases or server side files unless you need real high speed stuff. I have yet to find a real requirement for an ejb
except that some systems simply require them
This may be because jboss can provide better after-sales service, and jboss, etc. can provide operation and maintenance support, etc. This may be the reason why many large companies choose commercial versions of servers.
But you must know that tomcat and netty are not bad. For example, many large B2B or C2C or B2C companies still use tomcat, such as Internet companies such as Alibaba.
Choose a server
Operation and maintenance costs
Scalable costs
Server cost
I have a stand-alone, Swing application that uses Hibernate for its persistence layer. I need to extend this to a three-tier system, so that there will be multiple instances of the Swing application and a central server. The client is a stock trading platform, so it will contain a lot of business logic. The server will be responsible for mostly persistence operations and some business logic.
What would be the best way to implement the server for my needs? EJB3 or Spring? What is the best practice for Swing applications to interact with a server? I don't want to go with RMI since not only is it becoming obsolete but also there is no guarantee that the clients and the server will be on the same network.
If the client is a Java client, I don't see the point of using web services (and thus having the overhead of the object to XML serialization) and I would go for EJB 3.x.
For me, the major benefits (beyond performance and scalability) that you get with a good container are fault-tolerance and fail-over (both on the server side and client side, especially with Stateless Session Beans if they are idempotent). For a stock trading platform, this matters.
Also note that using EJB3 doesn't necessarily exclude using Spring for the glue (on the client side and/or the server side).
And if the need to expose your services as web services should arise (e.g. for another non Java client), just annotate them with JAX-WS annotations.
I don't want to go with RMI since not
only is it becoming obsolete
This isn't true at all. As long as Java is around, you'll have RMI.
And what do you think EJBs are using to communicate? It's RMI.
but also there is no guarantee that
the clients and the server will be on
the same network.
Personally, I'd prefer Spring. You can expose your service layer using web services or HTTP remoting.
Go with Spring and RMI. If your client and server are both Java it is the best solution with best performance and productivity.
Note that EJBs don't necessarily use RMI as the transport protocol. OpenEJB for example uses its own custom protocol. We get about 7300 TPS over the wire which is pretty good. There is a Spring integration as well so if you wanted, you could build the server with Spring and inject Spring beans into EJBs and vice versa:
http://openejb.apache.org/3.0/spring.html
In a very popular ecommerce store, I'd imagine the actual processing of the credit card would be moved to some sort of dedicated application server, and made into more of a asynchronous process.
What sort of java application type would that be? i.e. a service that would take a message of the queue, and start processing the request and update some db table once finished.
In .net, I guess one would use a windows service. What would you use in the java world?
It is typically a J2EE application that uses a HTTP web service interface or a JMS messaging interface. HTTP interfaces are accessible via a URL, and JMS connects to a queue to pick up messages that are sent to it. The app can run on any one of the major commercial (WebSphere, Weblogic, Oracle) or free (Glassfish, JBoss) servers.
In Java you already have great open source projects that do all this for you like Glassfish, Tomcat etc.
For a mission critical system, you might want something like IBM MQ series as the middleware, and a straight Java application that uses the MQ interface to process the requests.
At a few banks that I know of, this is their architecture. Originally the application servers were written in C, as was the middleware. They were able to switch to java because the code that was actually doing the critical work (sending and receiving messages, assuring guaranteed delivery, protecting against interruptions if a component went down) were the IBM MQ's.
In our case we use an application server from Sybase that can house Java components. They are pretty much standard Java classes that have public methods that are exposed for calling via CORBA. Components can also be scheduled to run constantly or on a schedule (like a service) to look for work to do (via items in a database table, an Oracle AQ queue, or a JMS queue). All of this is contained in the app server and the app server provides transaction management, resource management, and database connection pooling for us.
Or use an OSGI environment.