WWDC2003 Session 624

Transcript

Kind: captions
Language: en
good morning everybody hope you
guys had a nice lunch a good nap or a
session depending on how awake you were
and hey that wasn't a joke so we're
going to talk about web objects and
creating web services this is session
624 if any of the above sounded wrong
you're probably in the wrong room
alright as our nice friendly voice of
God introduced me I'm Carl sue i work in
webobjects engineering and i'll be doing
the first half of this presentation the
second half the presentation will be
done by my compatriot rondo sang he's
the friendly Jamaican Chinese guy so we
have to have the obligatory what you
will learn in this session slide because
they told us all right so web services
we're going to talk very briefly about
what a web service is in our case when
we talk about web services we're going
with a stricter definition I mean
technically web services is anything
where you invoke services over the web
but we're going to specifically talk
about the standards based web services
that webobjects provides and uses we'll
talk a little bit about practical
applications of web services why you
would use web services in lieu of just a
regular HTTP connect or korbo or
anything else like that then finally we
get to the meat of the matter we'll talk
about web objects and web services what
objects is a server web objects is the
client and finally about the crown
jewels for web services in web objects
direct to web services hopefully that
will be a relief to those of you who
have been going to the web object
sessions and not actually hearing a
whole lot about what object so in a
single sentence what our web services
web services are remote procedure calls
for the Internet era and their xml-based
the goal I think in that one sentence
was to hit as many little buzz words as
you possibly can it'll sound great to
managers IT people it's fantastic there
are a bunch of standards in specs in the
official web services sphere there is
description of the web service in
wsdl which the web services description
language there's discovery of a web
service how you find what web services
exist and how do you find the
information about them and that's the
uddi which answers something I can't
remember Universal discovery definition
and interface or interrogation something
like that nobody calls it that nobody
remembers what it's called everybody
just says uddi so when you hear that
buzz word floating around you know what
it is ah that's discovery the encoding
of the web service itself when you send
XML back and forth you have to agree on
a particular way that the XML will look
that's soap the simple object access
protocol and finally the transport when
you send the XML and receive it you have
to do it over something over the wire or
whatever and those very that's probably
the most flexible part about the whole
thing but the two most common the two
that are defined in the spec itself are
HTTP and smtp web bob jects in
particular mostly deals with HTTP so
let's go over a little bit over the
parts of a web service when people talk
about a web service they typically talk
about three major parts there's the
wisdom and the wisdom the wsdl is a
contract it defines everything about
your web service you can sort of think
about it as the interface to a class
when you publish a web service you
publish the Wizzle to it and that's what
the client uses to know how to talk to
the web service there are a number of
tools out there that can also use the
wisdom to generate stub classes and and
so on and so forth the service itself
consists of a set of operations and
invocation information it's the again in
an analogy to the class itself it can
hold state or whatever you needed to do
the operations exist within a service so
that's something to keep in mind a
single service can have multiple
operations it's sort of a grouping
because the service exists at a certain
point it exerts exists at a certain URL
and then you can invoke multiple
operations at that point those are
analogous to methods let's take a quick
look at the wisdom the web services
definition language it's also defined in
XML and it basically defines everything
you need to invoke a web service it's
the structure of the web service itself
it defines data types that are used in
the web services not only the standard
set of data types in strings
dictionaries whatnot but also custom
data types that you may have for your
web service yo global IDs whatever it
defines message types requests responses
error messages anything that you might
send what you're supposed to send and
what you might get back it talks about
the available operations on that web
service what can you do with it can I
add something can I you know invoke a
particular method that will return some
status whatever it's all in there it
defines where that service is actually
located the URL or address that you
would invoke that web service at and
finally it talks about the transport
bindings most of the time for web
objects insecure that will be HTTP ok
let's talk a bit about soap it's the
simple object access protocol this is
basically the protocol when you send the
XML across the wire you can think of
this a little bit like the meta schema
for what you're actually going to send
across it defines the language in which
you will define your web service ok it's
split it splits up the message layout
itself so each soap envelope will then
have a header in which you can stuff
ancillary information about the the web
service itself in a particular
invocation for instance it might include
routing information or session based
information and then the body itself
which is where the bulk of the data
that's going back and forth across the
wire is kept
the souks standard defines several
transport protocol HTTP and smtp but it
leaves it open for plug-in they're not
tied to a particular protocol you could
conceivably write a web service that
required somebody to write down the XML
on a piece of paper run to your
neighbor's house and give it to them and
run back it wouldn't be very effective
but it would technically be with things
back just to show you just because it's
a spec doesn't mean that it works it's
not you know a lot like statistics it
supports synchronous and asynchronous
mode you can do the standard sort of
HTTP way you send a response the service
it does whatever it's doing and then it
sends you the record I'm sorry you send
a request
I'm sorry I'm not worthy you send a
request it gets processed and it sends a
response there are also asynchronous
modes in which you know the server may
pull a client for a request or for data
and so on and so forth an interesting
thing at this point is that there are
two major styles of web service there's
an RPC style of web service and there's
a document style of web service most
people I think would like to be using an
RPC style the RPC style is invoked very
much like a remote procedure call that
would be our PC you invoke a method you
pass arguments in a particular order and
you get back a response document Styles
a little bit more flexible but it's also
more annoying it's more work you
essentially say I'm going to send you
XML soup in some privately defined
format you meup with it and send me back
more XML in a privately defined format
and we'll kind of negotiate it there
this actually negation agates a large
point of web services which is easy
negotiation and easy understanding of
what you're actually sending and
receiving so this is a really quick
example I mean you can sort of see if I
wanted to find an RPC service it's very
analogous to a class and a method you
receive optional arguments you return
something in in the case of a document
service you just get basically in our
case you would get a dom tree and you
would have to return something very
similar so problem solved by web
services the major bonus of web service
is that it's very clean information
transfer there are a number of services
out there Watson for instance where at
least initially I'm not sure about now
the whole point was that it would screen
scrape it would hit a website get back
the HTML and it would have to then parse
its way through the HTML looking just
for the information that you're looking
for that's bad because it means but it
means that if they decide to change the
look of the site if they say you know
what we're going to do something nice
we're going to put an ad here we're
going to
move this search field around or
something like that you're totally bored
right and sites change all the time part
of the point is that you know the
display is fluid it also means that it
doesn't dictate any sort of display or
usage you can expose the information you
expose the service and the client can do
whatever they want for it they can
present it directly back to the user
they can aggregate it they can they
could do whatever you want another
important thing is that its
implementation dependent the spec tries
to be as clean as possible so that the
server doesn't have to know anything at
all about the clients and this is what
really separates it in large part from
custom solutions things where you just
agree on a private format between you
and the client in this case you don't
need to know anything about the client
if you're the server or vice versa it
tries to be fluid in a way that the spec
tries to income pass pretty much
anything so you can have webobjects
written in Java running on Mac os10
talking to pearl running on Linux or C
sharp running in a.net cause the dotnet
client on a Windows machine and you
don't have to know what that is as long
as you can talk the web services talk it
goes back and forth and everybody's
happy and finally one of the reasons it
was created this way is that its
firewall friendly unlike older
iterations of things like carbon such
you don't have to open up any funny pork
you don't have to do anything
interesting to make your system
administrator really unhappy you
basically punch a hole you know you no
longer have to punch a hole through
anything you can just route it right
through your web servers a way that you
would normally and because it fits that
well that well onto this distorted
internet standard it makes things much
easier to use the best part about it
though is that it's human readable
this is actually isn't a very
complicated thing I think the best
description that I've ever heard of this
is the fact that the soap XML is human
readable does not actually guarantee
that it is readable by humans so you
could in fact it could conceivably
encrypt it or something like that it
doesn't really matter I mean the goal is
that you wouldn't actually have to look
at it one of the goals of things like
web services is that the XML is well
defined XML is well understood the soap
spec that defines how the XML is
structured is well understood and it
becomes very easy for you to write tools
so that machines can talk to machine it
doesn't it it's built written in XML
it's done in XML so that there are a
number of tools available to read and
write it not so that you can actually do
this by hand please if you do though it
would be really interesting to hear
about it okay hold on a second it should
be obvious by now participants in a web
service you have a server and you have a
client often they're called a provider
and a consumer it's just a different
name for it shouldn't have to worry
about it theoretically what ends up
happening is the server will write the
web service they then register with some
sort of universal directory and then
they publish the wsdl set to in a way
that's described in the directory so you
would go to the directory and you would
look up i want web services that do
let's say something really lame add two
numbers together and you would get a
list of urls for contact information and
whizzed alok ations for those services
then you could hit those services take a
look at the wisdom that came back run
your client automation thing and now you
can talk finally of course the server
has to provide the web service itself
the client does the opposite it has to
look up the web service in a directory
it will then configure itself using the
wsdl and it can invoke the web service
the configuration using wsdl can be
either dynamic or static there are a
number of tools out there that will
generate stubs web objects the default
implementation for what objects doesn't
do that
in fact it just retrieved it wisdom and
then tries to be sort of nice about it
very quickly we'll go over this this is
a little bit more specific this sort of
is looking at the web service event flow
from a web objects point of view and I'm
not going to talk about the client side
because it's essentially a mirror image
of what happens on the server so the
client sends its wsdl request the server
returns the wsdl to the client the
client will then I mean this can happen
offline you can cash the wsdl we can
keep in a file use it to generate stubs
or whatever that happens could happen
right before the request and have the
client dynamically do something to
generate the the proper soap request
sometimes it happens or much earlier so
now the client sends a soap request the
server gets it as XML in web objects we
unmarked the XML into a set of objects
native types we process it we marshal
the response back into XML and we return
the response to the client again it's
very simple so let's begin talking about
what objects and web services webobjects
uses access for its engine to do web
service it's the apache extensible
interaction system I don't know why it's
called that because it doesn't seem to
have anything to do with what it
actually does it's written by the Apache
group it's open source it has support
for both the client and the server and
it has automatic wsdl generation we
basically stuffed it directly in web
objects does do some nice stuff for you
it has plugins for both session support
and custom serialization and
deserialization of objects in particular
all the basic objects that web objects
is likely to use all of our NS
collection classes and the EOS
themselves and of course on top of the
access engine we wrote in our coup de
Gras the director web services and we'll
talk about that later actually he'll
talk about that later
so things that we do to you specifically
the DC realises that we have our four NS
array data dictionary range time zone
Enterprise objects and global I be in a
web objects application and on the
client they are automatically registered
for you we also provide wisda for these
we also provide this is actually one
thing that we do that should be really
nice it's session support we have the
custom session handlers installed on
both the client and the server side one
major lack in the soap 11 spec is that
it doesn't talk at all about transaction
semantics there's no way to carry on a
conversation about web services when
they define the suspect they sort of
assumed that each web service would be
nice and sort of self-contained that the
answer from one invitation would have
nothing to do with the request of
another one we felt this was a major
lack particularly when we were trying to
deal with databases so what we added was
we extended the session support in what
objects to support sessions through web
services so that you can invoke a web
service and habits and stores that
server-side state can anybody else say
that three times fast I can't so it's
okay the other thing we add and this is
pretty minor is just dynamic
registration access is configured
typically through a set of XML files and
we typically don't like to do that so we
provided the low web service registrar
it's a single call that you can use to
register a web service okay so really
quickly I'm just going to run through
the demo so we have a demo server and
you can see session test services the
name of my service the service class
itself is not terribly complicated it's
called state test what I'm going to do
is it gets the current session oh sorry
then we remember ought to change the
font on this thing preferences text
editing in touch coloring oh here we go
sorry about that please forgive me I
know not what I do ah there we go all
right this is about a simple of a
services you can get we get the current
context the web objects context we get
the session and in our session we just
store an array of strings basically so
that as we send each time we add to that
list and finally the application here's
that single line that I was talking
about to register I've actually
registered the session under a different
name session test just to see you know
it's doable okay the client is going to
be a little bit simple what the client
is going to do is it's just going to be
a front end is going to be a web app
webobjects application with the text
field you're going to add in type in a
string hit enter and as a response we're
going to send back the list of
previously submitted strings this is
obviously a very trivial application
okay so web service client we can get
the web service client so on and so
forth alright so let's run these suckers
one thing to keep in mind at this point
is that the client because what i want
to do is I want to show you what's
happening on the client through
something called TCP monitor just to
prove that we're actually going across
and so you can see what the what the
state looks like I've actually stored
the wisdom locally on the machine and it
looks like this ok you can see here
state test response state test return it
returns an array the request takes a
string the name of the service is the
session test service the operation is
named state test and it takes a string
which turns the response which takes a
request returns a response those are the
message types that I was talking about
alright so let's hook this up
and let's hope the network is kind to us
and it is okay and here so our first
request is this one sorry if the fonts
still too small for this you can see
it's a very simple one you have the soap
envelope itself which defines all of the
namespaces you have the body and the
string itself encoded on the way back
again the envelope here's where the
session support comes in we start
sending the session we send the
information in the header you can see
that we have the session ID for those of
you who are familiar with webbed objects
in the instance ID in our case at this
point since we're running directly
there's no instance ID at all so we
return if you walk through the rest of
them the same request you can see that
we're simply returning an array ok back
to slice all right talk a little bit
about the client really quick it's
basically a very thin convenience
convenience API on top of axis while on
the server side we added director web
services we didn't add anything quite
that complex on top of the client side
the custom DC realises and sterilizers
are available they're registered the
session support is registered for
security you can do HTTPS on the client
side to connect using the standard Java
API going forward talking about security
currently the current state of the art
for web services security in terms of
secure connections is pretty much just
HTTPS that's fine it works pretty well
there is an industry standard
ws-security it's been basically
Microsoft IBM all the big people are
behind it
web bob jects doesn't support that at
this point unfortunately we do provide a
security delegate that will get invoked
at pretty much every single phase before
the response is sent after the responses
sent before and after marshaling so that
any at any point you can hook in and ask
webobjects to do whatever needs to be
done and finally so I'd like to
introduce ron was saying he's our
Jamaican Chinese webobjects engineering
cowboy ki ha Mon see humma come on come
on come on mon on you know the your hats
out of date it's already obsolete yeah
it's panther time now i can only find a
panther colored cowboy hat so thanks
Carl now that Carl's told us everything
we need to know about web services and
how webobjects leverages access to
support web services I'll just take the
next 20 minutes or so and tell you about
our kick-ass technology director web
services so let's see actually goes to
black first so I'll just talk a little
bit about three things three things
basically first what is it that direct
web services is trying to address what
problem is are trying to address and
also what technologies went into
director web services and then I'll give
you a cool demo about that has a web
objects application talking to a cocoa
desktop application via web services so
what problem is it that direct web
services solved basically we in the web
objects department believe that our
developers write too much code and by
that I mean they write too much
application specific code they should
really be we want our developers to have
simple lives and simply work on
fine-tuning their business logic so to
that end we've come up with these rapid
development technologies and if you're
familiar with director web or direct to
Java client then you're probably
familiar with the rule system that we
have in web objects with director web
services we've extended that and added
to it the axis and webobjects support
for web services and also our fantastic
enterprise objects framework
and wrap that in the rule system that we
have if you haven't heard of our rule
system it's basically a
question-and-answer system that lets you
infer values from a set of rules and
some contextual info that way you can
have a really dynamic application where
a set of rules instead of lots of code
defines your application behavior so the
problem that we're trying to solve is
most sure it's right now you can build a
web objects application pretty easily
that will vend your business logic as a
web service using access web objects and
eof but you still have to write some
code and usually that code does one of
four things create read update or delete
a bunch of rows from your database
typically called the crud operations so
we'd rather have our developers skip
doing all that crud and leave the work
to us so that's what director web
services tries to solve keeping you guys
productive working on your business
logic and leaving the crud behind so ya
know all right and so then on to what
technologies went into director web
services so Carl's already told you
about axis which does all the heavy
lifting of silk messaging for us he's
also told you about how webobjects ad
session support and of course all the
load balancing that you expect from web
objects as an application server so
between access and web objects we
already have a great way to talk web
services then on the low end we also
have the enterprise objects framework
for which we believe is the best way for
accessing and modifying interacting with
business data in your jndi or JDBC data
sources so and of course again wrapping
all of this in the smarts that is the
rule system we put together our kick-ass
crown jewel technology director web
services so I'm just going to go to the
demo now we get demo two please
cool just going to start a new project
just like all of our direct to star
projects we have a project template
called director web services and we'll
give it a cool name and we'll add a
business logic framework that I've
already built
all right navigational problems sorry
okay and we'll just go ahead and build
and launch the application so along with
the project templates we also have
assistance every director web
application director Java client
applications and now also direct to web
services have assistant applications
that you use to configure the rules for
your applications as a first step for
for specifying behavior of your
application so while that's starting up
see so it'll bring up a little web
browser which isn't entirely useful for
weds objects for a web services
application but it tells you that it
tells you you should really put this URL
in the web services assistant which I'll
do here so now the assistant is going to
connect to our application and it can
already look at all the models that are
in our application as you can see here
and it can also see all of the services
that are already published by default we
have an aptly named service the whoa
default web service at already set up
for us we'll go ahead and enable it and
we'll make one of these entities public
and over here you can see the service is
already populated by default every time
we add an entity by we add few
operations that do all those crud all
the crud work I talked about earlier
specifically inserting searching
updating deleting and we also look
through the vet specifications for your
model so we find things like my name
fetch sophistication yeah that's
specification for find user and login
user just so you can see what I'm
talking about here
so let's let's just give it a try we'll
do a search for users and we only want
to have to specify somebody's first name
and I want all the first names to be
case-insensitive like and we can also
change the return values so that we
return so we don't return some random
person's passkey we just get their
address first name and last name and I
want to change the public name for the
operation the return type so that it's a
user name so this is an important thing
right now we're exposing your business
logic as a web service so clients can go
and examine the Wizzle that's generated
from the service and you don't want them
to necessarily have a really good idea
of how your data is modeled so you can
change the names to be something less
sketchy for public consumption so now
we'll test the cept this operation and
we'll send the changes that we've made
in the assistant back to the server and
it will be updated in the rule system
there so now we can look for all users
with the first name starting with our
poof we do get one user some of this
text may be a little hard to read but
you'll see that there's a key value
coding null value here don't worry about
that what's actually happening is we're
sending back a serialized EO without the
pass key as you saw me configure earlier
on the client side here because this is
also using libel objects technology we
can actually create a real EO on the
client side but it doesn't have the
acute the passkey set yet so if we don't
want to see these values in our in our
client or especially if our client is in
a web object application we can go ahead
and turn on returning soap struct this
makes it a little bit cleaner for non
with objects clients alternatively it
makes it a little less efficient for web
objects clients so there's a trade-off
there
actually let's go ahead and add messages
as a public operation you can see we've
created some operations there and let's
go ahead and turn on the insert message
operation we don't want clients to
automatically create the creation date
for the messages that they're inserting
so we'll take that out we'll just say we
need a subject a recipient to send it to
buy a dress and let's add the sender's
address and a message and then for
return values we don't really need to
return anything just insert it and be
done with it and will enable the
operation turn on soaps trucks returning
just for the heck of it and let's try
this out okay forgot to change this
because we've gone and reverse
engineered kind of the fetch
specification in my model I actually
choose the names for the key value
bindings in the model which are not very
kosher as far as web services names go
so I'll go ahead and change these as
well and so you notice there we can
actually do a little bit of validation
for you to make sure that you're not
going to end up publishing a Wizzle that
isn't valid so again let's go back and
test the insert message operation let's
take a look at the Wizzle for this
service the entire service just for fun
this is the sort of thing that we don't
want you guys to have to worry about
this is precisely the sort of thing that
direct Web Services handles for you will
dynamically figure out what parameters
you set as input and output parameters
and merge those into a Wizzle for your
service let's say hello to Karl from me
wait for it Carl okay and we get an
exception so what's happened here is it
claims that the creation date is yeah so
we got an exception so now we know that
we need to start debugging our app all
right yes I believe this was expected
but this isn't the exception I expect so
in any case I can move on to starting up
an application that I no work no we have
a mess server message server rather gone
ahead and turned off whoa Otto open and
browser and set the port I'll also add a
couple of rules to our role model file
oh this part i want to emphasize for
editing rules in your application please
add a new file and name it d2w model
file like I've named it here so you'll
get this edit this file do not edit the
user BTW model file which is edited by
the assistant for you there are two
separate files you should edit the dtw
model file with rural editor so what i'm
going to do is change the location that
my web service application claims it's
running on i have it actually running on
port 8888 but through this rule the
service location URL which is a rule for
we're like how we publish the wisdom we
can change where clients will go to
invoke our web service and the reason
that i'm going to do that
so I can show you all of the cool XML
that goes back and forth through TCP
monitor okay so but clean build and run
and we'll go back to the assistant
connect we'll still connect through 8888
we could connect through 7777 but then
you'd get a little bit more gobbledygook
alright and here we can search for all
of our users okay
so one of the things that I've already
gone and done is change the return type
for arrays you can change how things get
serialize doubt simply by adding a call
to the low web service registrar what
I've done is make the XML that we return
simpler and more cocoa web services
friendly that's why the client here
didn't like it so heck let's see so I'm
going to add this to one of the download
sites after this conference so you can
actually try this code out basically we
tell it that if we're serializing out an
array should see realize it out with the
you are type instead of as soap enkore
so we can dynamically change how things
are serialized and deserialize as well
as which serializers get used and
another thing we can change thanks to
our dynamic deployment stuff we can
change how the response is encoded as
far as the entire silk message one of
the things I'm going to do in order to
make this more friendly for cocoa web
services is add my cocoa response
handler here into the response chain I
do that by by copying this line into the
response bit here what this handler does
it's simple simple piece of code that
runs through the soap element that we
return to the client and make sure that
the the return name for each element is
just returned so stopped up and run it
again and I'll bring up my cocoa
application and hide some of this stuff
we cool okay so i have a few classes in
here that were generated by WS make
stubs which is located in flash
developer tools which takes a bunch of
wisdom and generate some objective c or
applescript or one other i believe just
CF code that lets it that lets you
invoke the web service really easily you
don't have to write as much of this
stuff i'm going to make sure that i use
a valid name and it please and i'll
build and run this so here our server is
running so we'll hide that will get rid
of this basically what the what this
cocoa application will do one of the
things that can do is log in to log into
our web service using a just a simple
name and password and find a global ID
this global ID then you can pass back as
a key sort of to other web services
indications similarly you could
conceivably return a session ID or
something else like that that lets the
up the following operation in vacations
do something more intelligent kind of
contextual information so here's my app
and I'll do is I'll check my email
there's nothing there it's fine let me
try sending Carl a message
hmm let's take a look at the important
debugging tool tcp monitor oh I've done
something very silly and not included
this is my bill target yeah
so we'll give this one more try
and that definitely seems to have worked
let me check first okay so here we've
gone across let me check again so you
don't miss it and sent a clear text name
and password don't do this and replied
with a bunch of messages that are
encoded for specifically for cocoa you
could do this for any other client net
has worked we could do this for regular
applescript clients as well see and if I
send myself a message you can see that
we first log in finding the name or
finding the name of the recipient here
and getting it getting the global ID
this is an encoding of the global ID so
that we can use it later when we send
the actual message so this is a two
parts two-step process for for this
specific web service here you can see
we've sent a global ID for the recipient
and defender and I can check my mail
again and see that we indeed did get the
message one of the other things that
Carl alluded to was session support and
how that enables transactions for
director web services and web objects
web services in general you'll notice
when I check the service panel here we
have a little check box for allows
transactions or not with that enabled we
can go and check any of these and look
in the wisdom there will be two extra
three extra operations begin and commit
and rollback transaction operations this
way a web service client can explicitly
ask for session state to be kept on the
server for the remaining transactions
once they initiate a begin transaction
operation
sending simply begin transaction to the
server we keep the session of lives
reply with some session headers in the
soap message which the client hangs on
to simply forwarding those message
headers to the server will awakens the
correct session for the client so you
can do things like keeping a bunch of
changes in the editing context on the
server going keep making changes without
committing them to the database until a
commit transaction is sent so that's and
I think that was 00 as far as extending
the frameworks here how much time doing
okay extending the framework you can see
we have all the default services and
default operations you can also create
your own you can see you can create a
new service and change its name as well
as creating a new operation for it we
bring up a new operation dialog name the
operation and define which entity it
works with all of these changes are
saved in the rule system so that simply
by invoking a operation by name web
objects will automatically know what
entity the operation is meant for and
whether it should be inserting or
deleting or updating new records in in
the editing context so we can add a
search user operation named have fun
change the parameters and this play will
play with any of these settings until we
get it just right at which point we
might want to actually make some small
tweaks into how it's working at that
point we can actually freeze the
operation this generates real source
code we can name the operation source
and then we go and generate the source
for you for everything that you would
need for actually doing what is done by
default and we also generate a static
liz'll page that you can edit so we've
generated a lot of code and it does the
same thing boring next I'd like to
simply I'd rather just subclass the
existing operations and only tweak the
little things that I need rather than
having to manage a set of source if I
really needed it this would be useful
but in my case I typically just want to
change the return object by one little
amount so instead of freezing an
operation I can create a new operation
here name it a simple subclass and same
settings and you'll notice that once we
froze the previous operation we can no
longer edit any of these arguments and
return values so you have to get it
right before you freeze it it can
unfreeze but you still have to throw out
your original source when we subclass
you'll see we still get the dynamic
system here in order to configure
arguments and return types now
subclassing involves one little thing
there is a template that ships with web
objects and it lives in developer
documentation webobjects web services
templates blah i'm going to simply copy
that with this cute little script pirate
yeah i'm going to copy that into
developer project builder extras file
templates webobjects just read the
directions doesn't read me here
so now that I've copied that template
there I can go and create a new director
web service operation subclass will name
it and you can see now we have something
much simpler than this but it does
pretty much the same thing all you need
to do is tell is tell the or define your
operation to subclass one of our other
operation types search or insert or
delete operation this one is going to be
a search service search operation and
here i can print out a little extra
debug information one of the things that
we get when we r invoked when an
operation is invoked is a set of input
part values these are the values that
the client has actually sent to the
server and will also have to register
this service this operation with the
rule system the way we do that is
editing again the d2w BTW model file and
we'll say when the operation name that's
invoked is say hello don't ask me where
i come up with these names i don't know
either then the operation class that
should be invoked is my happy happy
class and a very similar rule needs to
be used in order to tell the rule system
that it is a dynamic operation
well I didn't need to do that copy paste
is a wonderful thing okay so operation
class name is set it is operation for
frozen is set to false save stop and
build and then we can go back to the
assistant disconnect wait for the
application to warm up again and then
once we've connected we can start
configuring this neil operation that
you'll see there so in my simple service
we can actually rename this to say hello
and you can see we can still edit the
arguments return types and which
services associated with whereas the
frozen one is still just frozen we'll go
ahead and add subject and a recipient as
input parameters and change fees and the
creation date and the sender so lots of
little parameters oh I have to make
these public another security feature
reminding you that you must make these
things public before anybody can invoke
them
okay so we can at least set the subject
will probably get an exception saying
that we don't have the serializer for
the response type but here you can see
on the server side that we didn't get in
fact get some input part values that we
can flux with before invoking super so
this way we still don't have to do all
of the work of actually inserting or
searching or deleting or whatever we can
just tune little parameters of the
operation to suit our needs and with
that I'd like to go back to the slide so
that's it direct web services web
services made easy based on the axis and
webobjects support for web services
using eof so that you don't have to
write any of the crud code and using the
rule system to define the parameters and
the behavior of your application with
that I'd like to bring Carl back up
stuff yep another demo but I did that
one there we go
thank you Ron so running a little short
on time that's ok let's talk really
quick there are some deployment
considerations when you're deploying web
services through web objects he talked
about a little bit about session support
and load balancing we do support
multiple instances of webobjects vending
web services and then load balancing
between them the key to that though is
that the load balancing is based on
cookie support the client we basically
send which instance you should be
talking to back as an HTTP cookies so
the client has to be able to understand
that and bend it back to us properly
otherwise the whole transaction session
thing breaks down entirely so that's one
thing to keep in mind the Wiz the
location you generally want to simply
publish your single wisdom it's nice
that we dynamically generate it and it
means it's easy to change but it's
probably best if you simply put it up on
a web server and then reference it
directly from there it probably
shouldn't change all that often because
a lot of people do things like generate
stubs off of it so if you change it you
will break the client finally we talked
about registration uddi was designed to
be this sort of analog to DNS or the
phone book we're all sorts of web
services operations would register in
this gigantic directory that was you
know all over the world and everybody
would look up stuff there so far it
hasn't really caught on it may beginning
to build a little bit of momentum it's
in the j2ee 1.4 spec and so on but it's
still not this giant phonebook thing
that the original authors had intended
in lieu of that a lot of companies use
web services internally and in in order
to publish their web services they
either have an internal uddi server
there are a number of free uddi servers
out there or they do something simple
like the web page or something like the
way ex.message would do it or just word
of mouth you send an email out saying
hey guys I published a web service the
way Stoke it is available at blah
so web services in two words even less
than the one sentence internet RPC it
has lots and lots and lots of acronyms
hopefully you know a little bit more
about them now but that's okay the goal
for us of course was that you know much
of that could be skipped that we would
try to do as much of that as possible
for you they would like it to be located
and registered in a uddi server and
because we're talking about standards
we're kind of going to go in that
direction it's described by the by the
wsdl it sent a soap encoded XML over
HTTP or smtp snail mail carrier pigeon
whatever hey don't knock the carrier
pigeons they were very efficient and
cheap you try laying a t1 line versus
getting a bird so webobjects itself at a
very fundamental layer very basically
adds transactions and type support and
that's good that's helpful the big thing
for us is that we add directed web
services and this is something I really
want to stress web director Web Services
provides you with automatic
comprehensive and very easy to configure
web services for your entire database
right you no longer have to do go
through and figure out what you need to
write how do i access this how do i you
expose it you basically point direct web
services at your database bring up the
assistant do a little bit of clicking
and pointing and checking and unchecking
and you can expose your entire database
with transaction support it looks
transparent to people they can say let's
start a transaction add some stuff
modify some things set up some
relationship when you're done check if
everything is in a good state if so
commit if not roll it back it's
beautiful I believe actually that it's
even better than something like director
web when you build something like
director web you're generating a UI and
then you have to tweak the UI so it
looks good so it fits in with your site
and everything else like that with
director web services it's just the
information your throughout your
database is exposed directly it can be
used by multiple clients it can be used
by clients you've never heard of in
languages you don't know or don't
recognize can't read right it's that
easy and it's something that we would
really really like people to take
advantage of