Mark Little

JBoss 2014

Posted by Mark Little Jun 14, 2014

Over a decade ago JBoss Inc was formed and back then the company was synonymous with J2EE and the JBoss Application Server. By 2006 and the Red Hat acquisition of JBoss we'd grown the projects to include Drools, jBPM, JBossESB, JBoss Portal and many others, but the predominate association of the term JBoss remained with Java Enterprise Edition and the application server. Over the last 8 years, however, Red Hat has grown the JBoss pantheon of projects and products significantly, so now it includes MRG-M, Data Virtualisation (through the acquisition of MetaMatrix), Fuse including A-MQ (through the acquisition of FuseSource and the associated projects), BPM (through the acquisition of Polymita and the work of our homegrown Drools and jBPM teams), BRMS (great vision and work by the expanded Drools team), mobile (with AeroGear, HTML5 and Objective-C), and other non-Java language support including JRuby, Clojure and Ceylon (putting Red Hat amongst the likes of Google and Apple pushing the frontiers of language development). Today in 2014, more than a decade since the term JBoss was first coined, it means so much more than Java let alone Java Enterprise Edition. Who knows what more it will mean in another decade?! Onward!

Mark Little

JUDCon Boston 2014!

Posted by Mark Little Jun 2, 2014

It doesn't seem like nearly 6 months ago when I mentioned that instead of a JUDCon preceding Summit as we've done in the past we'd have DevNation. Since then we've been looking at when and how to organise the new JUDCon and it was getting tricky to fit it in amongst the various conferences and workshops that also dot our collective landscape. One thing that we've always prided ourselves on is that JUDCon is "By Developers For Developers" and it has its roots in various larger project face-to-face meetings where we'd invite the communities to attend, give input and maybe listen to presentations. We still have those larger project meetings but we tend not to run them in the same way - not because we don't want to, but simply because JUDCon came along and made it easier to focus these kinds of things. So if we can't have a larger JUDCon at this time of year, why not go back to the original format? This is precisely what we've done this time around with JUDCon Boston 2014. It's a one day event being hosted just after the team meeting and with a focus this time on mobile, micro-presentations and a group hacking event not to be missed! If this is a success then I'd like to see us duplicate this if possible at many more such meetings around the world. If you're in or near Boston and want to come along, see the registration page!

 

Onward!

In the words of Rod Serling and the Twilight Zone: "Submitted for your approval". Consider a world where you're a developer and you've spec-ed out a large project you need to develop, either alone or with a group, and you know you need integration, a web server and definitely some enterprise capabilities such as reliability, transactions, security etc. And you'll be using good SOA practices throughout, of course! You sit down at your laptop, which doesn't have anything installed on it yet, and start to leaf through an online repository of software (app-store/service-store) that will help you achieve your goals. There's a core development environment (implemented on the JVM of course, though perhaps you want to use a combination of languages so maybe Java isn't your first choice) and for the sake or argument let's assume you're developing locally initially, so no Web-based IDE. Your initially selected packages download and off you go in a matter of minutes, with your friendly neighbourhood source code repository either created as part of this process or one you've got to hand already.

 

Now whilst it's nice to work alone at times, this project really requires more than one person and it's unlikely to ever be deployed on your laptop. So … to the cloud! All of the software components you need are either already deployed or deployed automatically as you migrate your requirements. As with the local (original) configuration, they're also integrated seamlessly with each other and with your IDE, so the only differences you might notice will be due to the interconnect between yourself and the cloud (though if you have redundant connectivity options then even this may be temporary and perhaps not even noticed by you). There are also core services deployed into the cloud, such as messaging (Messaging-as-a-Service), data (Database-as-a-Service), and others that you can use directly where necessary. As the team of developers continue to work, using their shared code repository and infrastructure, you may start to think about various non-functional aspects of the finished application which are critical when it comes to be deployed. These would include QoS requirements, such as average uptime, peak load requirements etc. All you have to do is define the QoS, clear in your understanding that the Cloud on which the application will be deployed knows how to distribute your application, non-functional components/services that you may not even be using yet but which are required to match your QoS, state etc. to any needed machines automatically and opaquely, i.e., without human intervention.

 

