Forum members will be responding to these questions and we invite additional comments. Feel free to add any new questions here. If you did not have an opportunity to participate in the Light Reading Service Broker webinar, you can visit the Light Reading Webinar archives to view in it’s entirety at http://www.lightreading.com/webinar.asp?webinar_id=29234

How does the additional cost of the SB impact the business case for services?

Is service broker more relevant to being part of applications layer, or to the network control layer?

What is the expected performance hit when using a service broker?

Given the importance of web apps/web services in this environment, can you comment on the use of Parlay-X vs RESTful APIs to expose network services? Do they compete? Which is more prevalent today?

ALL-IP networks are not cheap to implement. Do you actual numbers on per port savings while moving to all IP networks. Do all IP networks provide carrier class reliability on a per port basis and user experience? What are the compromises here ?

What type of hardware is best to support the service broker requirements?

What of the presented functionality is available, what is roadmap or candidates?

Are there any standardization efforts or best practises regarding the language or scripting technology for orchestration of standalone services into composite scenarios in realtime manner in Telco domain, just like BPEL in IT domain?

How long do you think it will take for media convergence to reach maturity?

NG IN platforms have SIP and IN capabilities, so why need for SBs?

You are describing the service broker as a multiprotocol system. How is it implemented? I ask so because the JSLEE technology comes into my mind (multiprotocol, telco services, etc.).

What is done with SDP (session description protocol) on SB or AS level?

Do I need to change any of my applications in order to enable a Service Broker to work on my network?

Is the operator empowered to manage service interaction logic on Service Broker?

Do I need to change any of my applications in order to enable a Service Broker to work on my network?

Are any TEMs/OEMs included in the forum?

Is the intention of the ServiceBrokerForum to influence the standard?

The upcoming Light Reading webinar:  Bridging the Legacy/Next-Gen Services Divide: Service Brokers, provides Service Providers, System Integrators, Application Developers and Telecom Solution Providers an opportunity to learn more about the innovative approach to leveraging existing and new services across all networks with Service Brokers.
Join Light Reading and the Service Broker Forum October. 20th at 10am Eastern time/3pm UK time.  Register today on the Service Broker Forum home page to get signed up!

By now many of you may have heard the recent buzz around the growing momentum within the Service Broker market. Service Broker solutions have emerged as a result of Service Providers exploring new innovative ways to manage their application connectivity, application to network interaction and application orchestration across the service layer.

What until now has been a rather disjointed market with many different niche solutions and perspectives on what a Service Broker should look like and how it should behave within a Service Provider’s network has now begun to come into focus. According to the recently formed Service Broker Forum, a Service Broker is by definition a standalone network element that resides between the service layer and the converging network. It serves to decouple the core switch from application servers and service execution and creation environments. The Service Broker product class provides an efficient and cost effective means to manage application connectivity, application to network interaction and application orchestration across the service layer.

While the emergence of the Service Broker product category may be new, the concept and underlying need has been building for some time. The Service Broker origin can be found in the 3GPP definition of the Service Capability Interaction Manager, the SCIM. The definition has recently been enhanced and expanded to deal with the various converging network and converging application challenges Tier 1 Service Providers are facing.

The 3GPP expanded interpretation, combined with a couple of other market factors have led to the current momentum behind the Service Broker. The ongoing need to address the complexity of the evolving network has brought Service Providers to the realization that there must be an alternative to the traditional siloed, niche connectivity and interworking models. The combined forces of the current economic reality, the competitive landscape and the need to drive down costs, leverage existing resources and increase revenue have caused additional momentum behind the Service Broker solution.

The reality is that what was once the promise of an all IMS NGN has given way to the reality that the next network will continue to be more of a hybrid, leveraging old, current and new resources going forward. As my 6th grade social studies teacher always said “The only constant is change” so goes the ongoing network evolution, best to be prepared to manage the change by leveraging the Service Broker to take advantage of yesterday’s, today’s and tomorrow’s resources.