The service broker article intends to highlight a new developing type of middleware that I'm calling a service broker. This is where I expect the J2EE vendors to go with their web services push now that J2EE servers are starting to become commodized. As usual, any comments appreciated on this thread.

Read Requirements for Building Industrial Strength Web Services: The Service Broker.

Post your feedback here.

Billy

At Java One I had the fortune of being able to sit down one on one with people from Silverstream, IBM and BEA. Although they all had a different web services pitch and product suite, all of their solutions seemed to be gravitating towards the service broker middleware that Billy Newport describes in this article.

I agree with Billy's prognosis that Web Services will be used primarily to build horizontal applications with a web services interface. Most of the hype, products and announcements these days seem to be about web services on top of vertical applications, that is - a thin web services layer on top of an existing single server product. To me this is the equivalent of getting excited about a 'hello world' application. This is not what web services were intended for.

I predict that within 6 months or so the hype will have faded. Web Services with a Service Broker architecture will be used for building horizontal apps (as Billy suggests). This means that the hype will fade because a small minority of projects require/can afford this level of functionality. Web Services isn't for everyone!

Thanks Billy for this excellent real-world article describing what is really involved with building web services! I hope the vendors read this paper, it would be great to see the word 'service broker' become widely used in the industry.

Floyd

What Billy has described may also be termed a Business Process Integration System (BPIS) or Business Process Management System (BPMS). His view seems to be technically oriented and service-centered. However, from another perspective there is much more value in managing business processes, spanning process design, simulation, analysis, deployment, administration, monitoring and reporting. So, what Billy describes as a Service Broker would actually be a component of a BPMS.

Existing products, such as IBM's WebSphere Business Integrator, and BEA's WebLogic Collaborate already provide a good deal of BPMS functionality.

Process activities invoke business services, which may be implemented as EJBs, COM objects, CICS transactions etc. Of course, business services can be exposed as Web services. Yet a whole business process may be exposed as a Web service. From a business process management point of view Web services are very promising, since in theory they would enable application integration regardless of programming language or operating environment.

However, there are a few serious technical challenges, mainly security, quality of service and transactions. Just focusing on transactions I see several issues, some of which I would like to identify using a simple scenario.

Scenario: An activity (business process activity) is a Web Service, which is implemented as an Enterprise JavaBean (EJB). With container-managed transactions the EJB container sets the boundaries of the transactions. If the process engine is not implemented as an EJB, the Web Service EJB cannot "join" a transaction (i.e. the MANDATORY transaction attribute would cause throwing an exception). If the process engine crashes for some reason, it will reestablish a consistent state upon restart, actually resulting in the rollback of the activity. However, the activity implementation has already committed. Consequently, the process engine will schedule the activity for execution, resulting in the duplication of work. (the process engine might declare the activity just rolled back as "in doubt" and put the activity in "suspended" mode, however).

The above scenario triggers a lot of questions, for example:
- What happens if the process engine is implemented as an EJB? Then, the process engine can initiate a transaction, which the activity implementation can join. The inconsistency problem may not arise.
- What happens if in a business process, exposed as a Web service, some activity implementations are EJBs, some are COM components, some are CICS transactions, some are ...?

The problem space can become extremely complex, since entire business processes can be exposed as Web services. In addition, Web services can be composed of other Web services.

WSDL does not provide information on non-functional characteristics of the service (e.g. QoS information). Also, there is no way do declare Web services as transactional. We need both ACID transactions and transactions with isolation and durability conciously relaxed.

The overall goal of Web services, to enable application integration regardless of programming language or operating environment would be severely compromised if it was not possible to solve the transactions issue in a satisfactory way. Consider the above scenario: just putting in a process engine implemented as an EJB would make a real difference.

I wholeheartedly agree with Billy's statement about benefits. However, joint effort is required by all players in the industry to make the concept actually work for transactional and security-sensitive Web Services. We want business processes to include business services implemented as EJBs, COM components or whatever else. However, what I actually see is vendors clinging to their platforms. Regarding business transactions, I am not aware of any initiative where all the big players work together. The OASIS Business Transactions Technical Committee is chartered with the development of technology for business transactions on the Internet. However, neither IBM nor Microsoft are members.

So, will Web Services just be the bone of contention in an extended war over platforms?

Cheers

Totally in agreement. I didn't mean it to come across as service oriented, like you, I see Web Services principally as a BPIS not as an RPC mechanism.

The big challenge now is to make this standards based to avoid J2EE being buried under a proprietary web services stack and hence lost it's portability aspects.

But, I don't see J2EE as the standards process for this. The whole point (or we fail) is for a service broker to be able to include components written using legacy technology, J2EE, Corba or .Net. This means the standards body should be 'above' the J2EE or .Net bodies.

