Skip to main content

skip to main content

developerWorks  >  WebSphere | Architecture  >

Meet the experts: Greg Flurry on building service oriented solutions

developerWorks
Document options

Document options requiring JavaScript are not displayed


New site feature

Check out our new article design and features. Tell us what you think.


Rate this page

Help us improve this content


Level: Intermediate

Greg Flurry, Senior Technical Staff Member, IBM　

13 Sep 2005

This question and answer article features Greg Flurry who answers a wide ranging set of questions on creating solutions using service oriented architectures.

Introduction

In this "Meet the Experts" article, SOA expert Greg Flurry answers questions on using IBM® products such as WebSphere® Application Server V6 and WebSphere MQ to build service-oriented solutions, and about using such products to build an enterprise service bus (ESB). WebSphere Application Server V6 includes everything you need to build robust service oriented solutions. It offers the industry's premiere J2EE application server for hosting applications, and includes WebSphere Platform Messaging that allows you to access the applications via an ESB. Greg frequently travels to customers to help them define and implement service oriented solutions.

Questions:

  1. How do we define a scope for a service?
  2. What kind of services could be services? For an infrastructure component such as a reporting server, could it be exposed as a service?
  3. How does the orchestration work from an one service perspective? I have a service, "MyService", that needs to produce reports using more than one data source. How is this scenario achieved? When I write MyService, what do I need when I deploy it?
  4. Is there any model or best practice for charging for the usage of a service?

Answer:

  1. There is no one answer to the scope of a service. All I can offer is some guidelines on how to identify and scope a service. One of the major goals of a service oriented architecture, or a service oriented solution, is reusability. In other words, you do not need to create a service from some business function that was used by only one application. However, if two or more applications want to use a business function, it is a good candidate to become a service. Perhaps the next thing to consider is granularity. Unfortunately, in some cases, there is a performance penalty for remote processing, and a service is not different. As a result, you typically want to identify large-grained business functions and define large-grained services. To do that, you want to understand your business so that you can identify the business functions or business tasks that qualify. There are other factors, of course, that may constrain the scope of a service. Consider outside business partners that provide or request some sort of business function key to your business. In that case, the scope of the service is defined for you. Sometimes you may define a large-grained service and recognize that it needs to be split into multiple services, but this is not much more than classic decomposition.
  2. IBM typically thinks of a service as a business function or business task, but if your solution needs some sort of infrastructure component surfaced to an application, then it can be exposed as a service.
  3. I am not exactly sure what you are asking, but I will try to answer what I think you are asking. If "MyService" needs to access multiple data sources, there are at least three options. The option you use depends on the nature of the data sources. First, if the data sources are standard databases, you can use normal techniques (for example, JDBC or EJB) to get to it. Second, if the data sources are legacy systems, you might have to use adapters or JCA. Third, you might have to mix the first two. Depending on the nature of MyService, you could develop it as standard Java™ code, such as a stateless session EJB, to deploy normal J2EE application server deployment techniques. On the other hand, if MyService is more complex, it may need to be described as a business process, an orchestration of multiple services. In this case, you could define MyService via BPEL using tools to assist in the definition of the business process. Deploying this in IBM application servers is also similar to normal J2EE application server deployment techniques.
  4. I am not aware of any industry-wide best practice for charging a service. Once again, the subject is more complex than it may first seem. Is the charge simply usage-based ("pay per click"), or does the charge have to consider the quality of service achieved (for example, response time)? That said, while I can't claim it is a best practice, I can say that most of the charging systems I have seen are "out of band" with respect to the requestor and provider. An example would be a JAX-RPC handler, or a mediation in an enterprise service bus.

Question: Could you please suggest a tutorial that has an example of implementing service oriented architecture and building an ESB?

Answer: Here is a list of some of the resources on SOA and ESB:

Here is a list of some of the articles that are more WebSphere® Application Server V6 related:

Question: If I understand correctly, MQ Version 6 can be installed on OS/390. If I were to install it on my distributed platforms first, is it downward compatible? Will it really give me anything more on Windows® and AIX® since I am running Version 5.3 CSD09 right now?

Answer: You can definitely install WebSphere MQ V6.0 on z/OS. The product is MQ for z/OS V6.0. There are advantages to upgrading to MQ 6.0 and, more specifically to MQ for z/OS V6.0, including enhanced availability and distributed configuration capability. I should note that my answers derive from the WebSphere MQ Web site. I have no personal experience with the product.

Question: We use WebSphere Business Integration as an ESB in order to route message from application to services. All is based on MQ series. What's the future for WebSphere Business Integration? Could we do the same thing in terms of routing with ESB integrated into WebSphere Application Server V6 compared with WebSphere Business Integration?