As the application development goes on you need more capabilities, such as cacheing or access to a large-scale in-memory data grid; you may even need to move up the stack and pull in requirements from different categories of users. For instance, your development team may create a range of services which can be used directly by users or composed together into other services to provide a composite capability/service. To do this it may be easier to think in terms of workflows or task flows; in fact the infrastructure on which you are developing may even pop up and suggest this to you (hopefully not as annoying as Clippy!) Further up the application stack the user may move from a developer who thinks in terms of code, interfaces, exceptions, messaging etc. and works with concepts such as choreography, orchestration, swim lanes. This is precisely where Business Process Management tools come into play and fortunately your Cloud has that service to offer on demand when you or others in the team need it; just select it and it is deployed into your development environment and automatically searches for the services you've created, making them available for further use.

 

Nearing completion of the application, you decide that whilst you want this application to run on the Cloud most of the time, you don't want to rely on a public Cloud entirely. Maybe you have some data that cannot be pushed to the public Cloud due to the sheer size of the data or for regulatory reasons (fortunately your development environment also has data virtualization techniques available which will allow you to partition the data for your application and also associate metadata with it such that the underlying Cloud knows where it can and cannot migrate the data to meet other QoS requirements). Maybe for peak periods you want to cloud burst to a private data centre (or vice versa). Whatever the reasons, you need to ensure that there's a similar infrastructure deployed on to these private machines (let's call it a private cloud for now) and tied into the public cloud. Again, a few clicks of the application repository (or administration menu) and everything is selected and downloads begin in the background, or even on demand, i.e., only encumber these machines when there's a need).

 

That's it. You step back and take a look at what the team have developed and how. In fact you can view all of this at various levels of granularity, from individual lines of code, to entire service interfaces and contracts, using the same toolchain you've been using. All of the interconnects between services that your team have created are shown up, and once it's running you'll be able to drill down onto specific machines, services and users to determine hotspots. gauge how well the application is running etc. All of this has been done by your team with no help from external service providers, IT teams or others not core to developing the application. Anything that has needed to be deployed, either to assist in the development or in the deployment has been triggered by your team and fulfilled by the Cloud infrastructure itself. Running the application requires very little (hopefully no) administration by you or the team, since the infrastructure is self-monitorig and adapts to changes in requirements, fault hotspots, patches itself when needed (maybe ignoring some patches that don't fix issues relevant to the application), …


Perhaps over the weeks and months that follow, your team or the client for whom you're working, buy more hardware (laptops, desktops, even IoT devices) that can be provisioned for us by the Cloud and this application: all you do is register them with the Cloud you're using and it downloads some basic infrastructure (fabric), perhaps add metadata to tell the Cloud when (time of day) these devices can be used or under what conditions (e.g., load is below 20%). Again, no programming/development is required: you "just" click-and-go! The development infrastructure may even be able to predict what you need before you do and install components so they are there when needed. Not so unreasonable given techniques such as Bayesian Inference Networks, or the fact that an algorithm is now a company board member!


Hopefully this doesn't sound too far fetched. And hopefully it sounds like something which makes sense to you, because this is the kind of thing we're trying to accomplish with xPaaS. Some of this isn't too far from what we demonstrated earlier this year. And whilst there's still some way to go before we have all of this, we're making great progress with efforts like Fabric8. However, a lot of the work we need to do is presentation related: how we make available these technologies so it really is a lot more point and click and a lot less writing of much code. Don't get me wrong: I've never been a believer in "zero coding" development tools aimed at programmers, but for certain categories of developer it's possible to get close (but no closer).


Adding in capabilities to your development (and deployment) environment as you need them is something we've become used to over the years with the likes of maven, but what I've mentioned above goes much further. It needs to be as natural and opaque as selecting an app on a tablet or mobile phone; any dependencies (such as other apps) are downloaded automatically. As you download capabilities (augment your environment) so too will they be downloaded to your co-workers on the same project - perhaps there'd be the notion of groups for developers so only if you're in a specific group(s) do you receive this auto-update when your colleagues in the same group realise they need some new capability. And like I said several years ago, how this happens under the covers is not necessarily something that is exposed to the users (the opaque references I keep making), but could be based upon dynamically updating containers with capabilities as and when they're required.


Finally another key component to this Utopian Future is the typical cloud billing mechanism: pay for what you need when you need it. The developers don't have to buy development licences or support ad infinitum but only for the duration of the development process (though some are obviously needed for support and maintenance later). The customer needs buy deployment/runtime licences or support for the duration of the application's lifetime, which could be measured in months or years, but which typically still only get billed per minute of execution. So if the application gets shut down for specific periods of the week or year, there's no need to pay for them.


Maybe this all seems far fetched. Maybe it's obvious to you. After all we and others have been talking about things like this for a while. We're continuing to head in these directions with xPaaS, Fabric8, WildFly, OpenShift and a large range of other efforts. Working with upstream communities, partners and customers this is an exciting time!

Mark Little

Future Middleware ...

Posted by Mark Little Apr 27, 2014

I finally wrote up some things that have been bouncing around in my head, various email conversations and touched on in a few presentations. I've cross-posted here in case anyone's interested.

Mark Little

Reactive Streams

Posted by Mark Little Apr 17, 2014

Norman has written up an excellent piece about the new Reactive Streams effort with which he's been involved. Take a look and provide feedback as well as watching what we do in this are.

Hopefully it's obvious, but everything these days really has to be open. Open standards, such as those activities within the W3C or OASIS, and open source. Vendor lock-in needs to be a thing of the past and open source empowers people to ensure that is the case! Why does open source matter? Open source is at the heart of many of the technological advances over the past decade. Whether it's cloud with Linux, JBoss with Java EE, or Android for mobile, you don't have to look far to see open source footprints. The success of these waves and others is due to the communities that naturally build up around open source, the rapid feedback that users and developers can provide to those projects and, of course, the fact that it's easier to tailor the technologies to the problems at hand.

 

So what does the platform for the second decade of the 21st Century look like, apart from being open source? It has to be lightweight with a minimal footprint, built for cloud - not the limited definition of it we have today with just servers, but the more natural and future version which includes IoT. It also needs to be dynamic, adaptable, autonomous, self-healing … in some ways similar to a living  organism. From a JBoss perspective technologies such as Fuse Fabric8 provide some of these capabilities today. And of course data management (virtualisation) is at the heart of the platform: being able to store and represent data in a range of ways, not just relational, and at such hugh scales, is a necessity.

 

This is really about modernising the application development platform, turning the development experience from what was needed at the turn of the 21st century to something that will define the next decade and beyond. I've outlined what this new platform needs to do in terms of functionality, but how will it happen? Or let me rephrase: how are we delivering this platform today so that it can be used by a wider range or people to develop an even wider range of applications?

 

Well for a start SOA is at the heart of this. Whether it's due to integration of disparate services across the clouds and clients, or what some people are calling Micro Services (which is really just SOA so don't be fooled) we're building on Fuse technologies such as Camel, A-MQ and of course Fuse Service Works, including Switchyard and S-RAMP. Back in the early cloud days we'd talk about the Internet Service Bus as a cloud version of the ESB, but these days there really shouldn't be a distinction. The SOA infrastructure, of which ESB is just a part, must be cloud enabled and mobile enabled and IoT enabled (you get the point) from the start. And of course where SOA and services are concerned you need a way of tying them together into business activities or tasks. The act of doing that immediately propels us into a different group of people: we're no longer talking about service developers but business analysts and that requires a very different approach, with very different tools. Fortunately jBPM, Drools and our acquisition of Polymita over a year ago have enabled us to create the new BPM Suite which targets business analysts.

 

