Wednesday, December 19, 2007
Thursday, December 13, 2007
Monday, December 10, 2007
Saturday, December 8, 2007
Friday, December 7, 2007
Wednesday, November 28, 2007
SJ put the contract out to tender, receiving proposals from many of the large SOA/ESB vendors, including JBoss. After extensive trial period SJ selected JBoss middleware solutions for its integration platform, due to its satisfaction with the product, its use of open standards and the impressive performance when compared to the other solutions.
Working with Redpill, the JBoss-based Integration Platform was launched in January 2007. The first major project, in May 2007, was the creation of a ticket auction system to sell unsold tickets on Tradera.com, the Swedish auction website owned by Ebay Inc. Using the ESB, any tickets which have not been sold by SJ with 2 days of departure are automatically transferred to the Tradera system, where they are available for auction until 6 hours before departure. On the 4th of October 2007 SJ went live with JBossESB! SJ's CEO did a live demo at a press conference to announce the release. The news was reported by every major paper and news channels, so this is a great success for SR, Redpill and JBossESB.
As the first test of the new SJ Integration Platform, the Tradera.com integration project based on JBossESB was a resounding success, and completed within only 4 months. SJ is now able to sell thousands more tickets per week, which previously went unsold. The entire process is automated, with the details of the unsold tickets being passed directly to the Tradera system.
Now that the Integration Platform is up and running, SJ plans to deliver a new project every 2 months. The upcoming projects come from both internal and external demand, for projects which could either be consolidating existing systems or creating new products.
Thursday, November 22, 2007
"I designed a complete framework for a health/wellness startup. It provides health and wellnes services to individuals and corporations/partners via the web and mobile phones. All requests from users go through a business process manager, which in turn orchestrates the process by invoking appropriate services via JBoss ESB. In some instances the logic routes the request to a local Spring managed POJO to execute the service. The same POJOs are actually handling requests via ESB. I created what I called SpringJbossEsbActionProxy to actually grab appropriate Spring managed POJO instead of instantiating a new service class for every invocation.
Though I am not a JBossESB expert, but I am happy I decided to use the product and will recommend it to my future clients."
Thanks for the blog entry Igor. If there are any others out there like this, let us know.
Thursday, November 1, 2007
Congratulations to the whole team!
Saturday, September 8, 2007
- New clustering and fail-over capabilities (thanks to Kurt).
- Much better fault handling and reliability (thanks to Kevin).
- Built-in monitoring and management (thanks to TomC).
- Yet more transport support, including OracleAQ.
- Web Services through JBossWS (thanks to TomF).
- Some very nice integration with jBPM (Kurt) and WS-BPEL (TomF).
- More examples (thanks to Burr and the team)!
Although we're not selling support for this version (that will come once the SOA Platform is released), we are running an Early Adopter Program. If you want to participate, or just want more details, let me know.
So if you haven't already, I'd encourage you to go take a look and give us feedback (as usual). Congratulations to Kevin and the entire JBossESB team, which definitely includes our fantastic community developers!
Thursday, August 23, 2007
Saturday, August 4, 2007
- top-down (business logic development): do as Kurt suggests and develop your business logic using whatever tools and methodologies you think are appropriate. From a high level perspective, this is as critical to your success as ever.
- bottom-up (service development): do as I suggest and think about the contract you want your service to expose and how that would map into message exchanges (content, sync versus async etc.); try to keep it as agnostic to the backend business logic implementation as possible (e.g., don't go exposing individual objects on to the bus). The service is your route into SOA: get it right and you'll be able to leverage all of the benefits the industry keeps pushing.
You can develop these two aspects sequentially or concurrently (even by different teams, which allows each team to concentrate on the right skill sets needed for each role). This is an aspect of what's traditionally called the service lifecycle part of governance. It isn't easy to get it right first time without appropriate tools and patterns. Plus experience helps a lot here: even with tools/patterns, you'll find it easier to do the more you do it.
Thursday, August 2, 2007
We have a big project here. It doesn't involve integrating existing software, but does involve a lot of parts that I think could best be written as web services so that they can be reused by other parts of the business, etc. Is it good to break up a project into services or is SOA better when you are trying to integrate things that aren't meant to go together or stuff that has remote components, etc. Basically, what I'm saying, is that I could put all this stuff into nicely organized java code, or I could break it out into services, and I don't know which to do.
I think the answer is that you should keep on writing your application like you always did. Write a tiered application, and make sure the business logic ends up in the (stateless) middle tier. Now this middle tier will exist of EJBs or POJOs. Next you will have to do two things:
1. Turn them into a service.
2. Register the service with the ESB.
There are multiple ways to go about achieving the above:
Use EJB annotations to turn your POJO into an EJB. You can now register the EJB with the ESB by writing a custom action which calls the EJB. This is demonstrated in the bussines_service quickstart. The action receives a message, some objects can be pulled out and used to send to the EJB. The return value of the EJB can be used to update the message.
Add JSR-181 annotations to bring up a WebService. Now if you do this using JBossWS something cool happens. If the ESB runs on the same instance it auto-discovers these services and registers them with the ESB. Now can can send a soap message to a gateway and the ESB will forward this message to your WebService. So, for example, you can now send SOAP messages in a file to an ftp server. See the webservice_producer quickstart.
If you have used seam to build your app, you can take take a look at Michael Yuan's write up called "Seam-and-SOA" when he attended a JBESB training earlier this week. Also we have an integration example with the Seam DVD store that Burr created. Be on the lookout for this to become a quickstart too.
Use Spring annotations to turn your POJO into a Spring enabled POJO. Now write a custom action to call the bean. See the Spring_OAP quickstart.
I hope this demonstrates the pattern. To be clear on why you should take the extra step to register your service to an ESB, this is to obtain capabilities like routing to multiple destinations, content-based-routing, message transformation, service orchestration (jBPM or BPEL), service-human workflow integration (jBPM), bringing up services over different protocols (ftp, file, etc). I guess that list is pretty well documented on the project page.
Monday, July 30, 2007
i) they should scale from several to hundreds and thousands of participants/services.
ii) they should be loosely coupled, so that changes of service implementation at either end of an interaction can occur in relative isolation without breaking the system.
iii) they need to be highly available.
iv) they need to be able to cope with interactions that span the globe and have connectivity characteristics like the traditional Web (i.e., poor).
v) asynchronous (request-request) invocations should be as natural as synchronous request-response.
Scalability and availability are possible with other technologies, such as CORBA. Although (ii) and (iv) can certainly be catered for in those technologies as well, the default paradigm is one based on an implementation choice: objects. Objects have well defined interfaces and although they can change, the languages used to implement them typically place restrictions on the type of changes that can occur. Now although it is true that certain OO architectures, such as CORBA, allow for a loosely coupled, weakly types interaction pattern (e.g., DII/DSI in the case of CORBA), that is not typically the way in which applications are constructed and hence tool support in this area is poor.
There is no objective way in which to approach the question of whether SOAs can be catered for in traditional environments. The answer is obviously yes, because no new language has been invented for SOAs and current tools are used to develop them. However, the real question is what is the best paradigm in which to consider an SOA that allows it to address all 5 points above.
Concentrating on the message and making it the central tenant of the architecture is the key to addressing the 5 points. How this is mapped onto a logical architecture (objects, procedures, etc.) and ultimately onto a physical implementation (objects, methods, state, etc.) is not important. The fact is that many different implementations and sub-architectures could be used. So what is the fundamental concept or mind-set in which to work when considering SOA?
The answer is that this is not about request-response, request-request, asynchrony etc. but it's about events. The fundamental SOA is a unitary event bus which is triggered by receipt of a message: a service registers with this bus to be informed when messages arrive. Next up the chain is a demultiplexing event handler (dispatcher), that allows for sub-services (sub-components) to register for sub-documents (sub-messages) that may be logically or physically embedded in the initially received message. This is an entirely recursive architecture.
JBossESB does not impose restrictions on what constitutes a service. The ideal SOA infrastructure encourages a loosely coupled interaction pattern between clients and services, where the message is of critical importance and implementation specific details are hidden behind an abstract interface. This allows for the implementations to change without requiring clients/users to change. Only changes to the message definitions necessitate updates to the clients.
As such, JBossESB uses a message driven pattern for service definitions and structures: clients send Messages to services and the basic service interface is essentially a single doWork method that operates on the Message received. Internally a service is structured from one or more Actions, that can be chained together to process incoming the incoming Message. What an Action does is implementation dependent, e.g., update a database table entry, or call an EJB.
When developing your services, you first need to determine the conceptual interface/contract that it exposes to users/consumers. This contract should be defined in terms of Messages, e.g., what the payload looks like, what type of response Message will be generated (if any) etc.
Clients can then use the service as long as they do so according to the published contract. How your service processes the Message and performs the work necessary, is an implementation choice. It could be done within a single Action, or within multiple Actions. There will be the usual trade-offs to make, e.g., manageability versus re-useability.
Saturday, July 28, 2007
- how to start and stop JBossESB in debug mode from within the JBossIDE,
- how to deploy your first service: Hello World!
Wednesday, July 4, 2007
However, the native SOAP stack in JBossWS 2.x depends on JAXB for SOAP<->Java binding. This raised an issue for us because JAXB is 100% driven by annotations on the Java binding classes. If your Webservice Java bindings are not JAXB annotated, JAXB will not marshal/unmarshal SOAP<->Java properly (see JAXB forum post).
A classic JBossESB usecase is one where the ESB is used to expose a Webservice interface for an existing Java based Service that doesn't already expose a Webservice interface. In this situation, you can use the ESB to define a "wrapper webservice" that maps calls to the target Service (we'll be automating this in a future release). In this situation you'll also want to use the Java types that define the target Service, when defining the "wrapper webservice" e.g. use an EJB's remote interface, without modification, to define a JSR 181 wrapper service.
So, in the usecase outlined above, the Java types that define the target Service are obviously not going to be JAXB annotated (or at least they typically will not be). At this point, using JAXB (and therefore JBossWS 2.x) is no longer an option, since JAXB will not work against an unannotated interface.
The JAXB RI API supports setting a RuntimeInlineAnnotationReader during JAXBContext creation. We've used this feature to support "Introduction" of the JAXB annotations, from an XML configuration, for interfaces that are not JAXB annotated. It works by creating dynamic proxies for the annotations as they are requested by JAXB RI, with the dynamic proxies being fed via an XML configuration. See "JAXB Annotation Introductions" for more details.
Having done this, and having talked with the JBossWS guys, it would appear as though users of JAXB are not the only ones that run into trouble as a result of not having an alternative to a purely annotation driven configuration model (JSR 181 being another example that Thomas Diesler and Hieko Braun have pointed out). Is there room for a general purpose mechanism that can be used to manually "Introduce" annotations in situations like this? Obviously you could suggest that implementations should just support 2 configuration models - internal (annotations) and external (something else - fed by XML, or whatever). But surely a single underlying configuration/metadata "access" mechanism (the Annotations API) is preferable.
The Annotation Reader approach (ala JAXB Introductions) seems to offer something along these lines, but it would be nice if it could be done without requiring the annotation reader i.e. it would be nice if we could introduce annotations directly on the Annotations API (AOP style).
Since then we've added the SOAPProcessor (SOAP onto the bus) action to complement the SOAPClient action (SOAP off the bus). Check out the Webservices/SOAP components and let us know what you think.
We had some fun upgrading to JBossWS 2.0 after we ran into issues with JAXB and how it doesn't allow us to use Java bindings that are not JAXB annotated. More on that in another blog.
Tuesday, May 29, 2007
We've just added some functionality to the ESB in support of making invocations on external Webservice Endpoints from within the ESB. This functionality is available right now from SVN and will be officially released in the 4.2GA release (July '07).
The main feature is the ability to construct SOAP requests and consume SOAP responses without having to generate proxy code. All that's required is configuration of the “SOAPClient” action class, specifying the location of the Endpoint WSDL and the name of the operation to be invoked.
Get all the details about the SOAPClient action from the WIKI.
This functionality is very important because it supports SOAP unaware endpoints making invocations on SOAP endpoints. This is only half of the new Webservices functionality being added for 4.2GA. We're also adding functionality to support exposing Webservice interfaces for Webservice unaware endpoints. Milestone Release 2 (MR2) of JBossESB 4.2 prototyped this functionality in the JBossWSAdapter action class. We are about to rework and enhance parts of that prototype for the GA release. More on this later.
With both of these pieces of functionality in place for 4.2GA, not only do we have strong support for Webservices in general, but we also open the door to supporting WS-BPEL style orchestration of Webservice unaware Services through the ESB. To this end, JBoss has partnered with Active Endpoints. Active Endpoints have developed a 1st Class WS-BPEL Engine called ActiveBPEL.
To see how well JBossESB and ActiveBPEL work together, see the flash demos available on the ESB labs pages.
Thursday, May 17, 2007
The questions showed that people really understood the presentation as well as the product, and almost half the people hung around for another 45 minutes to interact with the team to get their questions answered. If we ended up not answering your question, then please take them to the forum, and we'll try to answer it there. The slides have been attached to the wiki , see the link under the 'Presentations' header. If you missed it, there is another session next week May 22nd. You can sign up at the same place in the wiki. A recording of the webinar will be available next week. Don't hesitate to give us any feedback right here in the blog.
I hope you enjoyed it as much as I did :).
Tuesday, May 8, 2007
- WS-BPEL support: now have your BPEL processes exposed through JBossESB.
- Web Services support through JBossWS integration.
- More integration with EPRs for messages, such that faults and replies can be routed via the message header information.
- Support for Oracle AQ as one of the JMS transports.
- Some cool new quickstarts.
- Closer jBPM integration.
If you haven't taken a look at JBossESB yet, then I'd encourage you to do so now and give us feedback. This is a community development effort, so come and get involved however you can.
Wednesday, March 28, 2007
I recently performed some performance profiling of Smooks based XSL transforms, comparing them against standalone XSLT. This was done in order to get a better idea of the overhead incurred by using Smooks to perform XSL based transforms. I'll attempt to answer the question of why you'd bother applying XSLT via Smooks in future blog.
The comparisons were run on a Dell Latitude D820 (2GHz Dual Core), 2 GB of RAM, running Windows XP, running jdk1.5.0_10.
For this round of comparisons (I hope to do more some time in the future):
- I selected a very simple message format (an
with multiple ), as well as a very simple set of XML to XML transformations to be performed on that message. I wanted to keep it simple in order to keep the resulting XSLTs as simple as possible. This way I hope I can get a "worse case scenario" re the overhead incurred while using Smooks to perform XSL transforms. The tests are available here.
- I compared the number of messages transformed in a 6hr time period.
- I compared the results produced by using the following XSLT processors: Sun XSLTC (JDK 1.5), Xalan 2.7.0, Saxon 8.7.
- I compared the results produced by a DOM Source and Result for XSLT Standalone versus a DOM Source and Result on Smooks.
- I compared the results produced by streaming both the Source and Result for XSLT Standalone versus a DOM Source and Result on Smooks (Smooks only supports DOM based XSLT).
- I tested against 10 input messages ranging in size from 20K to 200K. That is, 10 threads running concurrently, continually transforming, each pausing for 10ms between iterations.
- The message bytes were read and buffered in memory so as to avoid File IO variabilities.
- During the timed test runs, I didn't compare the transformation output against the expected output. However, I did perform preliminary test runs on all processors and verified that the output produced across the board was consistent. The one exception to this was Xalan 2.7.0, which has a concurrency bug that results in the transformed output not being consistent when the XSL is not applied in a synchronized fashion. I still ran the tests against Xalan unsynchronized, so as to get an idea of how it would perform, assuming the absence of this bug.
In summary, the performance figures are as follows....
DOM based XSLT Vs Smooks based XSLT (also DOM based):
|Total Bytes - XSLT||Total Bytes - Smooks/XSLT||Smooks Relative Performance|
Stream based XSLT Vs Smooks based XSLT (DOM based):
|Total Bytes - XSLT||Total Bytes - Smooks/XSLT||Smooks Relative Performance|
To understand what this means for JBoss ESB Transformation, you first need to understand what it means for Smooks. At the top of this blog I mentioned how Smooks implements a fragment based approach to message transformations (including some of advantages of that approach). The down side to this fragment based approach is that Smooks currently supports this via a DOM based model.
So what does all this mean for JBoss ESB Transformation. Well, because JBoss ESB Transformation relies on Smooks to manage and apply transformation logic (including XSL transforms), it means that JBoss ESB cannot currently avail of the performance advantages offered by streaming messages into an XSL Processor. So, for a transformation where you don't need to features offered by Smooks (fragment based transforms etc) and you want to implement the transformation in XSLT, the performance hit is quite significant.
Luckily, this is not all that difficult to work around for JBoss ESB because we can simply implement a native XSLT ActionProcessor that can apply XSLTs using streaming. This is just a couple of lines of code - no big deal. From a Smooks perspective, there's a little bit more involved, but I don't think all that much. In short, Smooks could simply check the resources targeted at the message exchange in question, and if there's only one, which is targeted at the "docroot" fragment, and it's a stream supporting resource, then stream it - no need to DOM'ify. This would enable JBoss ESB to have the best of both worlds again... stream based XSLT + management and exchange based selection of transformation resources (via Smooks). We'll keep this for another blog :-)
Saturday, March 24, 2007
There have been quite a few changes between 4.0 GA and 4.2 MR1, including:
- jBPM integration: you can now invoke a service, use an ESB action to start a new process and signal a process, all from within the ESB.
- Groovy scripts can be embedded within the ESB via the action framework.
- Configure your ESB graphically, via a community donated editor.
- Scoped deployments within the same ESB server; see Kurt's earlier posting.
- JBoss Messaging 1.2.0GA is now the recommended JMS implementation, both for standalone and embedded operation.
- We've improved the performance of the ESB, particularly if you use JMS as your transport.
- There's now a Dead Letter Queue for the CBR; if it can't route your message then at least it can be persisted for later offline management.
There's more to come too as we move towards JBossESB 4.2 and 5.0. Hopefully this will give you a flavour of what's to come. Over the next few days, members of the team will post a few entries here on different topics of interest around our ESB. If there's anything specific you'd like to see an entry on, just let us know and we'll try to accommodate you.
Thursday, March 22, 2007
jbossesb.xml is now called jboss-esb.xml and it lives in the META-INF directory of the archive together with the MANIFEST.MF. Your custom action classes go in the root of the archive and optionally you can add a queue-service.xml definition to bring up any Queues or Topics that are specific to this ESB package.
All the ESB libraries and property files are now consolidated into one jbossesb.sar archive and you can simply deploy the esb archives to the deploy directory. Yes archives (plural), you can deploy multiples of them!
Monday, March 5, 2007
This brought up a nice discussion on EPRs, which was interesting for me, since JBossESB is using EPRs. EPRs look a lot like URIs, but they can contain more information, and they are not identifiers like URIs are. In fact an EPR should be able to "fall back" to a URI is its simplest form, in a manner that is consistent with REST. Let's learn from the Web and try to make the Web and Web Services live in Harmony. Both architectures are in use and the market place will determine where these technologies develop. Maybe use the URI part of the EPR as identifier. The Web has taught us the power of the URI. Let's see what WADL can do for REST.
Finally I wanted to mention a presentation by David Booth on Resource Description Framework (RDF). His point is that to (automated) service interaction is hindered by non-consistent data naming ('babelonization'). And RDF provides a framework to describe a piece of data in a standardized manner such that data integration can be automated. Such a framework would reduce the complexity of service integration dramatically. Maybe something our Smooks engine can take advantage off by generating transformations on the fly.
It looks like time and the marketplace will tell if and how the two Webs will converge.
Friday, March 2, 2007
The first day was titled "What's missing from the picture - new stuff to consider". The gist of that day was that some people fully embraced Web Services with SOAP and WSDL. The speed of development is great, and there are a great number of extension standards to make Web Services into first class Services. I actually presented a paper by Mark to push towards a general context standard in Web Services.
However other voices were calling to "Stop making standards and let's make things work". This quote is from Paul Downey from BT and it resonated with a lot of other people in the meeting. Basically vendors are still working out some interoperability issues and there are no 'best practices' available on how to really use SOAP with all it's WS-* extensions. They were calling on the w3c to provide somekind of test suite and knowledge base. In my humble opinion I see a huge oppertunity for the Open Source community to jump in here, and for the JBossESB in particular. I think we should lead the way to bring WS-* to the developer community. JBoss has always been very much in touch with the developers, and I think there is an opportunity for the JBossESB team to show how these standards can be used to right way.
Well I'd love to hear what you think. Stay tuned for what happened on day 2 of the workshop!
Tuesday, February 27, 2007
However, over the years SOA has become more widely accepted and Web Services as the preferred implementation choice. The loosely coupled, long duration nature of inter-organisation interactions suits SOA well and the amount of vendor support for Web Services (as well as using HTTP) makes them a natural fit. The weaknesses of the CORBA and DCOM distributed object models have been well reported over the years (and firewall vendors didn't help) and both SOA and Web Services proponents have talked about not falling into the same pitfalls.
So it is with some surprise thatI came across this from the W3C TAG. I don't have a problem with defining state in Web applications, but it's got to be done right or we will revert to the closely-coupled nature of the past. It's nice to see Dave saying that his company's application server uses WS-Addressing and yet is scalable and fault tolerant, but that doesn't address the point we've been making: the general notion of context is a better approach. It is more scalable and much better suited to loosely coupled interactions. That's why JBossESB has had the notion of context at its core from the start.
Sure, you can use a tightly coupled interaction pattern like object keys in your favourite application server or ESB, but that doesn't necessarily make it right. What it does do is make it more complex from implementation, management, scalability, fault tolerance and flexibility perspectives. You may be convinced by your favourite sales person today, but without a suitable loosely coupled architecture at the heart of your SOA infrastructure or ESB, you may repent at leisure!