JBoss Community

RESTEasy 1.1 Released

Posted on 2009-06-17 21:02:43.0 by Bill Burke [ View original post ]

I'm pleased to announce the release of RESTEasy 1.1.GA. This was a huge functionality and bug fix release for us. Special thanks goes out to Solomon Duskis, Attila Kiraly, and Michael Brackx. Included in this release is:

• New interceptor model
• GZIP encoding support
• Guice 1.0 support. Thanks Mike!
• XOP and multipart/related support. Thanks Attila!
• Internal dispatching and forwarding support. Thanks Solomon!
• Jackson JSON provider support.
• Asynchronous Job Service
• Client and Server side caching capabilities
• Decorator framework for JAXB
• XMl header and stylesheet support for JAXB
• Greatly improved multipart support thanks to Attila.

For more information follow the links at RESTEasy's Project Page.

Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---

We Welcome our Friends at Hewlett Packard to our SOA Solutions Community

Posted on 2009-06-17 15:21:33.0 by Pierre Fricke [ View original post ]

Today we announced that Red Hat and HP are collaborating on an integrated SOA development, execution and integration, and management environment featuring JBoss Enterprise SOA Platform and HP SOA Systinet. This week, we are with HP at HP Software Universe demonstrating and discussing our solution with customers, partners and others. We are excited to have HP join us on the journey to make enterprise SOA more simple, open and affordable, expanding opportunities for business to be more agile at all levels in the value chain.
Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---

Don't put lipstick on a pig that can't fly

Posted on 2009-06-15 09:45:34.0 by Mark Little [ View original post ]

For as long as I can recall I've always liked good tools and been infuriated with those that get in the way of me being "creative" or working "efficiently". (Subjective terms, I know.) Whether it was the MetaComCo C/Pascal compiler tools for my Atari those many years back (great customization capabilities) or plain emacs (yes, it's a tool!) I've admired those groups who can make good tools. Over the years I've met many tooling groups from HP, Bluestone, BEA, Microsoft and of course JBoss/Red Hat. Some of the more successful groups have been staffed by a combination of good engineers but also people who have good HCI skills (including psychology backgrounds). But they've all usually had the same comments to make about how tooling is seen by developers: under appreciated and an afterthought. That's a shame because as far as I'm concerned a good tooling experience can bring a better ROI than adding some super cool feature here or there.

I think the key to good tooling is having the involvement of the developers on the product for which tooling is being developed as early as possible. Where I've seen this work well is when there's actually a tooling person sitting in that team full time, learning about the requirements and acting as a conduit to impart that knowledge to the rest of the tooling team. To do it otherwise can often take longer (inefficient?) and may result in something that isn't quite what is required. Despite the fact that they're all engineers, there is often an impedance mismatch between tooling engineers and project engineers; almost a language barrier. But for good tooling to work well, the conversations need to be bi-directional. This is another reason why the approach of having a tooling person sitting in the project works well, as it provides immediacy of responses.

Max, our tooling lead, is keen to say that good tools shouldn't be used to cover up poor underlying projects. He's right! I've seen that happen a lot across the industry, where the tools look fantastic but there's very little under the covers, or what is there is horribly baroque and hard to understand. Designing for tooling from the outset should be considered in the same way as designing for robustness or performance or security. It's not something that is easy to retro-fit.

Good tools (and yes, I count JBDS in that list) also grow with you. Too often I've seen tools that are either way too complex to use for beginners or are so basic as to encourage you to grow out of them pretty quickly and look for something else. (There's a reason I've been using shell and emacs for 20 years.) And of course in this world of ever changing runtimes, you really want a tool suite (or IDE in this case) that can work with more than one at a time: I hate having to fire up different IDEs for different versions of the same product, especially when there may only be a few months age difference between the runtime versions.

Fortunately we have some great people here who are passionate about tooling and understand its importance in making the whole product experience work well. That doesn't mean we've got to that nirvana just yet, but we are on the right path. We need to work more closely with the projects and vice versa in order to push this mantra of thinking about tooling through all phases of the project lifecycle and not just after the fact. The improvements we've made over the past couple of years are pretty significant and there's much more to come. I'm excited and maybe this will finally encourage me to move away from emacs ;-)

