Understanding Web Service Packaging Considerations


If you have multiple EJBs and/or Java classes sporting your business logic, how many distinct Web services should that translate to? Figure 30.9 conceptualizes this question.

Figure 30.9. Decide how many distinct Web services should be created.

graphics/30fig09.gif

WebLogic gives you maximum flexibility in deciding how best to package your myriad business logic back-end components into Web service offerings. Some questions in this regard are

  • Should you combine all your component methods (EJB or Java class methods ) into one single Web service that possesses all those operations?

  • Should you categorize your business methods in some way ”for example, by functionality or domain ”and create a distinct Web service per category?

  • Is a distinct Web service one that has its own unique service name or context root, or both?

The following is one very important guideline that might answer all these questions:

Try not to expose your component or application model as your Web service model.

First, your component model is probably too fine grained. Web services should be coarse grained to reduce the number of network calls and increase service reliability. Second, a Web service should interact at a business level. A component API typically reflects your technical framework or architecture, which by nature uses different, nonbusiness objects and vocabulary. The exception to this rule is if the Web service functions as internal plumbing; that is, it is an intra-enterprise Web service. We will discuss best practices later in this chapter. For now, see what options you have with ServiceGen . Figure 30.10 diagrams these options.

Figure 30.10. How ServiceGen can organize your Web services.

graphics/30fig10.gif

The following discussion relates to Figure 30.10:

  • Methods in all selected EJBs and specified back-end class files within a <service> element will be combined into one Web service. The implication here is that the method names cannot collide in the same Web service; that is, they must be unique. Otherwise, ServiceGen will warn you that method overloading is not supported.

  • You can pick and choose what particular back-end EJBs in an input EJB JAR file to deploy as a Web service. This is done using the includeEJBs or excludeEJBs (but not both) attribute of the <service> element. Both attributes take comma separated EJB names as arguments. The attribute includeEJBs lists the EJBs in the input JAR file that should be made into Web services, whereas excludeEJBs says to include all EJBs found in the input JAR file except those listed. If neither is specified, all EJBs found will be merged into one Web service.

    Figure 30.10 shows an EJB JAR containing three EJBs: ejb1 , ejb2 , and ejb3 . Service1 includes only ejb1 and ejb2 . Hence, the Web service represented by //host:port/context1/Service1 will have operations from both ejb1 and ejb2 .

    Service2 , on the other hand, includes only ejb3 and a back-end Java Class1 , by exclusion. Hence, the Web service represented by //host:port/context2/ Service2 will have operations from both ejb3 and Class1 .

    Note

    Nothing prevents you from including the same back-end component in multiple Web services, although there is no good reason to do so.


  • To create more than one Web service (multiple unique serviceNameURI s) that shares the same context root, specify multiple <service> elements in ServiceGen . Each <service> element translates to a separate Web service within one context root. Of course, the service names within that context must be unique.

  • To create multiple Web services with different context roots, you must invoke ServiceGen separately for each context root. In that case, service names do not need to be unique across context roots.

Before we leave this topic, let's consider some grouping guidelines. First and foremost, each Web service should possess methods that are related in some way. Second, your back-end components may have interdependencies that require them to be packaged in the same Web service. Another consideration that applies only if your back-end components are secured is whether one set of credentials will permit usage of every EJB included in that service.



BEA WebLogic Platform 7
BEA WebLogic Platform 7
ISBN: 0789727129
EAN: 2147483647
Year: 2003
Pages: 360

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net