Now we could obviously deploy these services and others into the cloud as individual components. But that fails to see that there are so many common requirements that they share, so many groups of developers or analysts will want to use more than one at the same time, that to not pull them together into a single platform is inefficient to say the least. This common platform is what we call xPaaS and it's definitely an example of where the whole is much more than the sum of the individual parts! Our xPaaS implementation is evolving even as I type, but today it consists of OpenShift and many key JBoss technologies such as:

 

- Application Container Services  Based on Red Hat JBoss Enterprise Application Platform, the application container service delivers aPaaS capabilities that enable developers to build and deploy complex enterprise applications in the cloud.

 

- Integration Services (currently in developer preview) – Based on Red Hat JBoss Fuse and Red Hat JBoss Data Virtualization,  Red Hat’s integration services allow developers to create connections to, in, and with cloud and on-premise applications and data.

 

- Business Process Services (currently in developer preview) – Based on Red Hat JBoss BPM Suite, the business process services are designed to enable business users to build, run, integrate, and manage business process applications that automate workflows and business processes within and across organisations.

 

- Mobile Services – Based on the AeroGear project, mobile services simplify and streamline support for numerous mobile client types while extending applications to those devices through capabilities such as push notifications.

 

And we’ll be releasing more components into xPaaS over the coming weeks and months! If you want an enterprise level Platform-as-a-Service then xPaaS from Red Hat/JBoss is the only implementation that matches the needs of developers today and will continue to evolve as those needs evolve.

 