BTW, thanks to Max for the title of this entry!

Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---

The JBoss Microcontainer: Flexibility and Future Proofing

Posted on 2009-06-01 17:50:54.0 by Mark Little [ View original post ]

You've probably all seen or heard of Transformers ("Transformers ... robots in disguise.") The gist is that these robot are flexible enough to be reconfigured into a variety of different forms depending upon the need at hand. Pretty important if you need to battle enemies from the stars and then make your way silently through the streets disguised as a Bugatti Veyron. But what, you ask, has this to do with JBoss? Well we've been working on our own adaptable infrastructure for a few years; not so we can fight Decepticons, but so that we can offer a way for the same software components to be used in a variety of different environments without requiring major rewrites, different implementations, recompilations or several months of on-site consultants. We also want to support a range of different frameworks or component models, such as SCA, Ruby and OSGi.

So how have we been able to accomplish this? With the JBoss Microcontainer. It's been in development for several years as well as being an evolution from the original JMX Micro-kernel. The basic concept is pretty simple: you can define your core services/components and their interdependencies no matter what their flavour (e.g., POJOs, MBeans) dynamically and potentially on-the-fly. What was a full-featured JEE Application Server one minute could be a scaled down embedded ESB the next. What was a basic Web server yesterday could seamlessly acquire transactions and security tomorrow.

The aim here is clear though: to allow existing investments in components that have proven their maturity over the years to be used in both lightweight and heavyweight environments. Other approaches to solving this problem typically revolve around completely different technology stacks, requiring different expertise, learning curves, support contracts etc. And that kind of solution does not evolve with your changing requirements (at least not without going back to the vendor to arrange delivery of the new product, learning it, training etc.)

But what about other deployment models, such as OSGi and Spring? Although JBoss is popular there are people who need to use these alternative frameworks/component models. In the past they meant embracing that entire framework for everything in the assumption that the choice you make today is the right choice for tomorrow. Unfortunately frameworks come and go, as well as requirements changing. So an investment in something today is not necessarily the right approach for the future. But in that case what do you do when you're left with an OSGi bundle and you don't want to stay with OSGi, for example? Well fortunately the JBoss Microcontainer offers a possible solution there too. supporting a flexible state machine model of components we can support native component model deployments as well as foreign component models on the same codebase and track dependencies across those component models.

The architecture of the Microcontainer has evolved over the past few years, so even if you looked at it a while ago it's worth looking again. For example, we've added increased flexibility to the deployment model such that we now support an AOP-like manipulation of a metadata pipeline down to the final component deployer. There's also a Virtual File System for deployments, which is a major improvement over the past. Finally it's now possible to declare that any implementors of an interface should be "injected/un-injected" via specified methods, which allows for containers to specify plugin interfaces and easily have plugin implementors associated with the container as the plugins are instantiated. These examples and others just go to prove how much thought and effort has gone into this new architecture in order for us to be able to deliver on the promise of flexibility and adaptability for user requirements now and in the future. We spent a lot of time doing this so that we could do it right once and for all time: the future is bright for JBoss and its users, because we know now that we don't have to worry about re-architecting again in a years time when another deployment environment comes along, or some subtle differences in needs force a rethink of "fat" versus "thin" deployments or "rich" versus "poor". You can safely deploy to the new Microcontainer in the knowledge that it's future-proofing you.

As an industry one thing that we often fail to remember is that standards come and go, but core requirements remain. If you look at the evolution of distributed systems over the past 4 decades, for example, you'll see the transition through DCE, CORBA, JEE, Web Services etc. These all define their own component model(s), APIs, development methodologies etc. Yet at the heart of them all critical services such as transactions, messaging, security etc. remain the same. The only thing that changes is the way in which they are wrapped into the infrastructure. Well that's something we've tried to embrace with the new Microcontainer: leveraging our tried and tested components and providing a way to use them in environments/standards past, present and future.

Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---

