I currently develop a Web application that can be accessed over HTTP by an Android application or a Web browser. Both user agents basically provide the same functionalities. The Android app calls RESTful Web Services built with JAX-RS/Jersey, while Web pages are Facelets backed by JSF managed beans. I thus consider that there are two types of possible entry points to the Web app. The Web services do all the necessary work (accessing the resources, performing the database operations within DAOs, etc.) and most importantly, they must act on their own. Therefore, they constitute an independent layer.
In order to reuse the code, is it a good practice to call a Web service from a managed bean? Are their life cycle compatible?
The idea is to inject the Resource object into the managed bean (with CDI, but not necessarily) and to call its methods programmatically. The Web service would act as a business delegate (?) to the underlying services.
I widely googled the question but I didn't get a clear answer. I saw some pieces of code where the managed bean invokes a Web service with its URL, but since all my components are located in a single server app, I don't see what prevents me from linking them directly.
Subsidiary question on error handling: I am also annoyed with the idea of catching WebApplicationExceptions from the Web service into my managed bean for returning error messages back to the view (with FacesMessage). My father always told me that I should never catch runtime exceptions...So, is there a good way to handle them correctly?
In this case, you would be better off having the business logic out from the Web Service into "some central shared code". Then, then web services and the managed beans would call into the shared code.
I've put the term "some central shared code" in quotes, as what you use depends on your runtime environment. If you're using a JavaEE container like Glassfish or JBoss, this sounds like a perfect use of EJB and stateless session beans (which are designed to ensure the resources are managed well). You could also use Spring Beans as the shared code and centralize the logic that way.
It all depends on what you find more comfortable from a development and production sense. But both support injection, so both the Web Service and JSF Managed Beans could have the services injected as any other resource.
Related
I am planning to build an application bundle that includes a mobile app, a website and an web service for other developers. Website has the first priority and mobil application has second.
For creating the mobile application ordinarily first i need to create the web service.
What is the way i should follow:
Create web service, than website and mobile application using it.
Create website, than create service and mobile application.
P.S: I will develop the service and website using Scala and Play! Framework
The optimal order will vary depending on priorities and how stable requirements are.
Usually during development, the understanding of the problem improves and the requirements change. This can happen particularly for the user interface. The first usability tests can lead to changes in the application's design and behavior.
A construction order that takes this into account would be:
Create an initial version of the website. Depending on the project this would include a short description of the project, a way to collect emails, and authentication features such as user registration and login.
Create the mobile application, mocking the service layer in the mobile application itself (i.e. using mock service proxy objects). The objective is to discover and stabilize user interface requirements. This process will clarify which services are needed, which operations these services must perform, and exactly which data these operations must receive and provide.
Implement the web service, based on the already stabilized requirements.
Complete the web site, including description of the application's features and benefits, and showing the application's content (e.g. screenshots, videos).
This order assumes the application's features are the main benefit of the project. If, on the other hand, the main value and complexity resides in the web service, and the application is just a thin, optional front-end over it, then it might be more appropriate to develop the web services first and then the application.
I'm investigating integrating a 3rd party web application with PeopleSoft via web services. I'm not that familiar with PeopleSoft. After some initial investigation, it appears that in order to expose any PeopleSoft functionality as web services, you have to do some considerable configuration in the Integration Broker component of the PeopleTools module. It seems that you can either define internal PeopleSoft services with "service operations" and related "handlers" or you can create a PeopleSoft service for an existing "Component Interface." Then, you have to expose that PeopleSoft service as a web service.
Are there any standard, default, out-of-the-box web services available for a PeopleSoft system, or do you always need to go through the steps of defining them in the Integration Broker?
After looking at a system like Salesforce, which has a standard web services API, it seems like there might be something similar for PeopleSoft, but I'm not finding it. Am I on the right track in thinking that the Integration Broker is the only way to go, or am I just not aware of some standard web services API that exposes basic PeopleSoft functionaity as web services?
Integration Broker (IB) is what you need to expose business logic from peoplesoft and consume it with your 3rd party tool, or to consume a webservice from your tool in peoplesoft.
There are some out of the box messages, but most of them are made to have different PIA (PeopleSoft Internet Architecture) communicate.
Be aware, IB components were almost complemently remixed in peopletools version 8.47. So it's important to give your tool's version when talking about IB.
Never heard about a standalone API for implementing web services, outside of the IB framework. IB will use dedicated class to handle sending and reception of your messages. You mention it as the handler. And if a component interface need to be used it will be done throughout this class.
Integration broker is used to setup the basic configurations that will be used in exposing and using web services. this includes making nodes and its routing available for other system to use.
http://docs.oracle.com/cd/B14099_19/integrate.1012/b14060/int_broker.htm
There are many web services available in peoplesoft. you can alsi expose any componemnt as a web services by executing very simple steps.
http://docs.oracle.com/cd/E15645_01/pt850pbr0/eng/psbooks/tibr/chapter.htm?File=tibr/htm/tibr14.htm
Custom web services can also be build.
I'm learning about web services and most of the resources I've been reading talk about registering your web service once it's ready for use by others. Is registering a web service required to use the service?
For example, let's say I have a web application on a company intranet and I create another web service app that retrieves some sort of useful information to be displayed on this private intranet site. Would this new web service require being registered just so my web app can use it or can the web app simply interface directly to the new web service (following the WSDL file) without the need of some sort of UDDI registry?
You can certainly use the service without the UDDI registry.
I have created several Web Services and have immediately used them without registering them. Registration gives others confidence that your Web Service is legitimate and descriptions of how to interact with those services.
Imagine doing development where you have to register any Web Service before using it. Yikes!
No, not at all.
You are probably talking about API directories you may register your WS at. Like UDDI or what it’s named. Entirely optional.
Nobody uses UDDI anymore. It's an idea whose time has come and gone.
It was thought that there would be public registries of web services that everyone would use to find a web service to meet their needs. That never happened.
How could either the service or the app know whether or not the service was registered?
Furthermore, why would they care?
If you're trying to use service orientation the right way, your web services should be registered within a service registry. The registry should contain the published contract of the services and any meta-data that helps the discovery process.
A different questions is: does a service consumer program need to look up a registry and dynamically bind the service it needs to call? NO, NOT AT ALL.
But then, what discovery process am I talking about?
I'm referring to a human (developer, architect, etc.) who is designing/developing a program that needs to call a service. This person should have means to search what services are available in his/her organization. If not, the benefit of reusing services is compromised.
Discovery is also about humans finding out there's a service somewhere in the IT organization that offers the functionality they want.
In this case, the registry can be as simple as an html report that is created and updated manually or generated by parsing (xslt comes handy) the wsdl files.
I have a web application that exposes webservices, developed in java.
One of the client system is a siebel platform; as they told me, they cannot manage arrays/list of objects.
Which is the best solution to solve the problem?
How should I redesign my services?
Consider that my data structure requirement includes list of objects...
Thanks in advance
The team who are telling you that Siebel cannot manage list of objects within a web service are not telling you the truth. The Siebel application should be able to use your web service definitions to generate a proxy service within Siebel (which creates a Siebel internal web service definitions and integration objects). These need to be compiled into the Siebel srf and mapped to internal Siebel integration objects which in turn need to be related to Siebel Business Objects and components. It is certainly a non trivial piece of development if your team has not done it before but it is entirely possible.
A friend wants to consume my ASP.NET MVC 2 application in a similar fashion as adding a web reference to it, accessing my functions, and using my model objects from a .Net web form from a separate website.
Any links out there that could explain how to "dress" my MVC responses so that his server to server consumption would be similar in experience to a web service?
I suggested using System.Net.WebClient to pull the results in to a variable then deserialize the JSON result, but maybe there's a better approach out there?
I'd suggest that you consider an API controller or a separate API application depending on the load you expect from people consuming data from your application. A separate API application will allow you to move it off your application servers if needed.
Rarely, will you find that the data that you would provide via an API is a one-to-one match with what your views need to be rendered. Behind the scenes you could abstract the data generation so that your API and your application controllers reuse the same code to get at the data, but the front-end of the API would understand how to negotiate security (from an API perspective) and present data that is easily consumed by a program. Moreover, you won't find that you're creating extra controllers and methods in your application just to provide some data that will never be used in a particular view.
You could use MVC or WCF for the API and JSON or XML as the payload format. If you use WCF, you get the benefit that he really can simply add a service reference to connect to it without you having to build a WSDL file/action.
From another's advice, Phil Haack added this to MVC 2 Futures. Add the DLL reference to the Application Start, and bingo. It uses a validator.