What we will highlight in this presentation is first of all WHY you would want to use an ESB. I’ll make a comparison with Ant there. As with Ant, components are important: they do all the work. We’ll talk more about what components there are and what they do. When I’ve covered that you’re probably curious about what GlassFish ESB looks like, so we’ll give a brief demo of GlassFish ESB. After that we’ll show more of the architecture, the open source and open standards aspects of GlassFish ESB, and finish with a look into the future of GlassFish ESB.
There are people who don’t see the need for integration middleware. Their reasoning is that you can write integration applications with EJBs only, or with something like Spring beans. After all, EE provides transactions, and also provides a webservices stack. Should you need other tasks, just add the appropriate third party jars. And if you need support for long running processes, just use JPA or Hibernate to store state in the database. That’s indeed possible, but is that really the smartest thing to do? Let’s take a look at builds: there are a lot of similarities between builds and integration applications. Btw, what I mean with a “build” is when you have a bunch of source files, and you need to convert them into binary artifacts such as EAR file, jars, or a complete installer.
If you look at builds, I’m sure you recognize that there are hundreds of different projects in the version control system of an enterprise, and so there are hundreds of builds to convert these projects into applications or application components. Almost all of these projects need compilation, need jarring up the class files, etc. So there’s a lot of commonality between these projects. Most applications are not throw-away – they will stay around for many years. So they have to be maintained over time. Another interesting aspect is that it’s not just developers who have to deal with build scripts: there’s typically a configuration management group that will build and release enterprise applications. So the mechanism that is used to build the projects should be understandable by multiple groups or departments. Lastly, this build process typically also needs to be automated and managed.
Yes, you can write a build in Java. But you’ll end up with a lot of duplicate code: any time that you need to compile code, you end up with at least a dozen lines of java code. Similarly for jarring up things. Each build ends up with a lot of java code, and as a result it’s difficult to quickly get an overview of what’s going on. In other words, the Java language doesn’t provide the right abstraction level. It’s no surprise that nobody develops builds by doing everything in Java code. Instead, people use Ant. It has a DSL that provides a much higher level of abstraction. You get a lot of work done with just a few lines of Ant script, because Ant comes with a lot of built-in tasks. There’s a task for compilation, there’s a task for jarring, etc. And using each task typically only requires one statement. Some of these tasks are trivial, but there are also tasks that would require a *lot* of lines of Java code should you want to code it yourself. And if there’s something for which there is no task yet, you can write your own in Java, and plug it into Ant. Another important aspect is that in Ant you don’t really “code” as in a traditional programming language. In stead, you sort of “lay out a flow of processing steps”. Lastly, there’s support for Ant in all popular IDEs. All of this makes Ant much more productive for writing builds than Java code. And not just developing a build script is faster, maintaining existing builds and managing them is also a lot easier.
Integration projects share a lot of similarities with developing builds. First of all, like with builds, a reasonably sized enterprise has hundreds of integration projects. There is a lot of commonality in these integration projects: they all deal to some extent with these three activities: connectivity, that is connecting to different systems, be it legacy systems or web services. Second: data transformation: converting from one file format into another, or from one business object into another, or from one message into another. And thirdly, there’s always some orchestration to do, or something to coordinate, or some business logic that dictates what messages need to flow from what to what. Integration projects typically stay around for many years. During that time they of course evolve: new systems are added, data formats or messages change, new capabilities are added, etc. And lastly, just like Ant builds need to be automated, integration projects run continuously and as a result, require management and monitoring as well.
Now that I have shown that there a lot of similarities between the requirements for doing builds and for doing integration, let me show you how an ESB provides the same kind of relief for integration as Ant did for doing builds. Like Ant, an ESB comes with components. These components target the three typical activities in integration: connectivity, data transformation, and business logic or orchestration. Some of these components do trivial things, but there are also components that do a lot of heavy lifting. That is, if you had to write the functionality that these components provide yourself, it would take you many man months. And like Ant, if there’s functionality for which there’s not an off-the-shelf component, you can write it yourself in Java and plug it into the ESB. Another benefit is that an ESB provides a high level abstraction to lay out the message flow, to wire components together. This abstraction is higher that what pure Java would give you. Another important benefit is that using components and this higher level abstraction, you can accomplish a lot with no or just a few lines of code. With Ant we saw that there’s strong IDE support and that it increases productivity. Some ESBs also have strong IDE support. And all this makes it much easier to manage large numbers of integration projects.
Let’s take a look at a typical integration example. It will provide context for some of the basic operations in integration. And we will use a part of this example later to do a demo. Let’s say that there’s an enterprise that many years ago installed an ERP system. One of the things that the ERP system does is producing purchase orders. Let’s say that it does that in the form of a batch of orders in CSV format. A purchase order is a typical “business object”, that is something that has a particular meaning in many different contexts. Each system may have its own representation of a purchase order, perhaps even more than one. Now, many enterprises try to standardize these business objects. In other words, they will prefer a canonical purchase order so that all developers know how to represent a purchase order, and it’s much easier to deal with when it flows through the enterprise than dozens of different representations of a purchase order. Also, it will reduce the number of conversions from one data format to another: if there are 12 different representations of a purchase order, you might end up with a maximum of 66 possible transformations. If you use a canonical message as an intermediary, your maximum would only be 12. So, the first thing that needs to happen is that this CSV file needs to be converted into canonical messages. And this is the job of an integration application. So, the integration application picks up the file and converts it. The conversion typically cannot be a simple mapping: likely not all data that is necessary to fully populate a canonical purchase order is there in the CSV file. As a result, the integration application not only needs to take each record from the CSV file, but it also needs to lookup the data that’s still missing in the canonical message. The integration application typically needs to connect to other systems for that. For example, the canonical message might require the name of company at which the purchase order is going to be placed, while in the CSV file there’s only the DUNS number of company. The addition of data to a message is called data enrichment. Let’s say that there is an approval system that needs to approve the order before it can be sent out. There will be another integration application that will take the canonical message and knows how to interface with the approval system. Again, this interaction likely involves converting the canonical message to a data object specific to the approval system, and it likely also involves connecting to the approval system. If the order is approved, it can be sent to the trading partner, perhaps via a B2B gateway, or through a fax system. This may involve a transformation to EDI-X12 or to postscript. And it likely also will involve connectivity to the B2B or fax system. Let’s say that this is how the system and integration flow was as it was five years ago. Since then, perhaps the company built a financial dashboard, displaying all financial liabilities and receivables. One way is to have this monitoring system hook into the flow of purchase orders, resulting in another integration, this time of the monitoring system. Again, some time after the system was brought online, users of the ERP system wanted to know when a purchase order actually went out the door. Rather than changing the approval system, the company chose to hook into the purchase order stream and write a little email application. Another thing that was not originally foreseen is that the mailroom wanted to know ahead of time of incoming shipments. Again, the solution was to hook into the purchase order stream.
On this slide we see the purchase order stream from the ERP system in the left top corner, to the B2B gateway or TDN system or fax system on the right. In green we see the existing systems, for instance the ERP system, the approval system, etc. In orange we see the integration applications and integration middleware that tie these things together. In yellow we see the messages flowing through the system. And each box or envelope represents one integration application or one integration flow. The advantage of having these separate applications is that you can easily add another one without having to change existing systems. For instance, let’s say that the enterprise recently introduced a web-procurement system where employees can order items bypassing the ERP system. I’ve added this system in the left bottom corner, and it’s easy to imagine that this could be done without any changes to the other applications. So the concepts that I’ve highlighted here are integration applications and the fact that there are many of them. I’ve introduced canonical messages, and I’ve shown two of the three basic activities: data transformation and connectivity. We’ll get to the third one, orchestration and business logic, in a minute. These three activities are performed by components. Let’s look at those.
First, let’s take a look at connectivity. Most ESBs have support for SOAP, File, FTP, JMS, email, a scheduler, and database connectivity. If you look at OpenESB, you’ll also see a lot of other adapters: for instance SAP, CICS, CORBA, MSMQ, SWIFT, etc.
Data transformation is often done through XSLT. This may suffice in case you’re only dealing with XML data, and even then XSLT requires a different way of thinking that requires a lot of time before you’re proficient in XSLT. Therefore, OpenESB also provides encoders and decoders to transform different file formats, for instance CSV, into XML. And it provides options besides XSLT to transform data in Java or in BPEL. That means, there’s powerful tooling to make this easy.
An integration application needs to take messages from one place to another, send requests, wait for replies, etc. This is called orchestration. It may also need business logic, e.g. decision logic. One way of doing that would be in Java. OpenESB supports this: users can write this logic in the form of EjBs, POJOs. However, writing Java code is not always the best solution. So OpenESB also has very strong support for BPEL. More about that in a minute. It also has support for complex event processing, which can be used for event driven architectures. There’s also a component for workflow, and one for integration patterns.
Let’s talk a little bit more about BPEL. First, let’s take a look at a BPEL process in the OpenESB IDE. As you can see there’s a graphical depiction of a flow. I’ve depicted here the integration application that interacts with the approval system. We’ll show you how to create this application later.
BPEL is an ideal tool for orchestration, that is you can use it easily to say that when you receive a message from X, send a request to Y and wait for the response, and then send the data to Z. It provides support for asynchronous interactions. That means that if you send a request to Y and get the response through a different channel, you need to associate the response that you just got in, with the original request, or in other words: you need to correlate the response with the request. BPEL provides support for that. You might think that that is not that difficult: you just store the state in the database. That is not that easy though if you want to make it easy on the user by not bothering the user with defining a database schema. Also, if you want to support clustering, you’re suddenly in a heap of trouble. The BPEL engine in OpenESB takes care of all of that. Remember, earlier I said that there are trivial components and components that do a lot of heavy lifting? BPEL is one of these heavy lifting components. Another difficult thing that BPEL does is providing support for compensating transactions. The OpenESB BPEL engine supports XA. But if you have a long running transaction, for instance you send a request to a trading partner over the internet, and you would get a response back minutes or hours later, you of course cannot use XA. If a negative acknowledgment comes back, you cannot roll back the transaction. Instead, you need to undertake a different action to undo the original action. In other words, you have to compensate for the original action. All of these things become really easy through the OpenESB IDE. It provides a very user friendly way to define orchestrations and to add correlations, compensating transactions, etc.
If there’s functionality for which there’s no component yet, all ESBs let you write your own component that you can then plug into the ESB. The component needs to be implement particular interfaces so that the ESB can install, uninstall, start, stop, and manage the component. Also, the component needs to have an understanding of the messages that it receives. For many ESBs, these interfaces are specific for that ESB or that vendor. OpenESB on the other hand uses industry standard interfaces: JBI. JBI is a standard that defines these interfaces. So, components that you develop for OpenESB are also portable into other ESB runtimes, for instance ServiceMix. OpenESB has a strong preference for open standards where ever possible. I’ll get back to that a little later.
To keep components independent from each other, components are connected to each other at a late stage, typically in an XML file that is outside of the components. This XML file is often hard to read and hard to edit. OpenESB is no exception: in each integration application there is such a file that specifies which components talk to each other. Where OpenESB is different is that there is a graphical editor to wire the components together.
Here is a picture of what that looks like: in the solid envelope in the center is a screenshot of the CASA. This represents the integration application that I copied to the right top corner.
All of this, the use of off the shelf components that do both the easy stuff and the heavy lifting, the configuration of the components rather than programming them, the graphical editors, etc. lead to less code, faster development, and easier management. Let us prove that to you in a little demo.
Earlier I mentioned OpenESB’s preference for open standards. I did that in the context of writing components that you write against an industry specification so that they are portable between different ESBs. The spec is JBI. The other area where open standards are important are with interoperability with other systems, not the compatibility in terms of class loading, but in terms of wire protocols. It’s important that the ESB can talk to other systems, even other ESBs. This avoids vendor lock in. OpenESB even goes so far that the communication between different installations of OpenESB is done purely through open standards. This makes it easier to patch or to install different versions. Let’s look at this architecture…
As described in the JBI spec, the communication between components happen within the same VM. The advantage of this is that you can easily pass the security context, transaction context from one component to another. It also makes it easy to pass messages by reference, to pass around streams of large messages rather than having to persist a large message in JMS and having the next component read it back again. That components typically share the same VM doesn’t mean that an OpenESB installation is limited to only one machine. OpenESB supports homogeneous clustering. That means that each node in the cluster has the same components and has the same configuration. Nodes typically don’t have to communicate with each other because the load balancing is done externally. If one OpenESB cluster needs to communicate with another cluster, it will use standard protocols like WS* to communicate. In case nodes within the same cluster need to communicate with each other, which as I mentioned is the exception rather than the rule, there’s also a facility for that. If one component wants to send a message to another component, there of course needs to be agreement on the message type. Rather than inventing a new description format for that, we preferred the use of industry standards. In OpenESB you describe this using WSDLs. An abstract WSDL is nothing more than a description of what messages are sent and received. You can also add information to it that describes how the message is sent, i.e. protocol information which is there in a concrete WSDL.
Here’s picture of an OpenESB runtime. In the runtime you see three installed components: the HTTP BC, the BPEL SE and the EE SE. The EE SE makes the whole EE application server look like an ESB component. In the components you see parts of an application. These parts are called service units. Together the service units make up an application or service assembly. The service units expose WSDL interfaces. Components can exchange messages with other service units through these WSDL interfaces and through the NMR. The NMR is a router that routes messages from one component to another. It provides complete isolation for components and makes message exchanges completely asynchronous.
OpenESB is open source. OpenESB is the name of the open source project. It was started 4 years ago in 2005. It is led by Sun, but not dominated: there are several external contributors who also contribute code and components. There are also partners who provide services on top of OpenESB in the marketplace. There is a lot going on in OpenESB!
We have a great number of components: 43. The problem with having this many components is that you’ll end up with a gigantic installer if you bundle all components in the same installer. It also becomes very difficult to ensure that all components have the same level of testing and quality: some components are still in development while other components are already of release quality. So it becomes very difficult to have a release. So what we did in OpenESB is create a smaller distribution: it only has the runtime and a number of core components. We called this distribution GlassFish ESB. Not surprisingly it is bundled with GlassFish. It is also bundled with NetBeans by the way. With this smaller number of components you’ll end up with a smaller installer. If users want additional components, they can easily download them and install them into GlassFish ESB. More importantly, it’s also easier to make sure that the components in this smaller distribution are all thoroughly tested and are all at release quality. Another important aspect is that Sun provides commercial support for GlassFish ESB. Many enterprises will not take a product into production, especially if it is a crucial part of their infrastructure, if there’s not a company that they can call should something go wrong.
What is next for GlassFish ESB? We are about to release version 2.1. The next major release will be version 3. This will be based on OSGi and will come with GlassFish v3. Some of the new features are a different build system, interceptors, patterns out of the box, and a new language to wire components together. Let me show you:
Here you see an integration flow
And here you see a textual description of this flow.
And here you see a graphical editor. If you want to see v3 in action, come to our booth in the pavilion and attend the session on integration patterns. Also of particular interest is the session that I’m doing with Andi Egloff on “lessons learned”. On Friday morning there’s a session on a number of interesting aspects of BPEL in general, and the BPEL implementation in OpenESB.
Get Your Apps On The Bus
GlassFish TM ESB: get your apps on the bus! Frank Kieviet OpenESB Community Manager Sujit Biswas Senior Software Engineer Sun Microsystems
Agenda <ul><li>Why use an ESB? </li></ul><ul><ul><li>ESB = “Ant for integration/SOA” </li></ul></ul><ul><li>Components </li></ul><ul><li>Demo </li></ul><ul><li>Architecture </li></ul><ul><li>Open Source: OpenESB and GlassFish ESB </li></ul><ul><li>What is next? </li></ul><ul><li>Q&A </li></ul>
Why use an ESB? <ul><li>You can do anything with Java code and an application server (e.g. EE), no? </li></ul><ul><ul><li>EE provides transactions, JAX WS </li></ul></ul><ul><ul><li>Use third party jars for misc. tasks </li></ul></ul><ul><ul><li>Add JPA for state management </li></ul></ul><ul><li>Question is akin to “Why use Ant?” </li></ul>
Analogy: builds <ul><li>Characteristics of builds </li></ul><ul><ul><li>Each project has its own build: hundreds of builds per enterprise </li></ul></ul><ul><ul><li>Many repetitive tasks (e.g. compiling, jarring, …) </li></ul></ul><ul><ul><li>Builds must be maintained over time </li></ul></ul><ul><ul><li>Builds must be understandable by Configuration Management, not just developers </li></ul></ul><ul><ul><li>Build process must be automated and managed </li></ul></ul>
Doing builds in Java or in Ant? <ul><li>Yes, you can write a build script with just Java, but: </li></ul><ul><ul><li>Code duplication, repetitive tasks, lots of code </li></ul></ul><ul><ul><li>Java is not at the right expression level </li></ul></ul><ul><ul><ul><li>Difficult to get an overview, difficult to quickly understand, difficult to maintain </li></ul></ul></ul><ul><ul><li>Nobody does it! </li></ul></ul><ul><li>Everybody uses Ant </li></ul><ul><ul><li>Provides a higher level abstraction </li></ul></ul><ul><ul><li>Gets a lot done with just a few lines </li></ul></ul><ul><ul><ul><li>Dozens of built in tasks (some simple, some do heavy lifting) </li></ul></ul></ul><ul><ul><ul><li>Extensible through custom plug-ins </li></ul></ul></ul><ul><ul><li>Favors declarative programming (configuration) over coding </li></ul></ul><ul><ul><li>IDE support </li></ul></ul><ul><ul><li>Leads to fast development </li></ul></ul>
Characteristics of Integration and SOA <ul><li>Hundreds of integration projects per enterprise </li></ul><ul><li>Lots of commonality (some simple, some hard): </li></ul><ul><ul><li>Connectivity </li></ul></ul><ul><ul><li>Data transformation </li></ul></ul><ul><ul><li>Business logic / orchestration </li></ul></ul><ul><li>Integration projects evolve over time </li></ul><ul><li>Runtime needs to be managed </li></ul>
ESB = “Ant for integration/SOA” <ul><li>Important benefits: </li></ul><ul><ul><li>Many off the shelf components (some simple, some hard) </li></ul></ul><ul><ul><ul><li>Connectivity </li></ul></ul></ul><ul><ul><ul><li>Data transformation </li></ul></ul></ul><ul><ul><ul><li>Business logic / orchestration </li></ul></ul></ul><ul><ul><li>Extensible through plug-ins </li></ul></ul><ul><ul><li>Provides a higher level abstraction to wire components together </li></ul></ul><ul><ul><li>Few or no lines of code + configuration accomplishes a lot </li></ul></ul><ul><ul><li>IDE support </li></ul></ul><ul><li>Makes managing large numbers of sub-projects possible </li></ul>
Example <ul><li>Following an order from the ERP system </li></ul><ul><ul><li>ERP system creates a file with a batch of orders in CSV format </li></ul></ul><ul><ul><li>File needs to be picked up, read and converted to a canonical format </li></ul></ul><ul><ul><li>The CSV file does not contain all information necessary for the canonical format so it needs to be enriched </li></ul></ul><ul><ul><li>All orders in the CSV file need to be approved by an approval system </li></ul></ul><ul><ul><li>Each order needs to be sent out to the Internet Gateway (TDN) in EDI format, or to a Fax gateway in PS format </li></ul></ul><ul><ul><li>A financial monitoring application needs to get a copy of the order </li></ul></ul><ul><ul><li>An email needs to be sent to the submitter of the order when the order goes out </li></ul></ul><ul><ul><li>The department that generally takes delivery of shipments needs to be notified of the order </li></ul></ul>ERP system po.csv po.xml read convert Approval system Monitoring system Email Notify po.xml po.txt convert TDN system po.edi convert
ERP system po.csv po.xml Approval system Monitoring system Reserve .xml ERP approval T Finance po.xml TDN system po.edi TDN Fax system po.ps Fax Email po.txt Email Solution in parts po.xml po.xml po.xml po.xml EAI applications or infrastructure Existing systems Messages Web procurement order .xml Web Q T
Components: connectivity <ul><li>Typically for an ESB: </li></ul><ul><ul><ul><li>HTTP, File, FTP, JMS, Email, Scheduler, database </li></ul></ul></ul><ul><li>OpenESB also has: </li></ul><ul><ul><ul><li>ETL, Data Mashup, MDM, Asterisk, Exec BC, HL7, LDAP BC, RSS BC, SIP BC, SNMP BC, TCPIP BC, UDDI BC, XMPP BC, CICS BC, CORBA BC, DCOM BC, EJB BC, IMS BC, MSMQ BC, MQSeries BC, ScreenScraping SE, SWIFT BC, SAP BC </li></ul></ul></ul>
Components: data transformation <ul><li>Typical for an ESB: </li></ul><ul><ul><ul><li>XSLT SE </li></ul></ul></ul><ul><li>OpenESB also has: </li></ul><ul><ul><ul><li>Encoding SE </li></ul></ul></ul><ul><ul><ul><li>Visual mapping in BPEL editor </li></ul></ul></ul><ul><ul><ul><li>Java based mapping (test/sample driven) </li></ul></ul></ul>
Components: business logic / orchestration <ul><li>ESB typically has: </li></ul><ul><ul><ul><li>Java? </li></ul></ul></ul><ul><li>Open ESB also has: </li></ul><ul><ul><ul><li>BPEL SE: Long running transactions, Asynchronous interactions (correlation), Persistence, clustering </li></ul></ul></ul><ul><ul><ul><li>IEPSE: Complex Event Processing / Event Driven Architectures </li></ul></ul></ul><ul><ul><ul><li>EE SE: Makes EJBs accessible from within JBI </li></ul></ul></ul><ul><ul><ul><li>POJO SE: Use simple Java classes for business logic </li></ul></ul></ul><ul><ul><ul><li>Scripting SE: Use scripts for business logic </li></ul></ul></ul><ul><ul><ul><li>WLM SE: human workflow </li></ul></ul></ul><ul><ul><ul><li>Camel SE </li></ul></ul></ul>
Example: BPEL SE <ul><li>BPEL: highly expressive language for </li></ul><ul><ul><li>Orchestration </li></ul></ul><ul><ul><li>Asynchronous (correlation), concurrent interactions </li></ul></ul><ul><ul><li>Compensating transactions </li></ul></ul><ul><ul><li>etc. </li></ul></ul><ul><li>Strong IDE support for BPEL (graphically) </li></ul><ul><li>Reliability through database persistence (transparent to user) </li></ul><ul><li>Clustering support </li></ul>
Components: extensibility <ul><li>ESB typically provides </li></ul><ul><ul><li>Proprietary way to add custom components </li></ul></ul><ul><li>OpenESB provides </li></ul><ul><ul><li>Standards based components </li></ul></ul>
Wiring together components <ul><li>ESB typically provides: </li></ul><ul><ul><li>Higher level abstraction to express message flow / connectivity. </li></ul></ul><ul><ul><li>Typically XML file </li></ul></ul><ul><li>OpenESB also provides: </li></ul><ul><ul><li>IDE to graphically wire components together </li></ul></ul>
… leads to <ul><li>Less code </li></ul><ul><li>Faster development </li></ul><ul><li>Easier management </li></ul>
DEMO Approval System approval T po.xml T po.xml 1 2 3 4 file
Open standards <ul><li>Interoperability </li></ul><ul><ul><li>Allows connectivity with other ESBs / systems </li></ul></ul><ul><ul><li>Typical for ESB: done through bridge / bolted on </li></ul></ul><ul><ul><li>OpenESB: architecture is based on open standards </li></ul></ul><ul><li>Component standards </li></ul><ul><ul><li>Typical for ESB: components based on proprietary standards </li></ul></ul><ul><ul><li>OpenESB: JBI based </li></ul></ul>
OpenESB architecture <ul><li>Components interact typically within the same VM </li></ul><ul><ul><li>Homogeneous clustering </li></ul></ul><ul><ul><li>Propagation of transaction context, security context, etc </li></ul></ul><ul><li>Interactions with other nodes: </li></ul><ul><ul><li>Typically done through HTTP / standards </li></ul></ul><ul><ul><li>Also for heterogeneous clustering: proxy binding </li></ul></ul><ul><li>Component interactions described with WSDL: </li></ul><ul><ul><li>Describes message types </li></ul></ul>
Architecture <ul><li>Components are installed into runtime </li></ul><ul><li>Service units are deployed onto components </li></ul><ul><li>Service assembly </li></ul><ul><ul><li>contains service units </li></ul></ul><ul><ul><li>represents a composite application </li></ul></ul>
Open source: project OpenESB <ul><li>Started in 2005 </li></ul><ul><li>Led by Sun Microsystems </li></ul><ul><li>Many other partners and contributors: </li></ul><ul><ul><li>E.g. contributors from Advantech, Imola, ChainBuilder, eviware, Gestalt </li></ul></ul><ul><ul><li>Implementation partners </li></ul></ul><ul><li>A vibrant community </li></ul>
GlassFish ESB <ul><li>Large community = large number of components </li></ul><ul><ul><li>Humongous installer </li></ul></ul><ul><ul><li>Problems with synchronizing release dates </li></ul></ul><ul><ul><li>Components in different stages of development </li></ul></ul><ul><li>Solution: </li></ul><ul><ul><li>Smaller distribution (installer) called GlassFish ESB </li></ul></ul><ul><ul><li>Subset of components </li></ul></ul><ul><ul><ul><li>Most commonly used </li></ul></ul></ul><ul><ul><ul><li>Consistent quality </li></ul></ul></ul><ul><ul><ul><li>Same release cycle </li></ul></ul></ul><ul><li>Commercial support on GlassFish ESB is available from Sun Microsystems </li></ul>
What is next? GlassFish ESB v3 <ul><li>Runs on GlassFish v3 </li></ul><ul><li>OSGi </li></ul><ul><li>Maven </li></ul><ul><li>Simplify user interface to service artifacts </li></ul><ul><li>Convention, Configuration, Code ... (In that order) </li></ul><ul><li>New way of specifying interactions between components: Integration Flow Language </li></ul><ul><li>Editable text </li></ul><ul><li>Browser based visual editor </li></ul><ul><li>Enterprise Integration Patterns out-of-the-box </li></ul><ul><li>Interceptors </li></ul><ul><li>New way of distribution over multiple machines </li></ul>