Red Hat Launches Business Rules Management System to Drive Enterprise Competitive Advantage in Turbulent Business Climate

Posted on 2009-05-19 08:41:03.0 by Pierre Fricke [ View original post ]

JBoss Enterprise BRMS Enables Rapid Response to Change

Faced with economic, business and regulatory turbulence, enterprises around the world need to respond to change, opportunities and threats more rapidly than ever before. Businesses that can respond to new regulations, customer trends, opportunities and threats by updating the IT deployments with new / modified business rules will have a competitive advantage. To date, business rules management systems (BRMS) have been complex, closed and expensive. Red Hat believes there is a better way to improve business execution and responsiveness while carving out costs. Today, we introduce the JBoss Enterprise BRMS.

JBoss Enterprise BRMS provides an open source business rules management system that enables easy business policy and rules development, access, and change management. JBoss Enterprise BRMS includes a fast and highly efficient rule engine and easy to use rules development, management system and repository. JBoss Enterprise BRMS allows businesses to reduce development time to update applications, SOA deployments and business processes with the latest business rules and policies. The ability to respond to change in hours or days updating a BRMS vs. weeks or months updating business rules scattered in stove-piped enterprise and web applications can mean the difference between prosperity and bankruptcy. The JBoss Enterprise BRMS subscription along with other JBoss Enterprise Middleware such as our SOA Platform enable this value within solid IT governance methodologies for some situations such as price changes or simpler parameter changes on policy or product configurations. Even with more complex changes such as a new regulatory regime, the enterprise can respond faster with JBoss Enterprise BRMS.

Examples where JBoss Enterprise BRMS may add significant value to an enterprise or government agency include:

• Resource Allocation and Prioritization
• Product Configuration - Handles complex product feature interdependencies
• Pricing and Electronic Trading - Applying algorithms to live pricing information
• Insurance - Assessing the premium level for new and changed customers
• Network Security and Monitoring - Intelligent assessment of traffic for malicious intent; smart alerts and control actions
• Authorization – e.g., Determining user permissions
• Control Systems – e.g., Air conditioning, heating
• Healthcare – Assessing drug interactions; prescription assistance Government – Evaluating and approving benefits such as social security, unemployment, and welfare; fraud detection

For example, suppose an upsell opportunity arose, with demand so high that a price increase is also in order. Also, let's assume that $100,000 of increased business per day is likely when the new product offering is available. With product configuration and pricing rules in JBoss Enterprise BRMS , this business may be able to reconfigure IT to offer the new upsell product and product pricing in 5 days, making the change available to all channels simultaneously. Without JBoss Enterprise BRMS, this new offering could require changing and redeploying 3 web applications and a product configuration application written in Java which may take 25 days. With JBoss Enterprise BRMS , the web applications are still part of the deployment, but now call upon the BRMS to execute business rules. The enterprise with JBoss Enterprise BRMS has gained $2,000,000 in increased revenue. Even if the old style application deployment enterprise made the change manually by faxing new price sheets to various channels, it still could take several days and then present several consistency, customer satisfaction, delivery and other issues.

We invite you to explore JBoss Enterprise BRMS and see how it may help improve your business.

We also invite you to take the JBoss SOA Assessment which will help you understand where you are in adopting SOA and what next steps may further your journey to a more flexible and agile IT infrastructure that is responsive to change. JBoss Enterprise Middleware and Red Hat Consulting can smooth the path and accelerate the journey...learn more in the JBoss SOA Resource Center .

Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---

CloudCamp 2009

Posted on 2009-03-12 10:34:07.0 by Mark Little [ View original post ]

We are co-sponsoring CloudCamp this year. Come along to the Newcastle or Edinburgh events if you get a chance.

Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---

WS-Eventing standardization

Posted on 2009-03-11 07:46:24.0 by Mark Little [ View original post ]