As for the points on transactions, it's difficult. It all depends on the protocol used to reach the WSDL endpoint. If we use HTTP then we need application logic for failures, if we used MQ under JMS then it's straightforward. It all depends on the transport.

When we need application logic then I think we may see the BPMS side of the service broker being used to implement compensation tasks when the business process starts to hit 'failures'. These compensation tasks would attempt to programmatically rollback any changes made so far.

Billy

Hi all,

From experience in this area (using various business process / process integration software on middleware), the hotspot always ends up at the transactionality of the end-point systems.

EAI over the past few years has come in two general forms - those trying to integrate existing applications and/or services within an organisation (to provide reuse or encapsulation of existing systems, reduce system management overheads [as if!], external visibility, inovative use of existing system data, enterprise data integrity etc etc etc - we've all seen the possibilities), and also those trying to provide a new enterprise framework, based upon EAI technology, where existing systems are being gradually phased out, and are treated as end-points rather than 'hub systems'.
The manuafacturing industries have typically entered the fray in the first category (through serious investment over many decades in existing systems / in house applications), and service based industries in the second. Within this sector however, the lack of externally visible transactionality of these systems, makes providing a business service layer on top extremely difficult, as you have to re-implement business logic to provide rollback.

This is where we always seem to get stuck.

Until we can define a service orientated layer which sits at the end-points (v.v. expensive in man-power and lisences I expect!) I cannot see how this can be overcome.

The technology is willing, but the legacy is not mobile.

David

Hi David,
You're experience matches my own. It's easy to get hung up on transactions but I think it's a safe bet that it's going to remain a problem for some time to come. There will always be some system that doesn't support transactions that we need to talk to.

All we can do is to handle compensation transactions/processes for when trouble shows. Anyone who has read Frank Leymans book "Production Workflow" is probably already familiar with compensation spheres w.r.t. BPM.

Support for Compensation spheres in the BPM engines seems to me to be the only rational way to move forward. They are a very strong concept but aren't widely implemented.

Billy

Is anyone aware of a BPM engine that actually implements the compensation sphere concept?

Dieter

I'm not sure if there's any kind of explicit support separate from the regular product workflow development, but our BEA support engineer, when first telling me about Weblogic Process Integrator, which has now been rolled into their WL Integrate platform, was talking about compensating workflows for transaction rollbacks before I had heard it anywhere else.

Hi Billy,

Thanks for a great article.

In the context that you describe, where do you think Bowstreet's products fit?

I've heard a lot of hype about their products, but they don't seem to give away a lot about how they actually work.

Thanks in advance.

Carl

I think the problem these 'smaller' niche tech companies will have is that if a customer is going to invest heavily (and we are talking big bucks) in this sort of thing then customers will only do it with large financially sound companies such as IBM, Microsoft, BEA etc. Given the current tech environment and the lack of standards, it would be hard to see a company making these large investments unless they are sure the vendor will be here for some time.

This, of course, has nothing to do with the technology but this is how things work at large corporates. Why take a risk when you can 'safely' go with Microsoft or IBM for example. These projects are 2-3 year or more projects and are very expensive, you need to be sure of who you're working with.

Please note that I have no knowledge of BowStreets financial situation so please only take this comment w.r.t. the groups of such companies in general not with Bowstreet in particular.

Billy

Service Brokers are already starting to appear. In the software arena, Microsoft's Biztalk Server is very close to what you describe.....in the ASP world, GrandCentral is very interesting as well. GrandCentral allows you to connect web services in terms of routing, security, etc...

check them out at www.grandcentral.com

Best,

Damian

At the risk of being stoned, I have to say that when I first saw BizTalk, I thought, "Finally, some one gets what I want". People compare J2EE and COM+/.Net and argue over platform and entity beans etc but for me, Microsoft have been in front for some time now as regards vision and delivering on that vision.

It may only run on Windows but it's going to have great tooling, be easy to use and be very keenly priced compared with almost any J2EE based solution + server broker + a database.

Bravo Microsoft.

You views are on the right track for sure. Perhaps you should look at the whitepaper previously published by interKeel Inc (www.interkeel.com).

Hi! Billy
   I have some puzzles about Service Broker,need your help.
I think what you talked about Service Broker is EAI(Enterprise Application Intergration) actually.But now there have lots of products about EAI such as Tibco,Forti(iPlanet) etc. .How do you think about these products?Can they reach the same effect of service broker?
   Thank you!
                                      solid
                                   [email protected]

WebServices is not a new concept. The concept of WebServices "legalizes" what has been there already and what would have been built in the future. One point that I like about Billy's article is that he points out that WebServices is more than just putting the standards together (SOAP, UDDI, WSDL). This is not WebServices. If it was one HelloWorld WebService would do the job.

The WebService needs relevance. It gets this relevance by being easily developed and deployed (producing) and by the ease of use of WebServices, let's say in a EB Portal scenario (consuming). This may be harder or easier, depending on what you want to achieve (depending on the data sources you want to integrate and what you are planning to do with these). Some vendors have great solutions on this, other's do the standards and leave the rest to your imagination and vision.
WebServices = Producing is wrong
WebServices = Consuming is wrong

instead:
WEBSERVICES = CONSUMING and PRODUCING

Only if you see the whole thing (= big picture), this new technology makes sense and can help you to improve what's already there.


cheers!


Patrick

Excellent article, I wholeheartedly agree that the Service Broker is certainly an integral part of any Web Services solution. You did a great job describing the concept of a Service Broker, however, there are some points I would like to make.

I see in a response to another article on Web Services that you state that the word “Web” refers to “Web Of Services” and not “World Wide Web Services”. I agree with you that the moniker Web Services is misleading – but who are we to argue with the industry.

I disagree with you on a 4 main points.

1. Firstly, my definition of a Service Broker is a system that is only concerned with configuring, managing and delivering the Web Service from the Web Service Provider to the Web Service Requestor.

2. In the article there is mention of the Connectors being able to deliver the service directly to the requestor. In actuality the Service Broker delivers the service directly to the requestor, while the Connector will be purely concerned with providing the business functionality of the service. To take your example of the ‘Get City Weather’ Service - Lets say a service is requested using SOAP but the ‘Get City Weather’ Connector is a CORBA Component. A Service Broker retrieves the service from the CORBA Component over IIOP, its native transport and delivers the service over SOAP to the requester. So as the standards evolve and more appear, the broker merely adds new delivery mechanisms without requiring changes to the Connector Components.

3. Business Process Management (BPM) is not really part of the Service Broker. A Service Broker in itself is not concerned with an overall solution, using Web Services. This is the job of the application that assembles business logic using Web Services. A Service Broker is purely concerned with delivering these Services, not how they are used. Similarly the Service Broker is not concerned with transactional issues as each service is atomic. Sure – to provide a complete solution then BPM is required to create Processes from Business Services and chain them together and so on, but the Service Broker itself does not need BPM.

4. Content Based Routing/Transformation/Enrichment does not really play a starring role in a Service Broker initially, but just like with message broking it will become important in the future. Content based rules may be simple to apply to document (and message)-centric architectures but they may be difficult, if not impossible, to apply to service-centric architectures, as the rules governing the services should be contained solely within the business applications or the BPM Tools. However, Quality of Service issues may best be addressed within the Service Broker itself (prioritisation, Service Level Agreements ...etc...).


Also, I work for a company called WEST Global Ltd. that has a Service Broker that, coincidentally, performs as described above. Check out http:
www.westglobal.com for more information.

Best Regards
Brian Dennehy
WEST Global Ltd
mailto:bdennehy at westglobal dot com

See my response in <bn>

1. Firstly, my definition of a Service Broker is a system that is only concerned with configuring, managing and delivering the Web Service from the Web Service Provider to the Web Service Requestor.

<bn>Agreed, but I think that a service broker may also allow composition of different backend servers in a a more complex service.</bn>

2. In the article there is mention of the Connectors being able to deliver the service directly to the requestor. In actuality the Service Broker delivers the service directly to the requestor, while the Connector will be purely concerned with providing the business functionality of the service. To take your example of the &#8216;Get City Weather&#8217; Service - Lets say a service is requested using SOAP but the &#8216;Get City Weather&#8217; Connector is a CORBA Component. A Service Broker retrieves the service from the CORBA Component over IIOP, its native transport and delivers the service over SOAP to the requester. So as the standards evolve and more appear, the broker merely adds new delivery mechanisms without requiring changes to the Connector Components.

<bn>We're agreeing here, it's a policy that determines which protocols a backend service is exposed as. Adding a new delivery mechanism should be as easy as updating the policy.</bn>

3. Business Process Management (BPM) is not really part of the Service Broker. A Service Broker in itself is not concerned with an overall solution, using Web Services. This is the job of the application that assembles business logic using Web Services. A Service Broker is purely concerned with delivering these Services, not how they are used. Similarly the Service Broker is not concerned with transactional issues as each service is atomic. Sure &#8211; to provide a complete solution then BPM is required to create Processes from Business Services and chain them together and so on, but the Service Broker itself does not need BPM.
<bn>I disagree here, I think being able to do choreography and service brokering are big deals. If we're doing service brokering then we need an exception mechanism and hence choreography.</bn>

4. Content Based Routing/Transformation/Enrichment does not really play a starring role in a Service Broker initially, but just like with message broking it will become important in the future. Content based rules may be simple to apply to document (and message)-centric architectures but they may be difficult, if not impossible, to apply to service-centric architectures, as the rules governing the services should be contained solely within the business applications or the BPM Tools. However, Quality of Service issues may best be addressed within the Service Broker itself (prioritisation, Service Level Agreements ...etc...).

<bn>I'm thinking that the service broker can be used to do integrate and expose backend services to different kinds of clients. Some clients are more agile and will readily move up to higher revs of the backend services. Others are slower and hence need an integration layer to bridge the old interfaces to the new ones. WSDL is pretty for think type of bridging and it's like an ultimate DSI when combined with technologies like WSIF.
</bn>

Billy,
This is a very good article! I think that it is right on when it comes to the computing pain of the enterprise and the role web services will play with regard to standardizing connectors.

I am not sure that the orchestration/BPM layer you are describing will leave up to its promises: Do you think WSFL is the right modeling metaphor for capturing the complexity of the interactions\transactions\exceptions you are describing in your article?

This is one of the best web service article I have read so far!

Edwin

Welcome to my world,

Greetings from India. Along side your article on Service Brokers, I just completed reading a set of articles on the net (from IBM, WSA etc). I had in the past gone through a lot of the Web Services stuff and was not able to get the right picture, thanks to all that semantic obfuscation.

My background is mostly CORBA/CCM (in the beginning) and Software Architecture (the recent past). This way, I am more the OMA/MDA guy. It all begun with the introduction to the Service Oriented Architecture (SOA). The first thing that struck me was SOA is nothing but a primitive version of OMA, only thing new is, its adapting to the demands of the web. Finally, what I have understood is that SOA is an offshoot of the OMA and EAI/Messaging/Workflow styles.

I wish to clarify a few points with you.

Point #1:
---------

What is WSDL's specific role. I find it very close to IDL. However, with all the bindings and services tags, it looks like being bound to a specific address location. The is somewhat ambiguous to me. Also, WSDL has four styles of invocation of which solicit/response and notification are again ambiguous to me. With the addition of messaging/asyncronous semantics to SOAP, I get confused with the WSDL. Does this mean that the same WSDL prototypes can be realized using both RPC and Messaging semantics or is it that notification & one-way means messaging and request/response & solicit/response means RPC. Could you clarify this a bit more.

Point #2:
---------

My overall understanding of web services are described below. Enterprise portals are exposed to the client through [web pages/web components]. Behind the JSPs and Servlets, we have a flexible workflow system that can interact with the various application, advertising their services on the net. They could come from various companies. All of them exposing their services using WSDL. The workflow is coordinated in WSFL and the orchestration process is managed by a business process manager sitting within the Web Tier.

The elements of the workflow are essentially stateless process components defined in WSDL encompassing a specific division of an enterprise. Inter/Intra enterprise communication with the BPM will take place using ebXML/BizTalk frameworks. The process components accept an XML document that is part of the overall work flow. Each time the XML document passes through the workflow, it gets transformed/enriched. Finally, the XML document will reflect the final output of the process. Ideally each of these process components are realized by a set of CORBA/EJB/.NET components. Depending on the complexity, a messaging middleware could also be used to realize integration of components. What I can see is fractals of components that can be zoomed into to find sub components and at the micro-architecure level, objects. Patterns are ubiquitous.

The processes have to be loosely defined. This aids flexibility to redefine/add/remove new/existing business processes. As we zoom in further, we will see that the granularity of the component/detail will be finer. Well, do I make sense?

Point #3:
---------

All this point to the fact that SOA and Web Services are immature and an OMA is to be done to Web Services to be made usable. Finally, only the architecture of the system will decide on the amount of leverage you have. So, SOA/Web Services will take a lot of time to evolve into a mature implementation.

All of them put together, could it look something like this:
(Please reformat to remove the words/lines wrapped by the editor)

Tier 1 Tier 2 Tier 3 Tier 4 Tier 5 Tier 6
---------------------------------------------------------------------
PDA, Web Business Web Service CCM Legacy,
Browser Server Process Components EJB DB
... Manager (XML) COM+
                                             Components

        ^ ^ ^ ^ ^
   HTTP/HTML SOAP ebXML IIOP Proprietary
                          UDDI SOAP Connectors
                          SOAP JMS ...
                                        DCOM

          ASP BPML WSDL IDL SQL
          JSP WSFL Java JDO/ADO
                                            COM+ IDL JDBC/ODBC

        So long,

                Jacob.

Hi all,
  i was going thru that article and i have one basic doubt.
Where does the SB reside in the big picture??
For example: i have my web site in which i publish
following web services:
- booking holidays
- get stock quotes
- get weather informations
- buy lottery tickets

As far as i can understand, the ServiceBroker resides behind all of them, so that all of them will send their own SOAP message to the SB, which in tuns invoke the 'component' that perform the logic.

Is that correct??

thanx in advance and regards
   marco