The HTTP/SOAP binding component (BC) provides external connectivity for SOAP over HTTP in a JBI 1.0 compliant environment. It supports the WSDL 1.1 and SOAP 1.1 specs (the RI example uses WSDL 2.0, SOAP 1.2). Message exchanges to and from this BC make use of the JBI WSDL 1.1 wrapper for the normalized message. It implements the SOAP binding from the WSDL 1.1 spec (not HTTP Get/Post or Mime bindings). It follows WS-I 1.0 conventions and adds additional support for non-conforming components. It supports Document and RPC style web services. The HTTP/SOAP binding component supports literal use and currently only some very limited “Section 5” SOAP encoding such as simple arrays. It supports the common convention of WSDL retrieval via <service uri>?wsdl. It uses XML Catalogs following the OASIS Committee Specification - these allow the component to resolve schemas locally without resorting to network access. It Packages an embedded HTTP server (Grizzly). It uses asynchronous I/O (NIO) to service 1000s of concurrent incoming requests. Outbound requests are currently handled through SAAJ 1.2. To service requests directed at a port serviced by an application server instance, a Servlet can be deployed to handle these requests in the HTTP/SOAP BC. It supports JBI service unit deployments to define the web services to provision or consume. It makes use of the WSDL extensibility (standard SOAP extensions) to define external communication details for the web services to provision or consume.



Component Configuration
To support component configuration at installation and run-time our components follow the following conventions not covered by the JBI spec:

• Component configuration defaults are present in the JBI descriptor of the component
• These defaults can be overridden via JBI installation configuration parameters at installation time. This is how our web GUI allows these to be changed
• At run-time, a custom JMX MBean exposes the configuration and allows relevant settings to be changed on-the-fly

Instrumentation and Management
JBI 1.0 does not directly define many component-specific run-time monitoring and management capabilities (with some exceptions, e.g. lifecycle extensions. It does however provide access to the java management extensions (JMX) infrastructure; our components therefore use the following additional conventions to support enhanced management:

• For monitoring purposes, the component directly creates and manipulates a monitoring object and registers it as an MBean.
• Standard interfaces allow the GUI to understand the capabilities provided by the monitoring MBean.
• For management purposes, a MBean is registered that exposes the configuration properties as MBean attributes and advanced management functionality as MBean methods.

Figure 2: HTTP/SOAP Binding Component Configuration

Frequently Asked Questions

• Is this equipped to support faults defined on operation both directions (our application calling external web service and external client calling our web service? What is the support for fault not defined (server/client) on WSDL operation?
  Yes, it will handle faults for webservices for both inbound and outbound invocatoins.
  • For faults defined in the WSDL, the fault is converted to/from the standard normalized message format using the WSDL 1.1 wrapper defined in the JBI spec.
  • If the fault is not defined in the WSDL, the fault is sent internally as a normalized message without the WSDL 1.1 wrapper - because we wouldn't have a valid value for the mandatory type setting on the wrapper..
• How does the BC handle services on different ports?
  For services defined on ports that are not served by the application server, it contains an embedded server that will listen on those ports. For services defined on an application server port, a servlet needs to be deployed to handle the "services" context
• When there are multiple operations defined in a porttype/'interface' bound to the same soap address URI, how does it know which one to invoke?
  It uses either the soapAction or the message signature to distinguish requests, depending on which one is unique within the WSDL definition (and present in the request). If neither is unique or present in the request, a fault will be returned indicating the ambiguity.

Why do I need to know this?
The good news is that you don't need to know any of this to use Java Business Integration(JBI). Perhaps the even better news is that JBI is tightly, seamlessly, and transparently integrated with the GlassFish Application Server. However, we thought some people might be interested in learning how this actually works behind the scenes.

SOA developers who are the users of the Java EE Tools Bundle therefore only need to use domain concepts and technologies related to the business problem they are addressing because JBI and the GlassFish Application Server provide that Invisible Plumbing that makes it easy for the SOA developer. This allows the composite application developer to concentrate exclusively in domains he is expert in, and leaves the business of weaving the services he writes into the overall SOA fabric to the Java EE tools bundle.

Download the Java EE 5 Tools Bundle Beta from http://java.sun.com/javaee/downloads/index.jsp for FREE, and provide us feedback on the improvements you'd like to see. It combines the new Java EE 5 SDK with NetBeans IDE 5.5 Beta, NetBeans Enterprise Pack 5.5 Early Access, and Sun Java System Application Server Platform Edition 9. This bundle also contains Project Open ESB Starter Kit Beta, Java EE 5 samples, Java BluePrints, and API docs (Javadoc).