What I've mentioned so far is here today. But what about the future? I've already mentioned that the platform we need today is very different from those which we've used in the past, but this is a never ending evolution. For instance, whilst EAP is core to everything we do today and so is Java EE, we're already seeing people develop serious applications with new frameworks such as node.js or Vert.x. For several years we've been talking about JBoss Everywhere and this continues today with our view to these new reactive platforms: we will be ensuring that where these frameworks need transactions, security, caching, replication etc. then we'll use those that we've got rather than reinventing the wheel. And it'll be polyglot too.

Red Hat has strong links for a number of academic institutions around the world. However, certainly within JBoss our strongest links are with Newcastle University, where we work closely with the students, teaching staff and researchers. It's no surprise that many of the JBoss team in our local office have come from there. Therefore, I'm very pleased to hear that the University has received one of only a handful of Centres for Doctoral Training (CDT). We've worked closely with the University on their proposal, which is around Big Data and Analytics, combining the practical elements of a traditional Computer Science PhD with the more theoretical/formal methods from statistical analysis. Congratulations to all of those involved in putting together the submission and getting it approved. And I look forward to the research that is done over the next years and working closely with the University team.

Mark Little

Summit, DevNation and IoT

Posted by Mark Little Mar 23, 2014

It's been a while since I've had a chance to sit back and put some of my thoughts to (e)paper. I don't know quite what it is but for the past few months (even before 2014 began) I've been snowed under with this or that. I know some of this is down to our (Red Hat/JBoss) success meaning that I'm being pulled in many different directions so it's definitely a good thing in that regard. But it's past time for me to make more time and at least write about some of the things we're planning for Summit/DevNation this year. Now of course I won't go into much detail or I'll spoil the surprises, but here's a taster:

 

  • Summit Keynote: once again JBoss will be kicking off the keynotes at Summit and once again we'll be running a demo with a large amount of audience participation. Prizes will also be available but you'll have to wait until the keynote to find out what and how they can be received. It never fails to surprise me how much effort goes into the keynote, with the demo taking up a lot of time and effort from some of our key engineers. All I can say is that there'll be an IoT theme to this!
  • Summit session: I'm presentation and moderating a session on the future of enterprise middleware. This should be a very participatory session so come along and hear what we think but also make sure we hear what you think!
  • DevNation BOF: Scott Stark and I (mainly Scott!) will be working with ARM presenters to talk about JBoss, IoT, CoAP etc. and then have attendees try out some of these cool ideas. Come along!
  • DevNation: there's a hacknight on the Wednesday evening with a number of things going on. One of them is an IoT themed event with ARM, and we'll also be trying to do some cool things with Raspberry Pis. We may even be giving away some of these devices on the night!
  • Fuse@DevNation: we've got a few very special activities going on at the start of DevNation if you're interested in Fuse related projects and products!
  • DevNation Party: 'Nuff said! Be there and if you find me maybe I'll buy you a drink or have a few surprise give-aways!

 

That's about it for now. Summit and DevNation will be very busy whether you're a presenter or an attendee. I hope to find time to put more thoughts to (e)paper soon on what we're doing in a number of areas, such as IoT, messaging etc.

Back in September last year I announced that we were working on xPaaS (enterprise services in the Cloud and specifically OpenShift). xPaaS is a long term effort that will evolve as our products evolve and we put them into the Cloud. However, it's with great pleasure that I can announce we've started the xPaaS releases with iPaaS (Integration-as-a-Service):

 

Screen Shot 2014-03-08 at 10.13.54.png

You can find out much more about iPaaS by checking out the home page and taking it for a test drive - give us feedback too! As Arun mentions separately, there will also be some relevant sessions at this year's DevNation. And we should be announcing further updates to the xPaaS effort in the coming months, so keep watching.

I've written a couple of blog entries on my personal blog which are related and which people may find interesting. The first is on some work I was doing over Christmas with CapeDwarf running on Raspberry Pis, with the aim to turn them into a private cloud. The second is about the adoption of hybrid cloud, but also repeats what I've been saying for several years that devices such as the Pi (or smaller) need to become part of the cloud. I'm hoping to say more about this at Summit later this year and maybe we'll have some demos to illustrate.

We've seen a couple of announcements already around DevNation and I just wanted to add my own take to this because I've been asked "Where's JUDCon or CamelOne?" The simple answer is that they haven't gone away, but at least as far as Summit is concerned they've been subsumed within DevNation. The reason for this is pretty simple too: when I kicked off JUDCon with the team back in 2010 it was the precursor event to JBossWorld/Summit and the only developer conference we held at that point. Over time we've added OpenShift and other developer conferences with non-JBoss focus and then of course last year we added CamelOne. Each of these conferences have their own identities but when gathered together at the same time and location it can cause confusion, not just in terms of questions like "If I register for JUDCon can I go to CamelOne?" but also in terms of presentations, which often span multiple developer communities and hence these individual conferences, resulting in questions like "Why was that presentation at JUDCon when it clearly should have been at CamelOne?"

 

