JBoss EAP 6 BETA Q&A

Here follows answers to the the majority of the questions we had during the BETA webinars last week. I’ll add the remaining answers in he next few days. There were lots of questions so I’ve grouped them into categories – if you have additional questions or require more clarity, please leave a comment.

Note any mentions of specific features, component versions and dates in these answer are subject to change.

I’ll post the results of the EE 6 Poll in a separate post.

Finally some links referenced in the Webinars for you convenience :

The Webinar replay (will be available in a week or so)

Red Hat’s PaaS – OpenShift

EAP 6 BETA Download

EAP 6 BETA Documentation

The Q&A

Developer Tools

Q: the current JBDS 5 beta does not include EAP 6, when will it include EAP 6?

A: A brief time after EAP6’s GA date – JBDS will GA prior to EAP6 GA – so post EAP6 GA will be the first time for us to get them sync’d up. Between now and then, simply download both, it is easy to add EAP6 to JBDS5.

Q: Will Zip file with Maven artifacts be provided in EAP 6 distribution or it will be a separate deliverable?

A: It’s a separate download on the Support Portal.

Cloud

Q: does the openshift flex support postgresql database?

A: yes it does.

Migration

Q: What about the migration from EAP 5 to EAP 6, is it transparent, or is it different?

A. There are definitely some major differences in configuration and management but applications should be largely portable from EAP 4 / 5 to EAP 6. We have created a migration guide and we also offer migration services.

Q: Would you please spend a few word regarding the migration path for Seam applications that currently target the EAP 5 release?

A: We have documentation for how to make Seam 2.2 applications run on EAP6. Furthermore, we will be delivering Seam 2.3 which will maintain the Seam 2.2 programming model but allow you to take advantage of JSF2.

Q: Being already partners, is there a path or redhat offer to help poc’ing the migration from EAP 5 to EAP 6 ? Thanks

A: Red Hat Consulting have a full set of migration services.

General

Q: will you publish the questions/answers ?

A: Yes.

Q: When EAP 6 GA will be available?

A : Subject to the outcome of the BETA, performance and quality – we plan to release within the next 4 months.

Q: You said you wanted to make sure you don’t do a vendor lock in, but how do you make sure that other vendors won’t lock you in?

A: Avoid proprietary technologies (languages, frameworks, tools) that are only available from a single vendor. Choose open standards and open source. Ask yourself this question about your technology stack – if the (single source) vendor goes out of business or pushes their prices up significantly what is your contingency plan ?

Q: Any idea when the beta’s will become stable?

A: EAP 6 GA is planned within the next 4 months but we may distribute a second BETA release before that.

Q: Will the support Lifecycle of Jboss EAP 4.3 be extended because of the late release of Jboss EAP 6?

A : We have a an extended lifecyle program for EAP – contact your local Red Hat representative for more details.

Q: Pros-Cons Domain Architecture versus standalone Architecture : will you better support the first mode ?

A : They will both be fully supported. Domain mode if you want to run multiple instances for HA or scale-out and don’t have other management tools. Standalone mode if you’re developing or don’t want our management wiring to get in the way of other management tools you use or have developed.

Q: What are technical differences between EAP 6 and AS 7.1 ? ( management tools, fixes, deploy tools, etc ? )

A : At the point of the BETA the difference between AS 7.1.Final and EAP 6 BETA are pretty limited – some branding and some critical bug fixes. As we progress through the BETA and our testing we EAP 6 will start to diverge from the last available AS release and that divergence will continue as we start the maintenance stream for EAP 6. More information on our model here.

Q: when will the Jboss Training courses start covering EAP 6, most spefically, the JBoss Application Administration course (JB336)?

A: JB366 (JBoss EAP 6 Admin.) will be available at GA – in fact you’ll be ale to take the course at Red Hat Summit / JBoss World in June. We’re also developing a new core developer course for EAP 6 that will be available at GA.

Messaging

Q: Have you enable data replication to hornetQ in EAP 6

A: It’s being worked on upstream but not planned for EAP 6.0 GA. It is on the wish-list for EAP 6.1

Q: When will HornetQ implement AMQP?

A : There are no plans for HornetQ to implement AMQP. Red Hat has a separate messaging product (Red Hat Messaging) that does support AMQP – Red Hat Messaging can be used as an alternate JMS provider for EAP.


Core App Server

Q: Will EAP5 bootstrap be updated to be compatible with Java 7? Or do we need to upgrade to EAP6 in order move forward in Java?

A : The plan is to certify EAP 5 with Java SE 7 after the GA release of EAP 6 – so within the next 3-6 months.

Q: Does EAP 6 contain tomcat 7.

A : EAP 6 embeds a modified version of Tomcat 6 with support for many Tomcat 7 features.

Q: When is EWS expected to uptake Tomcat 7 ?

A : JBoss EWS 2.0 will support Tomcat 7 and will be available later this year.

Q: Is there any EJB 2.1 support?

A: Yes but definitely in maintenance mode – you should consider moving to EJB 3.1

Q: Downloaded beta 1, can’t seem to find a way to “install it as a service” for Windows. Is this going to be introduced later?

A : The Windows Service Wrapper didn’t make the BETA – it will be in the GA and in BETA 2 (if we do one).

Clustering / Caching

Q: Why do not integrate The full Infinispan product in EAP 6 (not only for 2nd level cache or session replication)?

A: A number of reasons. The cache instance used for Query caching and session replication is tuned for a specific use-case, enabling it for general purpose use would likely impact both session replication and query caching. We have decided to offer a separate product (JBoss Data Grid) that is specifically for use a a general purpose, in-memory key value store. It can be run in embedded mode and also standalone and satisfies a broader range of deployment topologies and designs.

Q: Is JBoss Data Grid announced for end-March derived from Infinispan project ? Or any other relation between them ?

A : Yes JBoss Data Grid is based on Infinispan.

Modules / Class-loading

Q: Can we replace class on demand on working instance, without redeploying?

A: Possibly. Not out of the box. You’d need something like JRebel or Stuart’s Fakereplace to make it work. And of course there are limits to what kinds of changes can be made with that sort of mechanism.

Q: Will you support to access a Java module inside of an EAR via JNLP?

A: Sounds like a cool idea, though you can probably do this already using simple servlets.

Q: Can we point to application classloader what jar version should it use when we have many version of the same jar?

A: It depends. If you have more than one version deployed as deployments, or your JARs are installed as modules (either with different names, or with the same names but different versions) then yes, you can choose which one to link to simply by using the right Class-Path or Dependency entry, or their jboss-deployment-structure.xml equivalents. We do not support more than one version of a JAR within the same EAR’s lib/ directory or within the same deployment, and each deployment can only refer to one version of a JAR. You can however have an EAR with two subdeployments in it, with each sub-deployment linking against a different version of the same JAR (as long as the conflicting dependencies are never brought into contact with each other).


Security

Q: What is the status of PicketLink in EAP6?

A : PicketLink is included and fully supported.

Q: Is there any internal API to confirm x.509 certificate validity.


We do not provide any internal API to perform the x509 validation. You can use the standard JDK Classes for that. Usage of X509 depends on the subsystem:

If you are using JSSE via the JDK, then you can install your own Trust Manager

For the Web subsystem, you can use CLIENT-CERT and use any of the x509 based login modules.

Management Questions

Q: Can the domain controller be started from the command-line interface (CLI) as well?

A: No – you have to start it manually (or run as a daemon / service)

Q: What kind of scripting tool will be available in EAP6 ? Can all the tasks can be performed via the scripting interface ?

A: JBoss CLI was cover in the BETA Webinar, there are some more details in the docs.

Q: Is JON 3 packaged with EAP6 then? or still separate?

A: All JBoss Enterprise Platforms have a managed option that include entitlement for JBoss ON; though the products have their own distribution / installation.

Q: Will EAP6.0 contain more streamlined patches/fixes and will there be a better way to apply patches instead of copying jar files at different locations ?

A : Local patching is scheduled for EAP 6.1

Q: Does EAP 6 CLI able to deploy a web app on many instances at once ?

A: Yes – the CLI is fully domain aware.

Q: Can we see/configure all application servers under domain controller from the admin console of “domain controller” ?

A : Yes there is a physical view of running instances within the domain.

Q: Where web console keeps our modification? Does it change the XML files or what?

A: Yes. Any config. modification made through the management APIs are persisted in the underlying confg. files.

Q: Would twiddle still be supported?

A: No – we no longer support Twiddle but you can use something like JConsole to get at the underlying JMX MBeans or use jboss-cli.

Q: Does jboss-cli compatible with previous Jboss EAP releases?

A: There was no equivalent to jboss-cli in previous release of JBoss EAP.

Q: Will Domain Controller introduce a single point of failure (either at runtime for applications or for management operations) ?

A: No it isn’t involved in application request flow. In fact it’s quite common to disable the management infrastructure in secure production environments. We chose not to encumber the Domain Controller with an overly complex HA design, when the simple solution is to re-start it if it fails – or run it as a daemon / service so it is auto-started.

Q: is it possible to use JON3 to make automated deployments of jboss applications?

A: Yes., more info. in the JBoss ON 3 Documntation.

Q: If we can change configuration of other instances remotly, can it be done in transactional way – I mean all of the node confirm the change, or none of them in case of some failure

By default, if you make an administrative change that affects multiple servers, the Domain Controller will apply it on all affected servers and will roll it back on all affected servers if it fails on any of them. This constraint can be relaxed when using the CLI by adding an additional header to the operation request that specifies a “rollout-plan”. Among other things, rollout plan can specify that a certain number or percentage of servers in a server group can fail to accept the change without triggering an overall rollback. (See “Operations with a Rollout Plan” on for some conceptual information about rollout plans.

JBoss EAP 6 BETA Webinar

ease-into-the-cloud.png

Join me next Wednesday 3/14 – I’ll be talking about how to get involved in the JBoss EAP 6 BETA program. World-wide-friendly times :

  • Wednesday, March 14, 2012 | 14:00 UTC / 9am (New York) / 2pm (Paris) / 6:30pm (Mumbai)
  • Wednesday, March 14, 2012 | 19:00 UTC / 2pm (New York) / 7pm (Paris) / 11:30am (Mumbai)
  • Thursday, March 15, 2012 | 01:00 UTC / 6:30am (Mumbai) / 9am (Singapore) / 12 noon (Sydney)

Sign-up for the free Webinar here.

With all the enthusiasm of cleaning up a dog turd …

… Heroku finally got around to supporting Java. But they couldn’t do it without first piling on some hate.

Why then, if Java is such a miserable platform to develop on would Heroku bother ?

Here are a couple of thoughts :

1. Huge Developer Base

201108261621.jpg

2. Massive Adoption

Screen Shot 2011-08-26 at 4.22.48 PM.png

3. Large, Active Ecosystem

Only Java gives developers such a broad range of tools, technologies and APIs – both commercial and open source. Only Java gives you Open Standard enterprisey features like Transactions, Object Persistence, Messaging, Security, Integration, scalability and high availability for when you need them.

Basically, most professional developers use Java (if they aren’t beholden to Microsoft that is) and they, to a degree, decide how to spend money on deployment and long-term care and feeding of applications. And Heroku, like any other company wants to make money.

But why would a professional Java developer choose Heroku given their very out of date and poorly informed opinion of Java ?

Surely – Red Hat’s OpenShift is a better choice ? Instead of whining about Java’s shortcomings over the years – Red Hat / JBoss has put a huge amount of energy in fixing Java’s shortcomings – and doing it in an open and collaborative way so the entire ecosystem can benefit. Red Hat has a deep understanding of Java technology and open collaboration – more than anyone else in the industry. OpenShift’s support for Java EE 6 is a recent example of this – we didn’t sit around complaining that Java EE didn’t fit with the new deployment paradigm that PaaS represents – we simply did what we had to do to make it work. And you can try it for free.

Finally, as Isaac makes clear, it’s time for the folks at Heroku to wise up about Java and maybe trade in their 2004 copy of “Beginning J2EE 1.4: From Novice to Professional” and have a look at some of the advancements in Enterprise Java over the last decade. Hey – Adam – leave a comment and I’ll buy you a new book :)

Lightning Strikes !

Screen shot 2011-07-05 at 8.02.30 AM.png

Just 6 months after JBoss AS 6 was released, JBoss AS 7 (codename Lightning) is now available. Congratulations and a big thank you to the JBoss AS team and community. JBoss AS 7 is a major release in every respect and will become the technology underpinning for much of what we do at JBoss for the next decade. I believe it also represents a shift in the way developers will think about enterprise Java and it opens up new possibilities for deployment that were unthinkable 5 years ago due to technical and economic limitations.

If you’ve been following the AS 7 candidate releases (and AS 6 before it) then you already know that AS 7 includes some significant new features. I’m not going to list them all; but here are the highlights:

Developer Productivity

  • Startup-time and memory utilization have been significantly reduced which leads to a much more productive developer experience – no more coffee breaks during deployments and restarts.This required some significant rethinking and a fair amount of innovation (something we’re good at apparently)
  • The Java EE 6 Web Profile provides a much leaner, less complex platform for developers who focus purely on the web-tier – less to learn, fewer design choices – increased developer productivity
  • More flexible and powerful modular classloader – less time debugging and configuring classpaths; more time writing applications
  • Testable by Design with Arquillian with out of container testing for the business logic so developers can be more productive while delivering better quality applications.

Price / Performance

  • It’s probably a little early to claim significant performance gain over the competition right now but request path performance is a goal and the hard work of tuning and performance improvements starts now, One early indicator will hopeful give you a sense of what we’d like to achieve is the recent SPECjms2007 submission from Red Hat. SPECjms is a pretty narrowly focussed benchmark and not all the JMS vendors are represented, that said this is pretty significant for us as it is the first public benchmark submission from JBoss and good practice for future activities

Operational Ease of Use

  • Some of the more significant advances in JBoss AS 7 are around the operational ease of use. The configuration has been completely refactored around a multi-node domain model, though the simple single-instance view has been maintained for developer use as well
  • There are stable, easy to use management APIs – so AS 7 deployments can be completely automated from Java or any other scripting environment.
  • New shiny, task oriented domain console that also allows you to manage multiple, distributed nodes.

Anyway – time to stop reading and start playing : learn more about JBoss AS 7 here and get the bits here and provide feedback on community site.

Next post – how AS 7 relates to Red Hat’s commercial, fully supported distribution – JBoss Enterprise Application Platform 6.

Lightning Strikes !

Screen shot 2011-07-05 at 8.02.30 AM.png

Just 6 months after JBoss AS 6 was released, JBoss AS 7 (<codename>) is now available. Congratulations and a big thank you to Jason, Brian, Jaikaran and team. JBoss AS 7 is a major release in every respect and will become the technology underpinning for much of what we do at JBoss for the next decade. I believe it also represents a shift in the way developers will think about enterprise Java and it opens up new possibilities for deployment that were unthinkable 5 years ago due to technical and economic limitations.

If you’ve been following the AS 7 candidate releases (and AS 6 before it) then you already know that AS 7 includes some significant new features. I’m not going to list them all; but here are the highlights:

Developer Productivity

  • Startup-time and memory utilization have been significantly reduced which leads to a much more productive developer experience – no more coffee breaks during deployments and restarts.This required some significant rethinking and a fair amount of innovation (something we’re good at apparently)
  • The Java EE 6 Web Profile provides a much leaner, less complex platform for developers who focus purely on the web-tier – less to learn, fewer design choices – increased developer productivity
  • More flexible and powerful modular classloader – less time debugging and configuring classpaths; more time writing applications
  • Testable by Design with Arquillian with out of container testing for the business logic so developers can be more productive while delivering better quality applications.

Price / Performance

  • It’s probably a little early to claim significant performance gain over the competition right now but request path performance is a goal and the hard work of tuning and performance improvements starts now, One early indicator will hopeful give you a sense of what we’d like to achieve is the recent SPECjms2007 submission from Red Hat. In and of itself – this is the first public benchmark submission from JBoss and while not all the competing JMS products are represented – we’re confident we can crush the competition.
  • Stay tuned on this one.

Operational Ease of Use

  • Some of the more significant advances in JBoss AS 7 are around the operational ease of use. The configuration has been completely refactored around a multi-node domain model, though the simple single-instance view has been maintained for developer use as well
  • There are stable, easy to use management APIs – so AS 7 deployments can be completely automated from Java or any other scripting environment.
  • New shiny, task oriented domain console that also allows you to manage multiple, distributed nodes.

Next post – how AS 7 relates to Red Hat’s commercial, fully supported distribution – JBoss Enterprise Application Platform 6.

Anyway – time to stop reading and start playing : learn more about JBoss AS 7 here and get the bits here and provide feedback on community site.

The JBoss Product Lifecycle Explained

There was a fairly innocuous post on the interwebs at the end of last week which Oracle employees have jumped all over in an effort to discredit JBoss. I’ll rise above the petty mud-slinging and instead use this post to explain the relationship between upstream projects that JBoss uses and the downstream platforms that JBoss supports. It is my hope that people can then make their own informed decision about what to use to deploy their own applications.

So thanks for the opportunity to explain some of this.

First the obvious disclaimer – yes I work for Red Hat. Specifically I am the Director of Product Management for JBoss Enterprise Application Platforms and as such responsible for the product roadmap and technical direction of JBoss branded products like JBoss EWS, EAP and EWP.

So let me explain Red Hat’s model – something we call the Fedora / RHEL model internally. Red Hat provides subscriptions for use of its Enterprise distributions. A subscription provides the following (in no particular order) :

  • long-term world-class technical support – and we do it very well (PDF report)
  • long-term application compatibility
  • long-term stability and predictability
  • long-term partner certifications
  • legal assurance
  • long-term provision of security patches, performance enhancements bug fixes and RFEs

It may seem contrary if you’re used to the traditional model of “buying bits” but in our model, the provision of the bits is somewhat secondary; it’s something we have to do to support the value outlined above. For example, partners will only certify their applications and products if we have some way of identifying specific releases – supporting a continuous stream of releases is impractical. We can only provide application compatibility if we focus on specific identified releases.

So, one of the entitlements of a subscription is access to the supported binary distributions of a product – this is the thing to which we can apply all the other things I’ve outlined above.

For all of Red Hat’s products there are one or more upstream Open Source projects. In the case of JBoss EAP – the JBoss AS project is the primary components but JBoss EAP also includes Seam, mod_cluster, Apache CXF to name a few. Some of the projects that Red Hat uses in it commercial platforms are essentially Red Hat (or JBoss) projects – we provide the majority of developers, drive the roadmap and the release cadence (eg. JBoss AS, Seam, Hibernate), for others we’re merely one collaborator among many (eg. Apache CXF, OpenJDK, Apache HTTP).

Screen shot 2010-11-21 at 8.55.41 AM.png

The upstream Open Source projects is where the innovation happens – the focus of many of the Open Source projects driven by Red Hat is to act as technology incubators. Releases for projects like JBoss AS are frequent, experimental features are released, refined and re-released. That’s the focus – agility, speed, innovation. There’s never been any promise, implicit or otherwise that any given release is suitable for running your business critical applications. In fact we make it pretty clear on JBoss.org :

Screen shot 2010-11-21 at 8.40.58 AM.png

OK, so let’s dig into the relationship between project (or community) releases and platform releases. I’ll use JBoss AS (project) / JBoss EAP (platform) as examples as they are among the most widely downloaded / deployed :

Let’s take the JBoss AS 5 branch which was the foundation of the most recent JBoss EAP 5 family. JBoss AS 5 was focussed on a couple of big things : i) providing a new level of modularity via the Microcontainer 2.0; and ii) providing a Java EE 5 certified container. JBoss AS 5.0.1 was released in February 2009, followed a few months later by 5.1.0.

JBoss AS 5.1.0 met our functional criteria for JBoss EAP so that is what we picked up for our ‘productization’ process and JBoss AS 5.1.0 essentially became the Alpha Release for JBoss EAP 5.

Screen shot 2010-11-21 at 8.56.33 AM.png

The productization process is really not dissimilar to the kind of process you’d see in any other software company – we bring in all the major components, refine the dependencies, remove duplicates, perform additional testing above and beyond the community / project testing – focussing on security, performance, scalability, failure, longevity and the component integration points. We also look at documentation and the certification of third-party products like databases, Operating Systems, JVMs and other Application that work with JBoss. During this process we also run a traditional Early Access Program (aka Alpha, Beta) – this augments the attention the individual components receive during their own community release cycles. We’re fortunate to have some very willing customers who are able to apply significant resources to push our technology very hard using real-life applications and operational scenarios – often finding issues that are very hard to flush out in QE or during community release cycles.

The result of this process is an Enterprise Platform GA that differs from the upstream binary release we started with. First, we bundle additional components – like APR (Apache Portable run-time), Seam, mod_cluster, Apache CXF. And the core JBoss AS we include has a large number of fixes to address the security, performance and other issues identified during the productization process.

But that’s just the start.

Screen shot 2010-11-21 at 9.17.25 AM.png

JBoss EAP is supported for 7 years and with every additional minor or micro release we further improve the performance, security and stability of the Enterprise Platform. We’ve now released 2 micro and one minor release of JBoss EAP – that’s about 150 top-level issues in total. While the issue rate will slow over time – we’ll still be in a position to fix issues and respond to new security threats in 2016.

All those fixes are made available upstream and will ultimately make there way in to upstream binary releases but what the upstream project can’t guarantee is that those fixes will be isolated from more substantial changes and improvements – community releases typically don’t distinguish compatible bug fixes from more intrusive changes that provide the innovation.

OK so what happens to the community project once we’ve delivered an application platform? Well in the case of AS 5.0, from a Red Hat contributor perspective – the work was complete and Red Hat’s developers moved on to the next wave of innovation in AS 6 and AS 7. The goal of AS 6 is to deliver a Java EE 6 Web Profile implementation, the goal of AS 7 is to tackle the operational use-cases with a new domain model and console.

So to summarize this rather long post – if you want to deploy your business critical applications and receive long term support from Red Hat then the JBoss Enterprise Platforms are what I would recommend – if you’re more interested in seeing how those platforms will evolve and more interested in emerging technology but willing to take on more risk then upstream projects are where you should be looking. It all a matter of assessing the risk.

First they ignore you, then they laugh at you, …

“First they ignore you, then they laugh at you, then they fight you, then they produce lame marketing videos, then you win.”

– with apologies to the late Mahatma Gandhi.

Actually, I’d say if your competitors are producing videos at the rate that the Websphere marketing team are producing them about JBoss I think you can safely conclude that they’ve given up all hope competing with products and technology. The latest almost makes me feel a little embarrassed for the Websphere team. How the mighty have fallen.

Lies, damned lies, and statistics

First some insight into how my twisted mind works. I rarely believe any bar chart, pie-chart, percentage I see presented unless I can access the raw data myself and draw my own conclusions. I’m not a statistician by trade or education but I’ve spent a lot of time running surveys and analyzing large data sets; so I have the benefit of some experience.

Replay Solutions just published a survey about Java Platform usage. The questioning, subsequent analysis and presentation of the results was poor IMO. But they did one thing right – they provided the raw data. Thanks for that.

There’s a posting on TSS entitled “Why is JBoss at the bottom of this list ???”. In typical TSS style – few people actually bothered to read the survey results or question them and a long and rather pointless thread ensues. This post is an expansion of my comment at the end of the TSS thread.

The original report has this chart :

Screen shot 2010-04-09 at 11.07.48 AM.png

Update – Sunday 4/11/10

My initial (very quick) analysis was wrong. My formula for searching for different categories had a basic reg-ex flaw so I was over-counting JBoss by fair bit. I’ve fixed that mistake (spreadsheet here) and also removed duplicates (responses with both “JB + TC” and “Tomcat” or “JBoss” – I’d already admitted to this minor double counting (in the comments) – the original author’s analysis still includes this error.

So the ranking is now the same as the original author’s but the %’s are different. My apologies to IBM for originally stealing their #2 spot ;) By the way – Red Hat fully supports both Tomcat and JBoss AS – so #1 and #3 rankings and being able to satisfy 87% of the market isn’t such a bad result for us.

Screen shot 2010-04-11 at 8.25.17 AM.png

[As percentages of respondents – that’s : Tomcat = 59%, Websphere = 39%, JBoss = 28%, Weblogic = 23%, Other = 19%]

These rankings (WAS above JBoss) are more representative of larger organizations (where both WAS and WLS have traditionally been stronger) – the latest Eclipse survey shows a similar break-out. Unlike the Eclipse survey – this survey doesn’t have any information on the respondents and they seem to be largely self-selected.

My original points still stand – poor questioning, poor analysis and presentation are common in these kinds of surveys. Always ask for the source data !

JBoss, Jobs, Jobs, Jobs !

jbosscorp_logo.png

The JBoss team is expanding again – we’re looking to fill four PM / PMM roles – strong preference for location is Greater Boston (Westford, MA) :

Product Manager – Application Platforms

Product Marketing Manager – Middleware

Solutions Marketing Manager – Middleware

Technical Marketing Manager – Middleware

Submit your resume online via the above links and ping me if we’ve worked together in the past.