Core Improvement / Bring SPI first-class citizen - Java SE (Archived)

Finding out SPI implementations you have to deal with undocumented class sun.misc.Service !!!
This is not acceptable as lots of J2SE API rely on that mechanism :(
Every SPI enable API like Javasound came up with their own  solution for doing things.
SPI-like things are also used in java web start services but in an inconsistent way regard the regular SPI mechanism ...
So let's have a first-class SPI related JSR that will define a firs-class citizenship for the SPI mechanism.
- What is SPI
- How you implement SPI
- How you bind a SPI
- How you lookup for an implementation
- How you lookup for an implementation that match "some given features"
There should be ways also for a "ServiceManager" to install and uninstall SPI implementations "at the fly".
Please consider this ...

The new (tiger) apt tool uses Services as well, even refers to it in documentation (as does the jar spec), but this mechanism (which is really nice, extensible, and sensible) isn't in the core API.

I agree 100%.  I've implemented my own clone of SPI on several projects.  However, when you bring it out, don't stop there.  Add optional support for version constraints relying on java.lang.Package.getXXXVersion.  THen I can finally package various implementations of an interface in separate jars and let SPI make sure it selects one with the right version at runtime.


WebDAV server implementation

I'm currently trying to implement a WebDAV interface for an existing system to allow browsing it's content via normal file managers and to allow interaction with applications such as Microsoft Word or Excel, which can directly access WebDAV resources.
Ideally I'd like to leverage existing libraries, and I've set out to find them. Until now I've found WebDAV and Jackrabbit (both are Apache projects).
WebDAV seems overengineered and underdocumented for me and doesn't seem to lend itself to be used to interface an existing project (or maybe I just fail to see it's elegance). And from what I see of JSR 170 (which Jackrabbit is closely associated with) it seems equally over-engineered and far out.
Has anyone implemented a (at least somewhat complete) WebDAV interface to an existing project and has some hints/suggestions for good tools? Or am I better of just implementing all that myself (I really, really like to avoid that, as I know how much work it can be to implement such a protocol myself). 
No hints?

Developing Custom GSS Mechanism