Therefore, whilst the likes of JUDCon will continue to exist in isolation (you are going to JUDCon India, right?) and we've restarted the Fuse Days, when gathered together at Summit we'll have just DevNation. The content of this one event will be just as eclectic, the communities just as vibrant and the entertainment just as good, but now it should be a lot easier to understand just what you get for your registration and what you can expect. Of course I'm sure (I hope) there will still be issues with being able to see all of the sessions you want to see because some conflict, but I think that's the sign of a good conference/workshop.

 

Onward to DevNation!

Mark Little

Lyon JUG report

Posted by Mark Little Nov 29, 2013

I got the opportunity recently to go to Lyon (haven't been there in about 2 decades!) and present at INSA/CITI as well as give a session at the local JUG. Before I set off I was asked a few questions so that they could post an interview with me. If you're interested, then the interview is here.

 

I'm hoping that CITI and the Lyon JUG will eventually post the presentations I gave as they're a little bit too big to attach here. However, here's the first slide from my presentation at CITI:

 

Screen Shot 2013-11-29 at 13.25.51.png

And here's the equivalent from my JUG presentation:

 

Screen Shot 2013-11-29 at 13.28.01.png

Fortunately in this and age of social networking, I didn't have to worry about taking pictures of the event: others did that for me and I include them here along with my gratitude:

 

Screen Shot 2013-11-29 at 13.23.37.pngScreen Shot 2013-11-29 at 13.23.46.png

For those people who weren't there and want to see the last slide in more detail, here it is:

 

Screen Shot 2013-11-29 at 13.30.00.png

 

I want to thank everyone who attended both presentations and gave me some good questions to answer and things to think about on my journey home. I also want to thank Julien Ponge and Alexis Hassler for inviting me and arranging everything. I do want to do it again!

Mark Little

Sun-setting again

Posted by Mark Little Nov 6, 2013

Back in 2009 I wrote about how it was sad in some ways that Sun had been acquired by Oracle. 4 years later, we now hear that GlassFish is being relegated to the domain of the Reference Implementation. Once again I have mixed feelings about this event. Despite GlassFish being seen as a competitor to our own offerings, there was always a grudging respect for what that team had done, and several of them now work for Red Hat, often as a direct result of those efforts. So in that regard it is sad to see it go. However, what worries me the most about this turn of events isn't so much about the technology, but rather what signals this could send to their open source communities. I will leave that mainly as an exercise to the reader, but it doesn't really take a massive leap to be concerned if you are a member of those communities. Now I'm not going to suggest that Red Hat's projects such as WildFly, or any other open source vendor, are necessarily a better home for those community members who feel that it is time to move on, but I would hope that they would at least take a look and judge us on our track record.

I'm on holiday at the moment but some things are so important that they draw me back temporarily. Red Hat and JBoss before it, has been an active member of the JCP Executive Committee for many years. We've worked with Sun, Oracle, IBM, HP, JUGs and many others to try to ensure that Java the language and Java EE the platform, are open and fully participatory by those who really make our collective thriving ecosystem work. It hasn't always been easy but we're glad to be involved. Whether it's helping to open up the JCP processes, injecting more open source practices, leading JSRs or participating in them, we try to be involved in all aspects of the Java community and standards. This is why being on the JCP Executive Committee is important for Red Hat: we believe that the best way to influence things is from within and being on the Executive Committee gives us that ability.

 

But an even more important aspect of being on the JCP EC is that everyone gets voted on (or off). As with any election, this is a great way of getting feedback on how well people view you and your approaches. We've been elected on to the EC every time our seat has been up for election, but that does not mean that we take it for granted: far from it in fact! And this time is no different. The elections kicked off recently and myself and Scott Stark represented Red Hat. The results have just been reported and I'm really pleased and proud to report that we've been elected for another two years. As you can see from the results, we got a lot of votes and it pleases me that so many people believe we are doing a good job. I want to thank everyone who voted, whether or not they voted for us (voting is important!); we will ensure that your vote counts.

I wrote an article on InfoQ recently about IoT. This was based upon a presentation I saw whilst at the JCP EC meeting in September from ARM. I found it fascinating, especially given the work we've been doing on things like Raspberry Pis. It was also interesting to hear how important ARM and others see Java in this space. So if you haven't read the article then take a look.

Filter Blog

By date:
By tag: