|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 44
Messages: 44
Messages: 44
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
James Strachan tries to explain JBI
Java One 2005 had a very heavy emphasis on JSR-208, Java Business Integration. However, he says, "there seemed to be some folks with confused looks on their faces in some JBI talks." As a response, he's written a blog entry on what JBI actually is.My brief take on JBI is that its a simple API to a Normalized Message Service and Router along with a component and management model for deploying integration services such as routing engines, BPEL engines, rule systems, transformation engines etc.
JBI provides a logical XML messaging network which maps well to HTTP, email and JMS/MOM while easily adapting to legacy systems, binary transports and RPC systems like EJB and CORBA. Think of it as the next logical abstraction above JMS, with support for different message exchanges (one way, request response etc). James works on ServiceMix, a JBI implementation, so it's safe to say he has some idea of what he's talking about. However, despite the vendor emphasis, it's worth asking what JBI means to the average developer. James addresses that question with this:Sure most application developers will still end up writing POJO services and dropping them into their container and exposing them as web services - so often they won't need to use the JBI APIs directly; but for integration companies like ourselves, it provides a way for middleware and integration vendors and OSS projects to work together at the ESB level. What do you think? Don Box, in "Looking for a Clue" and other posts, has wondered how a JBI container differs from an EJB container. (He was answered by Eric Newcomer, in "JBI Debate." It's a pity that Mr. Box's blog doesn't support trackback well, or at least that it wasn't used in this case.)
It's clear that JBI is getting a lot of attention and causing a good amount of confusion as well. Do you think the JBI standard is a good one? Is it a necessary one? What does it mean to you?
|
|
|
Message #177101
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wonder why ?
JBI is as bad as it was the first release of entity EJB.
It seems many people do not get/buy it
which tells me "maybe" there is something wrong with it.
Webservice technology is little different...everybody gets it but nobody knows why they should use it.. :)
yet another "mate" (MArketable TEchnology) to help sell more..
|
|
|
Message #177107
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
Nothing against SOAP or WS, but in attending the JBI presentations, I became very aware of the differences between agreeing and accomodating.
|
|
|
Message #177131
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wonder why ?
"It seems many people do not get/buy it
which tells me "maybe" there is something wrong with it."
On the contrary, enterprise and distributed technologies are beyond comprehension of the masses; just discuss JBI as a JSP tag and everyone will get it!
Perhaps, someone will create a drag and drop JBI component soon and make it an Eclipse plug-in...
|
|
|
Message #177136
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
Seems like a spec for the sake of having a spec to me, I fail to see the endgame other than shelling out money. When you start abstracting something that's already an abstraction (like JMS), it's gone too far and you are simply adding complexity. The last thing the java community needs is more container/deployment complexity. JBI simply adds more nodes and configuration files to the overall architecture, something we should be moving away from.
I know, I've got a new spec that will even one up this, it's the JAA - The java abstraction abstraction. Abstract any Java API through the JAA container and a handy set of 32 Interfaces, which by the way, my company will be the first to market with in hopes that IBM buys me. Hip-hip horray, that's progress!
|
|
|
Message #177143
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
my company will be the first to market with in hopes that IBM buys me. Hip-hip horray, that's progress!
Hehehe...
|
|
|
Message #177147
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JBI is mainly a service providers' programming interface
To me, JBI seems to be mainly a service providers' programming interface, rather than an application developers' programming interface. Unfortunately, most discussions of JBI fail to point this out clearly, with some of the JavaOne sessions being no exception.
JBI technology will likely become relevant to many of us (I'm an application developer) when we start deploying business logic in JBI Service Engines and exposing this logic through JBI Binding Components. In other words: application developers (or should I say service developers?) will deploy business logic in a service engine, but they will not write a specialized service engine for every piece of business logic.
JBI APIs will be relevant to those people who implement these Service Engines (e.g. BPEL engines) and Binding Components (e.g. for your-most-favorite-and-utterly-obscure-communication-protocol-here).
The main difference to EJB containers is that an important EJB aspect is its application developers' programming interface.
A commonality between both specs is the fact that both define a standardized deployment model. (This does not mean the same deployment model, though.)
The JBI spec follows the principle of separation of concerns (separating service engines from binding components from intra-container message passing) and thereby gives people the opportunity to create specialized JBI components (e.g. a specific service engine) without having to worry about the remaining parts of the puzzle (binding components and the normalized message service in this example). With a bit of luck this will allow a market for JBI components to emerge as you should be able to use components from different vendors/projects in the same JBI container.
|
|
|
Message #177149
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
Seems like a spec for the sake of having a spec to me, I fail to see the endgame other than shelling out money. When you start abstracting something that's already an abstraction (like JMS), it's gone too far and you are simply adding complexity.
There's the rub. JMS doesn't map too well to things like CORBA, EJB, HTTP or talking to web service endpoints over HTTP.
JMS rocks for what its designed for, a standard Java API to messaging systems. However something more abstract and with an XML/WS feel and richer message exchange patterns is required for integration type solutions where you're talking to MOM, HTTP, email, EJB, CORBA and legacy stuff. e.g. take a look at the stuff Iona have been doing, mapping tons of legacy systems to JBI. The problem of trying it with JMS would be leaky abstractions. JBI is trying to integrate many different systems together; whether MOM or Java or C or COBOL.
The last thing the java community needs is more container/deployment complexity.
Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc.
JBI simply adds more nodes and configuration files to the overall architecture, something we should be moving away from.I know, I've got a new spec that will even one up this, it's the JAA - The java abstraction abstraction. Abstract any Java API through the JAA container and a handy set of 32 Interfaces,
If its a Java API, then try reflection or just Spring remoting :)
which by the way, my company will be the first to market with in hopes that IBM buys me. Hip-hip horray, that's progress!
Shh don't tell anyone, you might start a bidding war :)
James
LogicBlaze
|
|
|
Message #177155
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JBI is mainly a service providers' programming interface
With a bit of luck this will allow a market for JBI components to emerge as you should be able to use components from different vendors/projects in the same JBI container.
Well said, Oliver. That's one of two things that I like about JBI. (We have a JBI SE wrapper for PXE, for example.)
JBI is like JCA (at least as of 1.5) in that it provides a lot of freedom and flexibility in comparison to EJB2. Also like JCA, SPI versus API means that things won't be as directly interoperable, but it also means that things are not tightly bound together.
The other thing that I like about JBI is the high-level architecture -- normalized messaging service, endpoints isolated from engines. We can talk about whether or not JBI, currently at 1.0 status, represents the platonic form of such an architecture and walk off in a huff if we don't think so, or we can make sure that lessons learned are poured back into JBI 1.5, 2.0, etc. so that the spec and implementations move in the right direction.
|
|
|
Message #177156
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JBI is like JCA
(Sorry for quoting you out of context in the title.)
Interesting--I have been thinking about the JCA analogy, too. Although I'm not quite sure what you mean withSPI versus API means that things won't be as directly interoperable
The key here is that the JBI components will be interoperable. Obviously, as an app developer I shouldn't expect to be able to drop my BPEL service implementation into a non-BPEL service engine; but then I don't drop my SessionBean into a Servlet Container and expect it to work...
|
|
|
Message #177157
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
Erik :
I've got a new spec that will even one up this, it's the JAA - The java abstraction abstraction. Abstract any Java API through the JAA container
Maybe you could start a new Apache Jakarta Commons project, "Commons Abstracting"...
geir
|
|
|
Message #177158
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
Commons-Object and Commons-Commons, anyone?
(Of course, that begs for the obvious "commons-commons-commons" as well...)
|
|
|
Message #177173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc.
If we're talking EAI & SOA why not go with a more generic standards approach such as this one:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
|
|
|
Message #177178
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Like the ESB support
I like the implication of using the JBI to implement
an ESB, which I think is definitely useful for integration
The "bus" allows one to address the combinatorial
explosion that one sees in complex integration
projects - by allowing canonical ("normalized")
models to be used.
I have played around with the open source Mule ESB product
(which I like) and it does a fairly good job, IMO
I dont know about combining orchestration (BPEL) etc
with integration - prefer to separate out orchestration
concerns from Integration solutions and have it focus
on connectivity, routing, transformations, security etc
--Arun
Arun Rao
EDS Corp
|
|
|
Message #177202
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
There's the rub. JMS doesn't map too well to things like CORBA, EJB, HTTP or talking to web service endpoints over HTTP. JMS rocks for what its designed for, a standard Java API to messaging systems. However something more abstract and with an XML/WS feel and richer message exchange patterns is required for integration type solutions where you're talking to MOM, HTTP, email, EJB, CORBA and legacy stuff. e.g. take a look at the stuff Iona have been doing, mapping tons of legacy systems to JBI. The problem of trying it with JMS would be leaky abstractions. JBI is trying to integrate many different systems together; whether MOM or Java or C or COBOL.
On the contrary, the messaging system *is* the abstraction. Most JMS providers allow direct publishing of HTTP messages and things like CORBA clients and EJBs can push messages to an abstract, declarative JMS end-point. They don't really care how the message is digested or by who, they simply care that the message was reliably published nor do they require an awareness of delivery channels, message exchange factories, etc. This can be easily implemented in JMS without a new deployment format or container leveraging existing investment. ESBs play nicely in this niche without the need for additional standards or containers and provide the same exchange patterns of JBI by leveraging the capabilities of the existing messaging bus.
IBMs abstention sums it up well "the JBI specification doesn't represent a sufficient step forward in terms of what we believe our customers need, and above what they can already do."
Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc.
This is exactly the space I play in, not sure why you made the application developer reference. I advise my clients to simplify their architectures whenever possible, complexity is cost for an enterprise and JBI is complexity. It inserts yet another app server into the mix and in the case of legacy systems, forces them to be exposed through that app server as SEs (sorry, I don't really see a way to make my email server comply with the interface contracts required by a BC).
I also find it funny that you throw BPEL in there. IMHO JBI is repeating many of the mistakes of workflow architectures/engines namely instituting additional (often single) points of failure by centralizing the service coordination and endpoints in a single container at the same time adding verbosity where simple configuration is sufficient.
Earlier, you reference Steve Vinoski's blog that has a similar disconnect. He says that some of the mistakes of late 90s' EAI were overhead of translation to canonical formats and the misunderstanding that Java can't "solve it all". Yet, the JBI spec is heavily dependent on WS and WSDL which are by nature verbose and canonical and at the same time forces services to communicate through a Java-heavy standard.
Whew, rant done. One round of XML-RPC for everyone, I'm buying!
|
|
|
Message #177225
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
There's the rub. JMS doesn't map too well to things like CORBA, EJB, HTTP or talking to web service endpoints over HTTP. JMS rocks for what its designed for, a standard Java API to messaging systems. However something more abstract and with an XML/WS feel and richer message exchange patterns is required for integration type solutions where you're talking to MOM, HTTP, email, EJB, CORBA and legacy stuff. e.g. take a look at the stuff Iona have been doing, mapping tons of legacy systems to JBI. The problem of trying it with JMS would be leaky abstractions. JBI is trying to integrate many different systems together; whether MOM or Java or C or COBOL. On the contrary, the messaging system *is* the abstraction. Most JMS providers allow direct publishing of HTTP messages and things like CORBA clients and EJBs can push messages to an abstract, declarative JMS end-point. They don't really care how the message is digested or by who, they simply care that the message was reliably published nor do they require an awareness of delivery channels, message exchange factories, etc. This can be easily implemented in JMS without a new deployment format or container leveraging existing investment. ESBs play nicely in this niche without the need for additional standards or containers and provide the same exchange patterns of JBI by leveraging the capabilities of the existing messaging bus.
I absolutely agree that JMS is very useful - folks have been using JMS and MOM for years to build SOAs and loosely coupled architectures. JBI does not replace JMS at all but work with it. With JBI glasses on, imagine JBI as the glue between your JMS provider, your encoding protocol (SOAP 1.1 in a BytesMessage? or REST in a TextMessage?) and your integration services (content based routing, orchestration, rules, transformations etc).
JBI is intended as an API for ESB container developers and ESB component developers to use which is similar in many ways to JMS but its more abstract and higher level and suitable to many other communication protocols other than just JMS.
JMS is quite complex in comparison to JBI's simpler normalised messaging model. JMS can be quite a tricky to implement correctly and pass the TCK tests (tell me about it, we work on ActiveMQ :) - whereas the JBI model is pretty simple from the NMS side of things; its easy to bind to email or HTTP or whatever.
So while JBI's messaging model is very similar to JMS, its much simpler and handles one way and request-response exchanges more easily.
Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc. This is exactly the space I play in, not sure why you made the application developer reference. I advise my clients to simplify their architectures whenever possible, complexity is cost for an enterprise and JBI is complexity.
Thats good advice
It inserts yet another app server into the mix and in the case of legacy systems, forces them to be exposed through that app server as SEs (sorry, I don't really see a way to make my email server comply with the interface contracts required by a BC).
Most legacy systems would be exposed as a web service I'd have thought. No need to write an SE or BC per se. Though some integration developer might wrap up the legacy system as a BC if there was no web service adaptor, to make the service easier to use inside an ESB - but its not a requirement.
It shouldn't matter how you expose a legacy system; as a CORBA, EJB, XML-over-HTTP, POJO or Web Service, a JBI container should be able to work with it. Its just JBI provides a standard API to allow folks to develop other bindings too.
Indeed I'd say its the ESB's responsibility to figure out how to connect with your legacy system, with whatever APIs and protocols available, rather than that of you or your customer. Though if you want, JBI provides a plugin you can write for your ESB. Maybe another way to think about it is - its a bit like WSIF, but a bit more pluggable and more useful on the server side (like in an ESB).
I also find it funny that you throw BPEL in there.
Orchestration is just one aspect of the integration problem space. There are many others; load balancing, content based routing, transformation services, rules engines, BAM etc. Its just one example of an integration service that you'd want your ESB to work with.
IMHO JBI is repeating many of the mistakes of workflow architectures/engines namely instituting additional (often single) points of failure by centralizing the service coordination and endpoints in a single container at the same time adding verbosity where simple configuration is sufficient.
How can an API dictate deployment architectures? There's no reason why a JBI container couldn't be deployed inside a SOAP stack on the client or server side to handle mediation with external transports and protocols. e.g. ServiceMix is lightweight and pretty easy to embed.
Earlier, you reference Steve Vinoski's blog that has a similar disconnect. He says that some of the mistakes of late 90s' EAI were overhead of translation to canonical formats and the misunderstanding that Java can't "solve it all". Yet, the JBI spec is heavily dependent on WS and WSDL
JBI assumes an XML service bus and follows the logical model of WSDL. So JBI is designed to work well with WS and WSDL stuff, but equally well with XML over HTTP or XML over JMS or even text & binary data formats over proprietary transport protocols & file polling etc.
which are by nature verbose and canonical and at the same time forces services to communicate through a Java-heavy standard.Whew, rant done. One round of XML-RPC for everyone, I'm buying!
LOL :)
James
LogicBlaze
|
|
|
Message #177229
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
jb lie?
As much as I’d like to see a spec for ESBs, this ain’t it IMHO.
James I actually surprised you are all hemped up on this thing. I am a big fan of ActiveMQ – you guys are doing a great job on that. You must see something I don’t.
I tried to look further past the spec and take a gander at ServiceMix, but if anything that just made me have more of a dislike for JBI. I then figured I’d join the mailing list to get re-educated – but there isn’t one?
When I read the spec. and look at your website, nothing leads me to believe that this is not a coupled mess that will lead to anything but angst, misery, and madness for the poor saps that have to use it.
The spec says and I’ve heard a couple of the folks that are pimping this thing that this spec isn’t for developers that its for vendors – as if its somehow beneath mere developers:
“The primary audience for this specification is system level software engineers who will develop the following:
…
This specification is not appropriate for application developers or business analysts. It is hoped that this specification will facilitate the development of standard service composition tools and services targeted specifically at this group.”
If that isn’t the telltale sign for a failed spec, I don’t know what is. If “mere” developers look at the spec and get gag reflex, why would they get excited about using it?
I don’t know, maybe the impls and some soon to materialize ground swell of support will prove me wrong, but I’m taking it upon myself to set the over under on this thing dying a horrible death at 1 year. Its demise will be worse then EJB.
I think that some people (including me) are reacting negatively to it because we all have suffered through years of the mistakes in EJB and when we see something that looks like it might lead to future pain at work we react negatively.
I don’t think that wonderful things like Spring can save this thing. Sure Spring is great, but that doesn’t do jack for those lovely SOAP errors you are going to get. Or how about a little fun with WSDL? Or a couple dozen javax.jbi.JBIExceptions with a “Not normal enough champ, try again!” errors.
James, you said:
“How can an API dictate deployment architectures?”
I think that is where I am struggling the most. How is this deployed? How does it scale? The first thing I thought I’d see in the spec is this wonderful physical diagram with a million nodes sitting around all over the network. Instead I see this frightening Normalized Message Router in what appears to be 1 JVM. After that I see 4 different RPC styles:
In-Only, Robust In-Only, In-Out, In Optional-Out
Is this a spec or a Ron Jeremy film!!?? I mean, I know that Sun is on the ropes and I wish them the best, but this is sick sick sick.
James, you then go on to say:
“JBI assumes an XML service bus and follows the logical model of WSDL. So JBI is designed to work well with WS and WSDL stuff, but equally well with XML over HTTP or XML over JMS or even text & binary data formats over proprietary transport protocols & file polling etc.”
Maybe you can set my mind at ease and explain how this works? Let me guess SOAP attachments? Or wait! I get a choice SOAP attachments or Base64 encoding in a CDATA field ?!
Anyway, sorry to spaz out, good luck – perhaps you’ll prove me wrong.
|
|
|
Message #177243
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
jb lie?
As much as I’d like to see a spec for ESBs, this ain’t it IMHO. James I actually surprised you are all hemped up on this thing. I am a big fan of ActiveMQ – you guys are doing a great job on that.
Thanks!
You must see something I don’t.I
Maybe I do - we've all got different mental models of this stuff. I guess I've worked on these kinds of problems a fair amount & tried many different ways of solving the problem. e.g. many years ago I helped to develop a product called SpiritBroker at a company called SpiritSoft which tried to tackle some of these kinds of issues - then Ross (another ex-SpiritSoftie) built Mule with a fairly similar kind of model & API. I just see JBI as a better model of what we need to create integration solutions - based on a logical XML messaging service bus abstraction using the NMS.
tried to look further past the spec and take a gander at ServiceMix, but if anything that just made me have more of a dislike for JBI.
Part of the problem I think is that JBI is a big spec with a lot of it only relevent to people who make JBI containers or JBI deployment units - which are necessary - but not exactly interesting for developers. So its a little hard to see the wood for the trees.
My best tip is, ignore the container/component stuff & deployment & management. Just focus on the Normalized Message Router APIs. They are fairly straight forward - much simpler than JMS and they handle various different message exchange patterns rather than just one ways like JMS. (The JavaDoc for this package looks much bigger than it might since there are typesafe interfaces for the different types of MessageExchange).
Basically there's DeliveryChannel, MessageExchange and NormalizedMessage and those are the core APIs of NMR / JBI.
I then figured I’d join the mailing list to get re-educated – but there isn’t one?
Here you go...
http://servicemix.org/Mailing+Lists
When I read the spec. and look at your website, nothing leads me to believe that this is not a coupled mess that will lead to anything but angst, misery, and madness for the poor saps that have to use it.The spec says and I’ve heard a couple of the folks that are pimping this thing that this spec isn’t for developers that its for vendors – as if its somehow beneath mere developers:“The primary audience for this specification is system level software engineers who will develop the following: …This specification is not appropriate for application developers or business analysts. It is hoped that this specification will facilitate the development of standard service composition tools and services targeted specifically at this group.”If that isn’t the telltale sign for a failed spec, I don’t know what is.
The first JBI specification is aimed at getting the JBI container and JBI component developers going. I think & hope future JBI specifications (or JSRs maybe) will address ways of plugging in POJOs into JBI in similar ways to Spring and EJB3 happened after the EJB 1 specification.
In ServiceMix we've gone down the road of supporting POJOs using Spring. I'm sure we can standardize this approach in future JBI specifications.
If “mere” developers look at the spec and get gag reflex, why would they get excited about using it?I don’t know, maybe the impls and some soon to materialize ground swell of support will prove me wrong, but I’m taking it upon myself to set the over under on this thing dying a horrible death at 1 year. Its demise will be worse then EJB.I think that some people (including me) are reacting negatively to it because we all have suffered through years of the mistakes in EJB and when we see something that looks like it might lead to future pain at work we react negatively.
I totally hear you. I've been a long time anti-EJB person myself. Even with the latest EJB3 drafts I still prefer the Spring approach to tell you the truth.
The difference though is, with EJB the hype was all - "this is how you write your business logic" - which caused lots of push back. With JBI folks are saying, application developers keep doing what you're doing - JBI is for those integration companies & tool vendors & EAI type folks to write integration components & containers with. The application developer model will come later if at all (and I'd expect it to be POJO based) - but you can just develop services using Spring / EJB3 and expose them as web services endpoints to join the JBI party.
I don’t think that wonderful things like Spring can save this thing. Sure Spring is great, but that doesn’t do jack for those lovely SOAP errors you are going to get. Or how about a little fun with WSDL? Or a couple dozen javax.jbi.JBIExceptions with a “Not normal enough champ, try again!” errors.James, you said:“How can an API dictate deployment architectures?”I think that is where I am struggling the most. How is this deployed? How does it scale?
However you like :). Put ServiceMix in your WS client and use it like you might use WSIF. Ditto on the server. Or deploy clusters of ServiceMix with ActiveMQ as your load balancing federated network - or use any other communication protocol you like; HTTP with an IP load balancer or another JMS provider (if you really must :) etc.
The first thing I thought I’d see in the spec is this wonderful physical diagram with a million nodes sitting around all over the network. Instead I see this frightening Normalized Message Router in what appears to be 1 JVM.
Rather like with JMS - an NMR could be embedded in a single JVM or it could be a cluster of remote processes on a network. Note that JBI components can be embedded in the JVM or the container can communicate with remote endpoints over different transports.
After that I see 4 different RPC styles:In-Only, Robust In-Only, In-Out, In Optional-OutIs this a spec or a Ron Jeremy film!!??
:)
Its really just modelling the different message interactions you often need to do (and which folks do in JMS already today). e.g. fire and forget one way, one way with acknowledgement, request response etc. JBI's just using the naming conventions in the WSDL 2.0 spec - the concepts have all been around for an extremely long time.
I mean, I know that Sun is on the ropes and I wish them the best, but this is sick sick sick.James, you then go on to say:“JBI assumes an XML service bus and follows the logical model of WSDL. So JBI is designed to work well with WS and WSDL stuff, but equally well with XML over HTTP or XML over JMS or even text & binary data formats over proprietary transport protocols & file polling etc.”Maybe you can set my mind at ease and explain how this works? Let me guess SOAP attachments? Or wait! I get a choice SOAP attachments or Base64 encoding in a CDATA field ?!
:)
The basic idea is a binding component does whatever it needs to do talking to some binary goo - then adapting it to look like a NormalizedMessage in some exchange. A NormalizedMessage is just a bunch of properties (key-value pairs where the value is a POJO) and a blob of XML for the body of the request and optional attachments. How those are physically encoded on a wire or bound to an API is completely up to the binding component to decide.
Then once inside the JBI service bus, you can forget about all that encoding/protocol stuff and work on the normalized message. i.e. JBI uses this API to mediate stuff to binary/SOAP/REST/CORBA/legacy stuff.
Anyway, sorry to spaz out, good luck – perhaps you’ll prove me wrong.
:) Thanks for a great post Mike!
James
LogicBlaze
|
|
|
Message #177257
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
There's the rub. JMS doesn't map too well to things like CORBA, EJB, HTTP or talking to web service endpoints over HTTP. JMS rocks for what its designed for, a standard Java API to messaging systems. However something more abstract and with an XML/WS feel and richer message exchange patterns is required for integration type solutions where you're talking to MOM, HTTP, email, EJB, CORBA and legacy stuff. e.g. take a look at the stuff Iona have been doing, mapping tons of legacy systems to JBI. The problem of trying it with JMS would be leaky abstractions. JBI is trying to integrate many different systems together; whether MOM or Java or C or COBOL. On the contrary, the messaging system *is* the abstraction. Most JMS providers allow direct publishing of HTTP messages and things like CORBA clients and EJBs can push messages to an abstract, declarative JMS end-point. They don't really care how the message is digested or by who, they simply care that the message was reliably published nor do they require an awareness of delivery channels, message exchange factories, etc. This can be easily implemented in JMS without a new deployment format or container leveraging existing investment. ESBs play nicely in this niche without the need for additional standards or containers and provide the same exchange patterns of JBI by leveraging the capabilities of the existing messaging bus.IBMs abstention sums it up well "the JBI specification doesn't represent a sufficient step forward in terms of what we believe our customers need, and above what they can already do."Relax, you don't have to use it :). As an application developer stick to Spring or EJB3. JBI is mostly for folks in the integration / EAI / SOA space to help wire stuff together with BPEL, content based routers, rules engines, transformation engines and protocol adaptors etc. This is exactly the space I play in, not sure why you made the application developer reference. I advise my clients to simplify their architectures whenever possible, complexity is cost for an enterprise and JBI is complexity. It inserts yet another app server into the mix and in the case of legacy systems, forces them to be exposed through that app server as SEs (sorry, I don't really see a way to make my email server comply with the interface contracts required by a BC).I also find it funny that you throw BPEL in there. IMHO JBI is repeating many of the mistakes of workflow architectures/engines namely instituting additional (often single) points of failure by centralizing the service coordination and endpoints in a single container at the same time adding verbosity where simple configuration is sufficient. Earlier, you reference Steve Vinoski's blog that has a similar disconnect. He says that some of the mistakes of late 90s' EAI were overhead of translation to canonical formats and the misunderstanding that Java can't "solve it all". Yet, the JBI spec is heavily dependent on WS and WSDL which are by nature verbose and canonical and at the same time forces services to communicate through a Java-heavy standard.Whew, rant done. One round of XML-RPC for everyone, I'm buying!
+1
|
|
|
Message #177262
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Normalized Messages
I don't quite get the purpose of "normalized messages" as an XML format in the first place. Why bother with WSDL/XML if we can use good ol' plain java objects to the same avail. Of course there would be those that argue that this can not be achieved, but I fail to see why not.
|
|
|
Message #177265
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Normalized Messages
I don't quite get the purpose of "normalized messages" as an XML format in the first place. Why bother with WSDL/XML if we can use good ol' plain java objects to the same avail. Of course there would be those that argue that this can not be achieved, but I fail to see why not.
When you are integrating in an SOA you typically do not have a 100% Java environment. Even in a 100% Java SOA, which is very rare, you typically have version and classpath hell, so serializing Java objects around an SOA is not a great idea - even inside the same JVM with multiple WAR deployments you can have issues.
However you can easily bridge from the JBI normalized message bus to a POJO model so application developers can work at a POJO level using some marshalling or SOAP tool like JAX-WS, JAXB, XStream, XFire, ActiveSOAP or Axis etc.
Also note that the NormalizedMessage uses a TrAX Source for the message content and tools like JAXB support a JAXBSource wrapping a POJO. ServiceMix has a similar XStreamSource for marshalling POJOs with XStream.
A JBI binding can also attach POJOs to a NormalizedMessage as named properties.
James
LogicBlaze
|
|
|
Message #177267
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wonder why ?
JBI is as bad as it was the first release of entity EJB.It seems many people do not get/buy it which tells me "maybe" there is something wrong with it.Webservice technology is little different...everybody gets it but nobody knows why they should use it.. :)yet another "mate" (MArketable TEchnology) to help sell more..
Hmm... I'm not sure where the confusion comes in, although there were some obviously confused questions being asked after the JBI session I attended... I found JBI to be refreshingly straightforward and well thought out. I love the separation between Service Engines and Bindings. Any of you who've had to write FTP utilities for passing files back and forth for integration know what I mean... I'd much rather use someone else's FTP/EDI/etc. code.
I was a bit confused about the difference between the routing in the JBI normalized message bus and the orchestration going on with BPEL, but it was only a 50 minute session...
|
|
|
Message #177272
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JBI is mainly a service providers' programming interface
With a bit of luck this will allow a market for JBI components to emerge as you should be able to use components from different vendors/projects in the same JBI container.
You mean like the market that was supposedly going to emerge around selling reusable EJB components? Or JavaBeans before that?...
|
|
|
Message #177302
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wonder why ?
I was a bit confused about the difference between the routing in the JBI normalized message bus and the orchestration going on with BPEL, but it was only a 50 minute session...
The ESB, in addition to providing transformations from a schema perspective, abstracts discrete services from both a location and transport/technology perspective (MOM, WS, SSB, etc). A BPEL implementation could then be used to orchestrate/aggregate/choreogrraph such services into a business process. This process can, in turn, be exposed as a service as well.
|
|
|
Message #177364
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCA Vs JBI - Standards for Standards (recurse forever :-)
JBI looks like an attempt to create yet another standard for helping integrate standards.
Can someone explain why
1) JBI choose to define yet another standard for
Component development when JCA has most of the
design principals - both from invocation standpoint
and deployment model standpoint.
Shouldn't we have extended JCA for JBI (to include
Normalized messaging concept) - rather than defining
yet another standard with 80% overlap and a few
extensions?
This would have allowed direct integration of all the
100's of JCA connectors already available (and well
tested) in market. And direct access to Tons of IDE
features built to accelerate JCA component development.
2) JBI choose to define a Container and instantiation
model (and will end up with transaction context,
resource sharing, securit context handling API's)
Isn't this awful lot of repeatition of what a JCA
container do?
Note that JCA container is NOT same as complete
J2EE container and has no relation to EJBs whatsoever.
Thanks,
Amit Gupta
|
|
|
Message #177387
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCA Vs JBI - Standards for Standards (recurse forever :-)
I came across some high level thoughts on that from members of the expert group.
http://www.iona.com/blogs/newcomer/archives/000182.html
1) JBI choose to define yet another standard for Component development when JCA has most of the design principals - both from invocation standpoint and deployment model standpoint. Shouldn't we have extended JCA for JBI (to include Normalized messaging concept) - rather than defining yet another standard with 80% overlap and a few extensions?
That would had probably required IBM and BEA to participate ;)
2) JBI choose to define a Container and instantiation model (and will end up with transaction context, resource sharing, securit context handling API's) Isn't this awful lot of repeatition of what a JCA container do? Note that JCA container is NOT same as complete J2EE container and has no relation to EJBs whatsoever.
I believe JCA connectors require an EJB container for servicing inbound calls. Vendors have implemented proprietary extensions for such connectors to work outside the scope of an EJB container though.
It would make sense to simplify connectivity!
|
|
|
Message #177393
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JBI is mainly a service providers' programming interface
With a bit of luck this will allow a market for JBI components to emerge as you should be able to use components from different vendors/projects in the same JBI container. You mean like the market that was supposedly going to emerge around selling reusable EJB components? Or JavaBeans before that?...
I see--at least to some degree--where you are coming from. However, I do believe that there are differences between JBI and EJB/JavaBeans technologies. This again is possibly due to the fact that the former is mainly an SPI, while the latter are mainly APIs (at least for the sake of this discussion, I'm aware that the EJB spec also defines contracts for container implementers etc.).
I can certainly see people competing on implementations for standardized service engines and binding components. For example, I can see people competing on the implementation of something like a BPEL engine or an EDIFACT binding. Moreover, I can see people develop highly specialized bindings that are of interest in specific industries or even only niche markets: clearly it would be beneficial if they only had to worry about the communication issues in order to make an entire JBI container (including all the deployed service) available through such a specialized protocol. Similar things are true for specialized service engines.
Interestingly enough people actually sell applications implemented as EJB and/or exposing application interfaces through EJB. There are even some JSRs for this (check out the JAIN and OSS/J specific stuff at the JCP website or http://www.ossj.org). There are other industries where such standards do not exist but individual companies still do similar things. Now I grant you that these products are not the re-usable components that were envisaged when EJB was invented, but there's a market nonetheless.
But then there is also an emerging market for JSF components.
Now I don't know what your background is or what kind of applications you develop. But chances are that there are people out there who try to solve problems that are different from yours. For some of these, JBI might be interesting and might seem like a step into the right direction.
|
|
|
Message #177395
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JBI is mainly a service providers' programming interface
Now I don't know what your background is or what kind of applications you develop. But chances are that there are people out there who try to solve problems that are different from yours.
I mostly work with integration, a mix of both middleware development as well as more hands-on integration for clients.
This means I am probably at least partially in the target demographics of JBI, and I was quite excited about JBI at first.
But having read the spec a few times quickly took that away.
Maybe that will change once I see some actual use of JBI, but so far I haven't been terribly impressed.
As someone earlier mentioned, there seems to be whole lot of overlap with JCA, and I don't see a whole lot being wrong with JCA to begin with.
|
|
|
Message #177396
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: JBI is mainly a service providers' programming interface
It is emphasized all over that JBI is not for application developers. But what if the developer wants to write his/her application in SOA style. Meaning that the biz logic is separated from the rest as the services and the biz processes orchestrating the service executions. Then a piece of biz logic is written as a component providing the biz logic as a service via various access methods, e.g. direct call or remote call (WS, JMS, RMI, EJB, you name it). The best alternative is that the developer focuses on the component itself without care on the access methods. The specific access method(s) are defined during the deployment phase.
This way we can call the ‘application specific’ (as known today) logic directly and thus achieving the best performance and re-use the ‘service specific’ logic via remote calls. Later on when today’s ‘application specific’ turns into ‘service specific’ (e.g. need for an address book from other apps) then the system admin changes the component deployment descriptors from local-only to remotely accessible (you pick the technology :).
My questions are: Can I write such components using JBI? Do I use the JBI API or not? Am I app developer or a service provider?
|
|
|
Message #177402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Normalized Messages
When you are integrating in an SOA you typically do not have a 100% Java environment. Even in a 100% Java SOA, which is very rare, you typically have version and classpath hell, so serializing Java objects around an SOA is not a great idea - even inside the same JVM with multiple WAR deployments you can have issues.
In my humble opinion, this argument shows a lot of the deficits that technologies like JBI bring into the picture. The normalized messages (as far as I could possibly understand) live _inside_ the JBI environment. I would expect that to be as pure java as it gets. The statements "All JBI containers must support the same WSDL schemas and SOAP version" is more or less equivalend to "all JBI containers must share the same java library for data objects and service interfaces". The one is "simpler" or more "loosely coupled" than the other is nothing but wishful thinking. In other words "If your abstraction layer does not abstract anything the best abstraction is not to abstract"!
|
|
|
Message #177440
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
BTW there's a good description of JBI in Steve Vinoski's article along with some background into the issuesJamesLogicBlaze
Did not learn anything from James' blog entry, except that it was an ad for CodeHaus ServiceMix project.
BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones. Is it the beauty of open source, the lack of information or an acute form of the NIH syndrom ;-)???
|
|
|
Message #177443
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones.
I understand it. James is getting old and it's time for him to make money. But it's too late, James. ;-)
|
|
|
Message #177470
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCA Vs JBI - Standards for Standards (recurse forever :-)
I believe JCA connectors require an EJB container for servicing inbound calls. Vendors have implemented proprietary extensions for such connectors to work outside the scope of an EJB container though.It would make sense to simplify connectivity!
I don't think so. JCA 1.5 components are "most commonly" deployed to invoke MDB, but there is nothing in the specific which limits it to this. One can easily take the JMS events generated by JCA 1.5 components and tie them to other Components - without introducing ANY NEW proprietry (or even Standard :-) ) interface.
Thanks,
Amit Gupta
|
|
|
Message #177472
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
BTW there's a good description of JBI in Steve Vinoski's article along with some background into the issuesJamesLogicBlaze Did not learn anything from James' blog entry, except that it was an ad for CodeHaus ServiceMix project.
I'm sorry my blog post did nothing for you then - at least I tried.
BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones. Is it the beauty of open source, the lack of information or an acute form of the NIH syndrom ;-)???
Erm - when ServiceMix started there were precisely zero open source JBI projects so there was no possibility of reuse. Sometime after ServiceMix was started, there was an ObjectWeb/Iona announcement of Celtix, an open source JBI project (which still has zero source files in it) - though I'm sure the ServiceMix and Celtix communities can work together somehow.
Also Sun announced their open source ESB at JavaOne - when ServiceMix was almost completed (despite me pestering Sun many times to work together on this).
So in summary, ServiceMix started because there was nothing else available to reuse - otherwise we'd have reused it :) Still today ServiceMix is the only Apache licensed JBI/ESB project available.
Projects at Codehaus do reuse code when it makes sense to do so and there is not a license conflict. I find your statement surprising Francois - given we're both part of the Apache and ObjectWeb communities which do reuse and work together when technologies and licenses allow it (and remember most of the folks at Codehaus are also members of the Apache or ObjectWeb communities too).
James
LogicBlaze
|
|
|
Message #177473
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones. I understand it. James is getting old and it's time for him to make money. But it's too late, James. ;-)
Sure, I'm getting old, you got me there. But I'm sorry to break it to you Andreas but I've been making money for quite some time now, I'm still making money today and its looking like I'll be making money for quite some time yet.
James
LogicBlaze
|
|
|
Message #177475
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCA Vs JBI - Standards for Standards (recurse forever :-)
I believe JCA connectors require an EJB container for servicing inbound calls. Vendors have implemented proprietary extensions for such connectors to work outside the scope of an EJB container though.It would make sense to simplify connectivity! I don't think so. JCA 1.5 components are "most commonly" deployed to invoke MDB, but there is nothing in the specific which limits it to this. One can easily take the JMS events generated by JCA 1.5 components and tie them to other Components - without introducing ANY NEW proprietry (or even Standard :-) ) interface.Thanks,Amit Gupta
I quite agree that JCA rocks. Though I think for various reasons (mostly political rather than technical), it was good to get JBI 1.0 out without being dependent on J2EE/JCA. The JBI <-> JCA integration specification can come next - either in JBI 1.1 or a new JSR. I also hope it comes out soon !:)
James
LogicBlaze
|
|
|
Message #177477
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: JBI is mainly a service providers' programming interface
It is emphasized all over that JBI is not for application developers. But what if the developer wants to write his/her application in SOA style. Meaning that the biz logic is separated from the rest as the services and the biz processes orchestrating the service executions. Then a piece of biz logic is written as a component providing the biz logic as a service via various access methods, e.g. direct call or remote call (WS, JMS, RMI, EJB, you name it). The best alternative is that the developer focuses on the component itself without care on the access methods. The specific access method(s) are defined during the deployment phase.This way we can call the ‘application specific’ (as known today) logic directly and thus achieving the best performance and re-use the ‘service specific’ logic via remote calls. Later on when today’s ‘application specific’ turns into ‘service specific’ (e.g. need for an address book from other apps) then the system admin changes the component deployment descriptors from local-only to remotely accessible (you pick the technology :).My questions are: Can I write such components using JBI? Do I use the JBI API or not? Am I app developer or a service provider?
Sure you can, if you want to. Typically I'd expect folks to write application services these days using POJOs and Spring or maybe EJB3 then expose those as endpoints in some container (Spring/Tomcat/Geronimo/JBoss) using either JMS or WebServices. Then a JBI container could perform orchestration, routing, rules etc.
But if you want, you could write your application service as a JBI component or JBI POJO just like folks write JMS specific application services - though I think the trend is gonna be for application developers to write POJO stuff and for there to be some binding between the POJO and the messaging system (JMS / WS / JBI) rather like Indigo in the microsoft world works.
James
LogicBlaze
|
|
|
Message #177503
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones. Is it the beauty of open source, the lack of information or an acute form of the NIH syndrom ;-)??? Erm - when ServiceMix started there were precisely zero open source JBI projects so there was no possibility of reuse. Sometime after ServiceMix was started, there was an ObjectWeb/Iona announcement of Celtix, an open source JBI project (which still has zero source files in it) - though I'm sure the ServiceMix and Celtix communities can work together somehow. Also Sun announced their open source ESB at JavaOne - when ServiceMix was almost completed (despite me pestering Sun many times to work together on this).So in summary, ServiceMix started because there was nothing else available to reuse - otherwise we'd have reused it :) Still today ServiceMix is the only Apache licensed JBI/ESB project available.Projects at Codehaus do reuse code when it makes sense to do so and there is not a license conflict. I find your statement surprising Francois - given we're both part of the Apache and ObjectWeb communities which do reuse and work together when technologies and licenses allow it (and remember most of the folks at Codehaus are also members of the Apache or ObjectWeb communities too).James
Hint: there was a smiley and 3 question marks at the end of my comment...
Kidding not, we end up with at least 3 open source projects targeting the implementation of JBI. My question here is (no smiley, no q mark): does it really make the world a better place to have 3+ OS implementations of JBI, or is is a waste of energy?
|
|
|
Message #177504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
BTW, did not really understand (and the blog entry did not explain) why folks at CodeHaus keep starting new projects instead of joining existing ones. Is it the beauty of open source, the lack of information or an acute form of the NIH syndrom ;-)??? Erm - when ServiceMix started there were precisely zero open source JBI projects so there was no possibility of reuse. Sometime after ServiceMix was started, there was an ObjectWeb/Iona announcement of Celtix, an open source JBI project (which still has zero source files in it) - though I'm sure the ServiceMix and Celtix communities can work together somehow. Also Sun announced their open source ESB at JavaOne - when ServiceMix was almost completed (despite me pestering Sun many times to work together on this).So in summary, ServiceMix started because there was nothing else available to reuse - otherwise we'd have reused it :) Still today ServiceMix is the only Apache licensed JBI/ESB project available.Projects at Codehaus do reuse code when it makes sense to do so and there is not a license conflict. I find your statement surprising Francois - given we're both part of the Apache and ObjectWeb communities which do reuse and work together when technologies and licenses allow it (and remember most of the folks at Codehaus are also members of the Apache or ObjectWeb communities too).James
Hint: there was a smiley and 3 question marks at the end of my comment...Kidding not, we end up with at least 3 open source projects targeting the implementation of JBI. My question here is (no smiley, no q mark): does it really make the world a better place to have 3+ OS implementations of JBI, or is is a waste of energy?
OK :)
I completely agree 100%. I've been working hard to try consolidate the space for a while - I can't say anything yet but expect an announcement soon that you might like :)
James
LogicBlaze
|
|
|
Message #177749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan tries to explain JBI
Don't you think that something is wrong about a standard that needs somebody to blog about it to get it clarified, in even more obscure terms? Certainly, nothing can beat "SOA is not a technology" (c), but "a simple API to a Normalized Message Service and Router along with a component and management model for deploying integration services such as routing engines, BPEL engines, rule systems, transformation engines etc" is also good, IMHO.
Regards,
Slava Imeshev
http://www.viewtier.com
|
|
|
Message #182517
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JCA Vs JBI - Standards for Standards (recurse forever :-)
1) JBI choose to define yet another standard for
Component development when JCA has most of the
design principals - both from invocation standpoint
and deployment model standpoint.
EXACTLY...thank you Amit. I was looking for someplace to ask this question or make the point and you've made it for me. ESB was interesting, but it seems that sun has taken something seemingly simple and easy to grasp and clobbed it into J2EE. Then as you've pointed out, it seems familiar, like something we've seen before...JCA.
Taylor
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
Download the entire book of Jakarta-Struts Live and learn about Struts MVC, Tiles, the Validator, DynaActionForms, plug-ins, internationalization, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