Answer: WebSphere Business Integration will continue to be part of the IBM product line. There may be some name changes to reflect product enhancements. You may find function from WebSphere Business Integration appearing in other IBM products. That brings me to your second question. The "ESB integrated into WebSphere Application Server V6" is a technology called the service integration bus (SIB). The SIB includes many of the capabilities of MQ and some of the capabilities of WebSphere Business Integration, at least in terms of what you expect in an enterprise service bus. These capabilities include routing, protocol conversion, message transformation, and so on. The most significant differences are in terms of scope and maturity. MQ and WebSphere Business Integration are mature products and thus have "built-in" enterprise scope and robustness, associated tooling, and widespread expertise. The SIB is not quite a year old. Its current primary target is more of a workgroup or site scope, but it does support federation that allows you to build an enterprise-wide ESB. You won't find much tooling, and only recently a significant amount of information has been produced to help spread expertise. These limitations should be addressed as the technology matures.

Question: I am working on a document integration project. There is a print/fax/EDI use case: The user can select some work orders and print/fax/EDI in the WebSphere Portal page. In this process, it will print/fax/EDI about 200 documents. After the user clicks print/fax/EDI button in the Portal page, he can leave the page and ignore those print/fax/EDI job. My suggestion is: We use MQ to handle those print/fax/EDI job, since they are time-independent and MQ is good at asynchronous process. What do you think? If MQ is a good selection for this case, do you have any materials about integration of WebSphere Portal and MQ?

Answer: You are correct that MQ exceeds at enabling asynchronous processing, and it would seem to work well for your project. I'd like to put a service-oriented spin on your second question. The most common way to build service oriented solutions is using Web services. There should be a lot of information on integration of portals and Web services at the IBM developerWorks WebSphere site. There is even a standard that bridges portals and Web services, Web Services for Remote Portlets (WSRP). For an overview of the WSRP standard and how to use it, see Introduction to Web Services for Remote Portlets. IBM and many others support SOAP/JMS bindings for Web services. Furthermore, it is possible to use MQ as the JMS provider, so you can use Web services over MQ. Of course, it is also possible to write portlets that use just JMS and use MQ as the JMS provider.

Question: We are using WebSphere MQ V5.3. We wish to modify the message expiry of messages already placed in a local queue. Is there any way to do so without having to get the message and putting it back?

Answer: Sorry, no. You have to take the message off and put it back. I'm not sure quite what you're trying to achieve, but one thing you can do is run an API crossing exit that can override the expiry value used by the putting application. However, once it's actually on the queue, there's no way to do an MQUPDATE.

Question: How to access the overloaded operations of an EJB Service using the JAX-RPC client through "wsejb" binding? How to access the overloaded operations of a SIBus outbound service destination directly using JAX-RPC client through the SIB binding? Background for the two questions: I have succeeded in accessing the overloaded operations of a standard Web service using the JAX-RPC client through SOAP binding. If the target Web service is integrated into an SIBus through SOAP outbound port, I can also access the overloaded operations using the JAX-RPC client through SOAP inbound port, but I fail to access the overloaded operations of the SIBus outbound service destination directly using the JAX-RPC client through the SIB binding.

At the same time, if a target EJB Service is integrated into an SIBus through the RMI-IIOP outbound port, I fail to access the overloaded operations of the EJB Service. Even if the EJB Service is not integrated into an SIBus, I cannot access its overloaded operations using the JAX-RPC client through the WSEJB binding either. I suspect that the WSEJB and SIB binding cannot support overloaded operations. I am using WebSphere Application Server ND V6.0.0.1.

Answer: My first thought is that you should avoid using overloaded operations. They are frowned upon in WSDL, but they are possible in WSDL 1.1. Overloaded operations are not compatible with the current de facto standard for WSDL descriptions of a Web service called wrapped document/literal. Furthermore, overloaded operations will be disallowed in WSDL 2.0.

The reasons behind the EJB binding failing are to do with the way the method name is "mangled" when sent across RMI/IIOP. We just do not support overloaded operations across the WSEJB binding. The effort required was not justified given the status of overloaded operations in the Web services community.

The reasons why API attach (client targeted to use the SIB binding namespace) does not work are not clear. There could be a bug. That said, we would not consider connecting directly to the outbound service a best practice. It is better to go through an inbound service, which avoids the problem. Of course, you would not have the problem in the first place if you avoid overloaded operations as recommended.



Resources



About the author

Author photo

Greg Flurry is a Senior Technical Staff Member in IBM's Enterprise Integration Solutions group. His responsibilities include working with customers on service-oriented solutions and advancing IBM's service-oriented products.




Rate this page


Please take a moment to complete this form to help us better serve you.



 


 


Not
useful		Extremely
useful
 


Share this....

digg Digg this story del.icio.us del.icio.us Slashdot Slashdot it!



Back to top