Sometimes standards evolution can read a bit like a religious work! For example: in the beginning there was the word and the word was "events". Some of the Web Services architects looked at the word and came up with WS-Events. The rest of the Web Services world looked on that specification and found it wanting so begat WS-Notification. But this wasn't enough for some and they begat WS-Eventing. As with so many of the standardization efforts in those prehistoric days (WS-CAF vs WS-TX, WS-Reliability vs WS-Reliable Messaging etc.), this lead to confusion for the people, especially as none of these approaches were standards initially.

Fortunately WS-Notification eventually went to OASIS and became a standard, but it lacked the support of all major vendors. A modified version of WS-Eventing became a W3C Note around the same time but this is significantly less than a standards stamp of approval, though it did have some of the author companies from the other specifications involved. Yet more confusion abounded! Event notification ranks up there with security, transactions and messaging as core to most distributed system technologies over the past 4 decades. So it was no surprise that it would eventually come to pass that events would find their way into Web Services. Unfortunately because there is no single standards body for all Web Services work, that tends to lead to competing specifications (and standards). It's getting a lot better these days than it was back in the early 2000's, but it's still not perfect.

In an effort to solve the confusion around events all of the main protagonists (ourselves included) got together last year to form the Web Services Resource Access (WS-RA) technical committee within W3C. Part of that effort will standardize WS-Eventing. The timescale is fairly aggressive, with final standards due in June 2010 (which will include interoperability efforts).

But what do you do in the meantime? Events are important. Some vendors have implementations of one or more of these specifications/standards. What does that mean now that WS-RA is changing things? Well it definitely means that if you're already using a product based on one of the existing documents you will have to change something: backward compatibility is not a key aspect of the WS-RA effort. Of course change for change's sake won't happen, but some changes are inevitable (e.g., because the specs were broken or experience has shown a better approach). I'm sure some vendors will try to provide means to allow their existing products to continue to work with the next generation, but it is likely that changes will be driven right up to the developer. So be warned.

In terms of our own WS-Eventing offering, it's based on the older documents and is a community-only release. We're going to be working on providing a version based on the evolving standard and may have early access releases before the standard comes out (being on the committee helps!) So feel free to use what we've got for now in the community and watch the forums as we begin to work on the next generation.

Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---

RESTEasy 1.0 GA Released!

Posted on 2009-01-20 17:37:06.0 by Bill Burke [ View original post ]

I am pleased to announce the first GA release of JBoss RESTEasy. All documentation and download links are available at RESTEasy's JBoss.org project page.

JBoss RESTEasy is a framework that allows you to write RESTFul Web Services in Java. It is a fully certified and portable implementation of JAX-RS specification. JAX-RS is a new JCP specification that provides a Java API for RESTful Web Services over the HTTP protocol.

RESTEasy can run in any Servlet container, but tighter integration with the JBoss Application Server is also available to make the user experience nicer in that environment. While JAX-RS is only a server-side specification, RESTEasy has innovated to bring JAX-RS to the client through the RESTEasy JAX-RS Client Framework. This client-side framework allows you to map outgoing HTTP requests to remote servers using JAX-RS annotations and interface proxies.

Features

• Fully certified JAX-RS implementation
• Portable to any app-server/Tomcat that runs on JDK 5 or higher
• Embeddedable server implementation for junit testing
• Rich set of providers for: XML, JSON, YAML, Fastinfoset, Atom, etc.
• JAXB marshalling into XML, JSON, Fastinfoset, and Atom as well as wrappers for arrays, lists, and sets of JAXB Objects.
• Asynchronous HTTP (Comet) abstractions for JBoss Web, Tomcat 6, and Servlet 3.0
• EJB, Spring, and Spring MVC integration
• Client framework that leverages JAX-RS annotations so that you can write HTTP clients easily (JAX-RS only defines server bindings)

Special thanks goes to all our independent contributors, specifically: Solomon Duskis, Ryan McDonough, Olivier Brand, Martin Algesten, Michael Brackx, and Justin Edelson.

Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---

RESTEasy 1.0-RC1 Released: Need help finalizing GA!

Posted on 2009-01-06 19:25:29.0 by Bill Burke [ View original post ]

RESTEasy 1.0-RC1 has just been released. For more details click here!
Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---

Economic Depression and the Rise of Open Source SOA and Business Rules

Posted on 2009-01-06 17:13:58.0 by Pierre Fricke [ View original post ]

"Those who cannot remember the past are condemned to repeat it." Life of Reason, Reason in Common Sense, Scribner's, 1905, page 284".

We know how the mania-bust cycle works. We have many examples in history. Seems like our "FIRE"-driven economy forgot it. FIRE=Financial, Insurance and Real Estate industries. In 1920s, it was stocks and too much debt. In the 2000s it's real estate and too much debt. It absolutely makes no sense to buy a house for a mortgage payment that is two times the rent cost! It's even more foolish to take a HELOC up to the manic value of a house to pay for consumer goods like cars, vacations and a lifestyle that otherwise one cannot afford. The industries that supported all of this activity expanded to a oversupply condition that must contract. So now we unwind...we may be halfway there; there being appropriately valued real estate that people can purchase with confidence...if the government let's the cycle play out without interference. If not, then we (the USA and EU) may follow in Japan's footsteps and it will take a while.

Nevertheless, it's not the end of the world, just the end of an era. In economic depressions and deflations, business activity continues. It just doesn't continue at the previous pace. However, there are still growth opportunities. We can look at the 1930s for instruction. We know auction houses, bars, home entertainment, repo businesses, bankruptcy and divorce lawyers will have a lot of business. But also the government will expand. Regulation and the implementation of regulation will expand. Industries will be transformed (finance, insurance, government, energy, real estate, manufacturing, health care, education, etc...).

In the 1930s, emerging high technology in the form of tabulator machines and improved telephonic services continued to grow. IBM led the charge and had growth every year in the 1930s with expanded opportunities for tabulators to support the new regulatory environment and to help industries become more productive and reduce costs. New Deal government programs drove a lot of demand and the companies that were looking ahead also took advantage of the new technology to improve their businesses. Remember, 75% of the people were still employed and even with pay cuts, many were coming out ahead due to deflation (as long as they had little debt!). They saved a lot more and spent less, but business was still transacted and those businesses positioned to serve the government and remaining consumer demand with new products, services that solved problems did OK to well.

Today, we will see the same thing. Not everyone will go out of business and whether we see 8%, 12% or 18% unemployment, business activity will continue. Certainly the government will expand...trillions of $ are being lined up. The FIRE industries will need to be re-invented to operate in a much different regulatory environment. Existing IT assets, configured as they are, will become obsolete. They can be reused, but need to be augmented and reintegrated to operate in the "New New Deal".

Today's business productivity and transformation tools will include further transition to an SOA-enabled environment. Since there likely will be several waves of regulation and increased change in the business environment, enterprises that set themselves and their value chain to respond to change rapidly will win. Beyond re-integrating IT assets to operate in the "New New Deal", businesses will also need to pull their business rules out of scattered applications, consolidate them in business rules management systems and present them to the applications, people and business processes as SOA services. This will be required to be responsive to a rapidly changing environment.

But these enterprises and value chains will need to do this with reduced budgets, even with bailout money available! Local and state governments cannot print money and will have reduced tax revenues. They will not be able to afford the $50K / CPU closed source SOA platforms or $100K+ / CPU BRMSes that require a lot of capital expenditure up front. Fortunately, open source SOA and BRMS (Business Rules Management Systems) are maturing and offer a more simple, open and affordable way to weather these challenging economic and turbulent times. Indeed, business and government will need to serve picky customers with better service on reduced budgets and open source can help lead the way!

Maybe we will get lucky and this will only be a "serious recession" like 1980-82. Or this could look more like a modern version of the 1870s, 1890s or 1930s. Or 1990s-2000s Japan. Either way, Red Hat, with its high value, cost-effective open source subscriptions and services, stands ready to serve and help enterprises, value chains, and governments not only survive, but to prepare for prosperity again!

Post to DZone   Post to del.icio.us   Digg this!   Stumble It!

---