My team is in the process of building a client/server platform in Java that interoperates with a proprietary platform. The existing platform uses a proprietary security architecture that was inspired by Kerberos (v4?).
Rather than develop my own security API, the JGSS-API seems like a good fit for me.
If I can prove that our proprietary mechanism can be adapted to JGSS in this emerging platform, we may decide to invest in factoring the legacy platform to use the C GSS bindings. The logical reason for doing this would be to eventually swap out the legacy security architecture altogether for Kerberos and, in theory, achieve SSO with other applications with little effort (OK, so I'm an optimist).
I see where I am able to register a for a given mechanism through GSSManager#addProviderAtFront/Back, but the documentation seems to indicate that a GSSManager can be overridden to disallow this.
Nevertheless, it seems awkward for me to have to bootstrap my security mechanism in a programmatic fashion when other such security providers can be registered through SPI. Am I missing something or should GSS have an SPI mechanism for this purpose? Does it have one that I'm missing?
I have a feeling this is not the beaten path, but it seems that a tutorial for GSS providers would come in handy here. I'd be willing to assist in putting one together if I could get some nudges in the right direction.
Any insight is much welcome,
I think I was making this more complex than it needed to be. Just subclass GSSManager and have the application code instantiate the specialized GSSManager. There's not much point in trying to "register" the proprietary manager with the default GSSManager as other applications would not know about the proprietary mechanism anyway.

Drawbacks to developing JBI Components

From a developers perspective my instinct tells me there appears to be two drawbacks to developing a JBI component.
First, I have to waste thousands of brain cells creating/updating a WSDL.
Second, each component is responsible for XML transformation (binding). For example, each component takes the incoming content (XML) and uses JAXB or XMLBeans to get some Java objects he can work with. Then right before he sends the response he uses the same objects to set the response content.
I was under the impression that we were getting away from all that complexity? Axis, XFire, JAX-WS, JSR181, etc�.. I thought all shared a common goal of providing developers a quick way to create web services by not requiring them to create WSDLs, supporting annotations, and handling the binding automatically.
To me there is a big time difference compared to writing a JAX-WS web service running in Glassfish and writing a JBI component.
Am I seeing JBI component development differently than how it was originally intended? Perhaps I am unfamiliar with potential existing solutions.
Thanks in advance.
I think part of the issue is vocabulary: the term component is way too overloaded. A JBI component is basically a plug-in container, akin to an EJB or servlet container (for example), which happens to be able to interoperate with other such containers. Code-level components are much different creatures. I suspect your expectations may have been set by the latter use of 'component'.
Most developers should be using existing JBI components. For example, you can create services using the WS-BPEL engine, and expose them as SOAP endpoints using the SOAP-over-HTTP binding component. You deal only with BPEL or SOAP, not JBI itself, which is invisible to component users.
That being said, developing new JBI components does happen; there is a lot of that happening at open-jbi-components over at All components have to solve the same challenges you mention, and usually in similar ways. What we need is a good JBI component implementation framework, that does most of the common stuff for you. The component still needs to map from its own domain to XML (and back), but there are plenty of technologies to help with that (JAX-B, XmlBeans, etc.). When the component leverages technologies like JSR-181 the mapping can be very easy.
Great explanation; thanks. You are correct in assuming my expectations have been set by your second definition of "component."
It's frustrating because just when I think I figure out JBI, reality sets in and I find out I don't know that much.
I have a lot of responses so let me try to narrow them down.
It's great that most developers should be using existing JBI components. What's not clear to me is when to develop a Service Engine verses developing a JAX-WS Service for example. Both seem to have a common goal of providing business logic. To me the main difference is with a Service Engine you get LifeCycle support. And JAX-WS Services are must simpler to create.
Could you give me some examples of "components" that should be JBI components that don't exist today? Also some examples of "components" that should not be JBI components but rather JAX-WS Services.
Also your explanation has caused me realize how critically important the BPEL and J2EE SE's are. 
JBI has to qualify as one of the most unusual standards to ever come out of the JCP, because it primarily addresses a very small audience (implementors of JBI environments and plug-in components), yet it is of great value to a much wider audience (the users of those plug-in components), who use JBI only indirectly.
When should you develop a new service engine? My short answer is "only when you have no other choice." SEs and BCs provide support for specific application and protocol technologies, respectively. If you need such a technology, and the appropriate SE (or BC) doesn't exist, you may have a case for creating a new SE (or BC).
You always have the option of implementing support for such technology separately, outside of the JBI environment, and using standard protocols such as SOAP over HTTP or JMS to connect to your JBI environment. In theory this lets you avoid implementing some JBI component features, but practice this ends up being more costly in terms of development effort. For example, a JBI SE doesn't have to worry about implementing SOAP, or any other protocol for that matter.
JAX-WS and JBI really have different goals. JAX-WS is an API for applications, to add WS support easily to Java code. It is meant for "regular" developers. JBI defines a "container of containers", defining an infrastructure for accomplishing integration of different application technologies and communications protocols.
JBI was designed as an integration technology. Any integration technology requires "adapters" for existing applications, protocols, resources, and services. That has always been a weak point for any integration technology -- do you have adapters for X, Y and Z? The big problem was that all those adapters were proprietary, which really locked you in to a particular vendor. JBI changed that, by introducing the standardized adapter: the JBI component. From that perspective, there are plenty of opportunities to create new JBI components out there. Packageware, CICS, custom apps, etc.
JBI also creates a "composite application" environment, which I suspect is your primary interest -- composing useful applications from a variety of application technologies, such as EJB, BPEL, even XSLT, and making those applications available over a variety of transports & protocols. From this perspective, there is still plenty of space for new components. I'd like to see a service engine that supports ebXML BPSS, for example. I'd also like to see a component that serves as a UDDI registry, exposing all of the internal services within the JBI environment to design tools. A business rules engine would be cool (I believe that is being developed already). I'd like to see an engine that integrates portal support, perhaps using WS-RP. I'd like to see some scripting engines, as well as a lighter-weight process engine (BPEL is very capable, but can be a problem if latency / throughput are of primary concern). I've love to see a work flow engine (XPDL would be very useful).
That's off the top of my head. I'd say that the current crop of components is enough to accomplish some very interesting, useful things. Their main accomplishment is to isolate you from all the plumbing underneath the covers -- you can concentrate on creating BPEL, or EJB, or XSLT, or configuring (not coding) SOAP, JMS, FTP, etc, access to/from BPEL, etc. Although JBI is a very interesting technology, I'd say it is doing its job when it 'disappears' into the plumbing, and application developers aren't even aware that it is there. 
+1 for everything Ron stated above. If you do find that a new JBI component is necessary, the Common Runtime Library (CRL) is available to help facilitate the development process. CRL provides a set of utilities and base implementations of the core JBI interfaces. The intent is to ease the complexity of navigating the plumbing of the JBI specification and allow the JBI component developer to focus on the implementation of their component, not JBI. For more information, please read my blog entry at 
I agree. Thanks Ron for your time. I would consider myself a component developer and application developer. Perhaps that is why I am having such a hard time.
You mentioned a UDDI component that exposes all of the internal services w/in the JBI env to design tools. I don't understand the need for that functionality. Perhaps what you are thinking is the ability to provide the internal services to the design tool such as BPEL to orchestrate services? Also I believe ServiceMix has what you call a lightweight process engine. They call it the ServiceMix-EIP component: They support 9 different routing patterns. We have used it and it is quite simple and valuable.
I was not aware of the CRL; thanks Kevan. I assume this is what Netbeans using when it automatically creates SEs and BCs. I am curious to know if I use Netbeans to create a SE, i assume it extends those CRL abstract classes? So to get the latest abstracts classes all I have to do is update the CRL and not re-autogenerate my SE stubs?
On a side note, ServiceMix also has this ability with their artifact servicemix-core,
We use these abstract classes to avoid creating our own.
Also Petals has a Component Development Kit (CDK):
Thanks guys for your feedback. Looking forward to the next JBI milestone I hit. 
A few follow-up comments about CRL. It's not a Netbeans library. It's intended to be IDE-independent as well as JBI-implementation-independent, the latter of which we're in the process of verifying. So far, only a few of the service engines are using CRL and I'm lobbying hard for more buy in to flesh out some of the gaps. So Netbeans is not really part of the CRL picture. The primary goal of CRL is to facilitate JBI component development based on the JBI spec and the spec alone.
That said, CRL does provide abstract and default implementations of some of the core JBI interfaces (Component, ComponentLifeCycle, Bootstrap, etc) to simplify the creation of an SE or BC. More importantly, there's no autogeneration of anything. You never need to worry about losing your changes because CRL has changed. CRL is entirely interface-driven; meaning if our implementation doesn't work for the needs of your component, don't use it. No vendor lock-in! Hope that clarifies a few things.

jbi components

Does open-esb come with jbi components (SEs and BCs) that I can reuse in other jbi compliant esbs? (I'm mainly looking at SEs)
If yes, could you tell me how I can get them ?
Hi Ryan,
JBI components are meant to be API compliant, not implementation compliant. What does this means?
It means that any JBI implementation (the hosting service and the NMR) have to be provide the same basic level of APIs and will expect the same SPIs from the components.
But, it also means, that some components may rely on some extension of a specific JBI implementation, and there is nothing in the specification to prevent this. For example, a BC could expect to be in a J2EE environment. If you try to install it in a JBI that is in a J2SE environment it would simply not work.
So, BC and SE may or may not work in different JBI implementation. It depends on what the expect the environment to offer. I would expect BC and SE providers to have to test and validate that their BC and SE works with a list of JBI if they want to offer them to multiple implementations. Or they would need to make sure that they distribute everything they depends upon.
I think that in most of the cases, it should work. Especially for simple components. But being able to live in multiple JBI implementations is not a requirement for a component to be a good JBI citizen.
I guess unless you have a specific statement from the SE, BC provider that is has been tested, you're on your own about finding it out...

JavaMail SPI design problem

I'm planning to support a corporate proprietary mail system through JavaMail SPI extension. The problem I'm facing is the fact that the system
has such functions that don't fit well in JavaMail api (Store or the Transport). Most of the functionality can be tweaked to follow the api but in order
to fully support the underlying system some extra methods must be introduced thus 'breaking / extending' the JavaMail api. The problem with this is
that one must use concrete classes (ie casting to concrete implementation class) instead of for example Store or Transport.
The way I see it this kind of cripples the abstraction the API is supposed to give. The idea of using JavaMail is the fact that someday these proprietary
systems will be replaced with standard smtp / imap protocols.